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

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 17 Mar 2012 12:43:24 +0200

Hi,

OMA has defined 6 new SIP header fields in the following document:

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

The relevant sections and Section 5.3 ad Appendix C.

Per RFC 5727, they have requested us to perform an expert review on
these header fields:

http://tools.ietf.org/html/rfc5727#section-4

We will assign an expert to look into this. Nevertheless, any input from
the community on these new header field definitions will be appreciated.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Mar 2012 16:30:30 -0400

I skimmed the referenced document and the header definitions.
I wonder if any consideration was given to reusing existing sip and mime 
headers to accomplish what these new headers are used for. It seems 
there are ones that could be used.

For example:

OMA Header                    Possible Alternative
--------------------------    -------------------------------------
Conversation-ID               Message-ID of 1st message
Contribution-ID               Message-ID
InReplyTo-Contribution-ID     In-Reply-To
Session-Replaces              References(?)
Message-Expires               Expires(?)
Message-UID                   Message-ID

(I don't know much about MIME. But I found defs of some of the above in 
RFC5322. Perhaps someone with detailed knowledge of MIME can 
correct/improve on this.)

Of course I don't fully understand the reasoning behind these new 
headers, and so these mappings may not work. But I think it would be 
worth studying the analogies between sip/oma messaging and email 
messaging/message-threads. We probably need a mime expert to help with that.

(Defining new headers to do the same thing as existing headers 
complicates things for everyone.)

	Thanks,
	Paul

On 3/17/12 6:43 AM, Gonzalo Camarillo wrote:
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 19 Mar 2012 17:13:55 -0400

> From: Paul Kyzivat [[email-masked]]
> 

As far as I can tell, "Message-Id" is copied from RFC 3501 and looks
like it is supposed to carry a "message sequence number within a
conversation", because the BNF is:

    uniqueid        = nz-number
			; Strictly ascending

It looks like "Message-Expires" is for when the message being
transferred is large enough to require a dialog.  ("carries the expiry
time associated with the Large Message Mode CPM Standalone Message")
The problem with using "Expires" for this number is that "Expires" is
already used to specify how long the UAS has to respond to the INVITE.
But if the message transfer process takes a while, they seem to want
an additional specification of the point after which transferring the
message can be abandoned.

> Session-Replaces              References(?)

all have a value that is syntactically "word", as opposed to Call-Id,
whose syntax is "word ['@' word]".  For consistency's sake I'd like to
see them all use the same syntax.  Section 3.2 suggests that the
datatypes of these headers has already been fixed in [OMA-CPM-SD].
But if that is so, why would that document have fixed a syntax which
matches "word" in RFC 3261?

Dale

---

From: Nancy Greene <[email-masked]>
Date: Mon, 19 Mar 2012 21:09:11 -0400

Hi, some answers below to Dale's email:

...

>It looks like "Message-Expires" is for when the message being transferred is large enough to require a dialog.  
>("carries the expiry >time associated with the Large Message Mode CPM Standalone Message") The problem with using 
>"Expires" for this number is that "Expires" is already used to specify how long the UAS has to respond to the INVITE.

[Nancy] correct

>But if the message transfer process takes a while, they seem to want an additional specification of the point after which
>transferring the message can be abandoned.

[Nancy] Actually it is not that the message transfer process may take a while, it is that this message might be deferred and stored in the network if the recipient is not available, so message-expires is a way for the sender to indicate the expiry time of the message. 

>all have a value that is syntactically "word", as opposed to Call-Id, whose syntax is "word ['@' word]".  For consistency's sake I'd 
>like to see them all use the same syntax.  Section 3.2 suggests that the datatypes of these headers has already been fixed in 
>[OMA-CPM-SD].

[Nancy] Call-Id syntax was not considered since the values of these headers should be created in a way unrelated to Call-Id.  These ID's are expected to simply be copied over at B2BUA's so they will remain the same on an end to end basis.

>Dale

Nancy

---

From: Nancy Greene <[email-masked]>
Date: Mon, 19 Mar 2012 21:20:05 -0400

...
> OMA Header                    Possible Alternative
There was a requirement in the OMA CPM work for more than just messages to be grouped together. It was meant to also cover file transfers and chat sessions, for example. So any standalone message, chat session or file transfer that was all related to the same "conversation" would have the same conversation-id.

> Contribution-ID               Message-ID
Again, it has to apply to more than messages - it has to apply to chat sessions and file transfers too.

> InReplyTo-Contribution-ID     In-Reply-To
A header with the equivalent syntax to the Contribution-ID was created.

> Session-Replaces              References(?)
This is supposed to carry a Contribution-ID - not sure where References is defined.

> Message-Expires               Expires(?)
Since it is used for sending a large message using INVITE and MSRP, Expires could not be used since it has another meaning in a SIP INVITE.

> Message-UID                   Message-ID
This header is related to the way messages are identified in a message store.

Nancy

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 20 Mar 2012 10:50:53 -0400

> From: Nancy Greene [[email-masked]]
> 
> >whose syntax is "word ['@' word]".  For consistency's sake I'd like
> >to see them all use the same syntax.  Section 3.2 suggests that the
> [Nancy] Call-Id syntax was not considered since the values of these
> headers should be created in a way unrelated to Call-Id.  These ID's
> are expected to simply be copied over at B2BUA's so they will remain
> the same on an end to end basis.

Yes, these field values are never copied to/from a Call-Id field
value.  For some reason, the syntax for the values of these fields was
chosen to be 'word' from RFD 3261.  The header field in SIP whose
value has the most-semantically-similar datatype is Call-Id.  To
minimize complexity, that would suggest that these fields should use
the same value syntax as Call-Id, viz., 'word ["@" word]'.  But there
may be other considerations that I am not aware of.

Dale