Re: [RAI] FW: Expert Review of 6 new SIP header fields defined by OMA CPM 1.0

[Cristina Badulescu <[e-mail]>]

dear Adam,


Thank you for the comprehensive analysis and feedback, I understand the RFC5727 (esp. sect. 4) better at this point.
I will take the IETF RAI conclusion back into OMA for consideration and assessment of the next steps.


Best regards,
/Cristina



________________________________
From: Adam Roach [mailto:[e-mail]]
Sent: July-16-12 5:53 PM
To: Cristina Badulescu
Cc: [e-mail]; [e-mail]
Subject: Re: FW: [RAI] Expert Review of 6 new SIP header fields defined by OMA CPM 1.0

Cristina:

Thank you for your clarifying comments. It is now clear that RFC 5727 expert review processes are unlikely to apply to the CPM header fields at all. If your replies are accurate, then all of the CPM 1.0 header fields (with the possible exception of Message-UID) must be processed through the normal IETF Standards Track process, which requires the mechanism to be developed in an IETF working group. If OMA's official position is that communication fails in the absence of these header fields, then I suggest that you quickly bring a proposed set of requirements to the SIMPLE working group so that the IETF work can begin in earnest.

On the other hand, if you would prefer to register header fields under RFC 5727 section 4 procedures -- without the need to publish them via the IETF Standards Track process -- then you must make them conform to the criteria in RFC 5727 section 4. In my original message, I indicated how to do this for every proposed header field (save Session-Replaces, which I discuss below). Re-asserting as immutable facts the very properties that violate RFC 5727 section 4 criteria is not sufficient to bring them out of violation; actual changes are required.

I have specific responses inline, below.


On 7/16/12 1:15 PM, Cristina Badulescu wrote:
----------------------------------------
Conversation-ID

Conclusion: Apparently unsuitable for registration (significant client behavior change), can be fixed with clearer semantics describing client behavior when header field is absent.
[Cristina] Conversation-ID is mandatory in CPM, so if the header field is not present then it's a typical protocol error case.
[Cristina] Conversation-ID is mandatory in CPM 2.0. So if the header field is not present in the SIP message received by the CPM participating function, then it'll be a failure at protocol level and the CPM session will not be initiated.

If the presence, absence, or value of the header field can cause the communications to fail, then it is not subject to registration under RFC 5727 section 4 procedures (numbered criteria 1, in particular). You must instead bring the mechanism to the IETF for refinement and eventual publication as a standards-track RFC.

To be clear: you claim that absence of the header field causes the communication to fail. I can imagine no more radical behavioral change than the conversion of success into failure.

Based on your answer above, Conversation-ID must not be registered under RFC 5727 section 4 procedures.

[Cristina] Similar answer as for Conversation-ID answer applies to the Contribution-ID for Call-ID reuse and mandatory nature for all CPM SIP methods.

Based on this answer, Contribution-ID also must not be registered under RFC 5727 section 4 procedures. See my response above.

----------------------------------------
Session-Replaces

Conclusion: Unsuitable for registration (overlap with RAI work)

This proposed header field directly conflicts with the "Replaces" header field defined by RFC 3891, which constitutes existing work within the IETF RAI area. It is not suitable for registration.

I do not believe that the described mechanism can be altered to overcome this conflict. OMA should instead employ the mechanism defined by RFC 3891.
[Cristina] The main problem encountered with "Replaces" was that SBGs along the way (or B2BUA) alter the Call-ID value contained in this header field. This beats the purpose in the service logic in CPM, as we absolutely needed to identify the Contribution-ID of the original session being replaced. So the Session-Replaces contains the original Contribution-ID value (not Call-ID).

If the SBCs are altering the Call-IDs, then it is incumbent on those SBCs to make corresponding adjustments to the "Replaces" header field. Re-inventing the SIP protocol in a parallel set of header fields as a vain attempt to stay ahead of SBCs' ability to disrupt services through data alteration engages in a cat-and-mouse game that cannot be won. Any rationale that can be applied to claim that such SBCs will leave Contribution-IDs unmolested can be applied equally to Call-IDs.

The proposed header field remains in competition with an existing standards-track mechanisms, in violation of the RFC 5727 admonishment that experts are to "review documents for overlap with existing chartered work in the RAI Area." It cannot be registered as long as it remains in competition with RFC 3891.

To suggest a concrete path forward: I will first re-iterate that this kind of operation must be performed using the mechanism defined in RFC 3891. If SBC survivability remains an issue, I would suggest that you bring work to the IETF that extends RFC 3891 to optionally use the end-to-end identifiers presently undergoing specification in the INSIPID working group. I would begin by discussing such a need on the DISPATCH working group mailing list: https://www.ietf.org/mailman/listinfo/dispatch

In my opinion, it would be easier for OMA operators to clarify to the vendors selling them SBCs that a criteria for selection of such SBCs includes Replaces header field Call-ID fix-up for Call-ID changes perpetrated by the SBCs.


----------------------------------------
Message-Expires

Conclusion: Suitable for registration, once security is addressed

This header field avoids overlap with existing RAI work by careful scoping its use to the INVITE method. Client behavior in its absence appears to be well defined, and does not constitute a significant change in SIP client behavior.

This header field needs better discussion of its security properties. In particular, implementors need to ensure user expectations around what happens when a message expires are properly dealt with. For example: if a user sends a message which he expects to expire in one hour, there is no guarantee that the recipient will be unable to retrieve the message after that time. Further, the recipient device may not preclude the storage of received messages well past their expiration.

[Cristina] it was left as an implementor's choice how to deal with this case, hence not intended for the standard specification.

I'm not suggesting that you add any specification. I'm asking that you add warning that these specific security issues exist and guidance about how they might be handled. Without security guidance, the header field does not satisfy the second numbered criteria listed in section 4 of RFC 5727. Unless such considerations are added, then the field cannot be registered.

/a