Subject: [RAI] Expert Review of 6 new SIP header fields defined by OMA

From: Adam Roach <[email-masked]>
Date: Mon, 19 Mar 2012 16:27:25 -0500

I have been asked by the RAI area directors to review of the SIP header 
fields proposed by the following OMA document:

http://www.openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C/OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf

I have been designated the formal expert reviewer for this request from 
OMA. Although this is not the formal review (which will be sent in 
response to a request from IANA), the contents of my review will be 
identical to or substantially similar to the following if the current 
proposal is sent to IANA. OMA is encouraged to make adjustments as 
suggested below before proceeding.

----------------------------------------------------------------------

The OMA proposal "CPM Conversation Functions" describes six new SIP 
header fields. These header fields are intended to facilitate their SIP- 
and MSRP-based instant messaging architecture. I will address each 
proposed header field individually, using the criteria described in 
section 4 RFC 5727.

In particular, I am analyzing for a lack of overlap with existing 
(either complete or in-progress) work in RAI; the absence of significant 
changes in SIP client behavior; and proper treatment of security-related 
issues.

My first comment, which is global, is that this document nearly 
universally uses the term "header" where "header field" is intended. 
While this is largely editorial, RFC3261 does have a clear definition 
for the term "header," and its use in this fashion is nonsensical. This 
does not preclude registration of the header fields.

----------------------------------------
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.

This proposed header field does not appear to directly conflict with 
existing or ongoing work in the RAI area. However, its presence is 
likely superfluous, as the SIP Call-ID of the initial message in the 
conversation could trivially be used for this purpose: it has the same 
information properties as the proposed Conversation-ID.

After carefully reviewing both OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C and 
OMA-TS-CPM_System_Description-V1_0-20101012-C, I have serious concerns 
about whether this header field qualifies as "purely informational" and 
as "NOT significantly chang[ing] the behavior of SIP entites that 
support it." In particular, both documents contain normative language 
indicating behavior such as the following:

    "[T]he CPM Participating Function... SHALL extract and locally store
    the following headers of the request: From header; To header; Date
    header, if it exists; Conversation Identity and Contribution
    Identity and if there is, Contribution Identity being replied to."

This text, for example, leaves the behavior undefined when a 
Conversation Identity header field is not present in the SIP message. 
Many implementations will consequently fail to process the request when 
no Conversation-ID header field is sent, which is the most radical 
behavior change possible.

To be acceptable for registration under RFC 5727 guidelines, the 
behavior described in this document (and related documents that discuss 
conversation behavior) need to be revised to clarify that the absence of 
this header field cannot result in substantial changes in client 
behavior, such as failure to process the message.

I will observe that the use of the initial Call-ID of the conversation 
to identify the entire conversation (as suggested above) completely 
eliminates these concerns, as RFC3261 mandates the presence of Call-ID 
in every SIP message.

Since the header field is not presently suitable for registration, I 
will not perform a security analysis for Conversation-ID.

----------------------------------------
Contribution-ID

Conclusion: Apparently unsuitable for registration (significant client 
behavior change), can be fixed with clearer semantics describing client 
behavior when header field is absent.

This proposed header field does not appear to directly conflict with 
existing or ongoing work in the RAI area. However, its presence is 
likely superfluous, as the SIP Call-ID of the message could trivially be 
used for this purpose: it has the same information properties as the 
proposed Contribution-ID.

I have concerns congruent with those for Conversation-ID, in that 
behavior in the absence of the Contribution-ID is not well defined, and 
therefore will likely lead to interoperability failures (which 
constitute significant changes in client behavior). For example:

    "[T]he CPM Participating Function... SHALL, in case of a Pager Mode
    CPM Standalone Message, store the following information: ...
    Contribution-ID; InReplyTo-Contribution-ID (if present)."

This comment may be addressed in the same way as for Conversation-ID.

I will again observe that the use of Call-ID for this function 
eliminates all interoperability concerns.

Since the header field is not presently suitable for registration, I 
will not perform a security analysis for Conversation-ID.

----------------------------------------
InReplyTo-Contribution-ID

Conclusion: Suitable for registration, once security is addressed

This proposed header field does not appear to directly conflict with 
existing or ongoing work in the RAI area, and client behavior in its 
absence appears to be well defined (communications proceed as expected).

Note that the use of Call-ID for identification of contributions would 
allow the use of the already-defined SIP "In-Reply-To." Doing so 
eliminates the need for the definition and registration of a new header 
field.

This header field needs to include a discussion of security: if new 
users are included into an ongoing conversation, the presence of this 
header field can be used to deduce that they did not receive previously 
sent messages on the topic. The very existence of these messages may 
constitute sensitive information that the sender did not intend to 
reveal. In particular, senders should have the ability to suppress this 
header field to avoid leaking such information.

----------------------------------------
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.

----------------------------------------
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.

----------------------------------------
Message-UID

Conclusion: Suitable for registration

This header field does not appear to overlap with any existing RAI work. 
Client behavior in its absence appears to be well defined, and does not 
constitute a significant change in SIP client behavior.

The presence and use of this header field does not appear to introduce 
any security issues.

/a