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

[Paul Kyzivat <[e-mail]>]

On 7/16/12 7:18 PM, DRAGE, Keith (Keith) wrote:
> Given Adam's response that these should all be standards track as currently defined, then if they do come in in that form, then there does need to be a reevaluation of the scope of the current INSIPID requirements.
>
> As far as I am aware it is not the scope of the INSIPID charter that rules this out, but only the requirements currently drafted in the working group document.

You seem to be making the assumption that this has some relationship to 
INSIPID. I don't necessarily see that it does.

The suggestions that Adam and I had made for alternatives to what has 
been proposed, using mostly existing fields, don't require the INSIPID 
work. (Its ok if B2BUAs alter the values as long as they alter them in 
all relevant places.) Maybe that won't work in practice, but there needs 
to be discussion to determine why not.

If INSIPID starts calling for things such as Refer-To-Session_Id, then I 
think it will quickly be shot down.

To go standards track the work should start in Dispatch. (And if it is 
to progress smoothly then it should come as requirements, not as a 
proposed mechanism that has already failed expert review.)

	Thanks,
	Paul

> Keith
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul
>> Kyzivat
>> Sent: 16 July 2012 21:16
>> To: [e-mail]
>> Subject: Re: [RAI] FW: Expert Review of 6 new SIP header fields defined by
>> OMA CPM 1.0
>>
>> On 7/16/12 3:34 PM, James Polk wrote:
>>> haven't thought this through completely, but where would the new
>>> Session-ID fit into this? The Session-ID within the INSIPID WG is coming
>>> down the pipe really soon, and seems to track *similarly* to how I read
>>> the OMA's desired use of the Conversation-ID.
>>
>> I don't think it is the same. IIUC they want to use a common ID for
>> multiple dialogs, and independent transactions (like MESSAGE) that
>> otherwise appear to be independent but are semantically related.
>>
>> AFAIK that is beyond the scope of session-id.
>>
>> I still think they can accomplish their goals with existing mechanisms
>> (and sufficiently smart B2BUAs). But obviously they don't agree. I don't
>> know how this will get sorted out.
>>
>> 	Thanks,
>> 	Paul
>>
>>> James
>>>
>>> At 01:25 PM 7/16/2012, Cristina Badulescu wrote:
>>>> Content-Language: en-US
>>>> Content-Type: multipart/alternative;
>>>>
>>>>
>> boundary="_000_B802D092CAFAB344B354F0977DEB71EE558AE7C7C4EUSAACMS0703e_"
>>>>
>>>> Dear all,
>>>>
>>>>
>>>> ...continuing to respond to RAI review comments below; I hope that
>>>> I've collected all comments previously circulated on RAI list.
>>>>
>>>>
>>>> Comment (email 19/03/2012 Paul Kyzivat)
>>>> OMA Header Possible Alternative
>>>> -------------------------- -------------------------------------
>>>> Conversation-ID Message-ID of 1st message
>>>> [Cristina] OMA CPM has the concept of "Conversation" which groups
>>>> together for example chat sessions, file transfers, standalone
>>>> messages, subsequent disposition notifications e.g. 'delivered'. The
>>>> Conversation content (messages, file tranfers, notifications, etc) is
>>>> identified and stored all together, by the Conversation-ID which ties
>>>> them all together.
>>>>
>>>>> Contribution-ID Message-ID
>>>>
>>>> [Cristina] Same as above, it has to apply to more than messages - as
>>>> it ties together chat sessions, file transfers within a chat session.
>>>>
>>>>> InReplyTo-Contribution-ID In-Reply-To
>>>>
>>>> [Cristina] A header with the equivalent syntax to the Contribution-ID
>>>> was created, for correlation and sequencing within a conversation.
>>>>
>>>>> Session-Replaces References(?)
>>>>
>>>> [Cristina] This is supposed to carry a Contribution-ID - not sure
>>>> where References is defined (CPM 1.0 was Candidate Approved in 2010).
>>>>
>>>>> Message-Expires Expires(?)
>>>>
>>>> [Cristina] In OMA CPM the message might be deferred and stored in the
>>>> network if the recipient is not available, for later delivery or user
>>>> initiated retrieval of the stored message. So message-expires is a way
>>>> for the sender to indicate the expiry time of the message itself (e.g.
>>>> a too late retrieval might be useless from the message content
>>>> perspective). It is not related to the "Expires" header for the SIP
>>>> transaction.
>>>>
>>>>> Message-UID Message-ID
>>>>
>>>> [Cristina] This header is related to the way messages are identified
>>>> in the Message Store accessible through IMAP.
>>>>
>>>> Comment (email 20/03/2012 - Dale Worley)
>>>> ----------------------------------------------
>>>> Conversation-ID Message-ID of 1st message
>>>> Contribution-ID Message-ID
>>>> InReplyTo-Contribution-ID In-Reply-To
>>>> 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].
>>>>
>>>> [Cristina] Answer is same as in my previous email to Adam.
>>>> Call-Id syntax was not used since the values of these headers should
>>>> be created and used 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 (passing through SBCs). We wanted to avoid
>>>> any cases where SBCs could alter the new headers in any way (e.g. even
>>>> a blind replacement of the ['@' word]" part).
>>>>
>>>> Also, in CPM scenarios where a closed group chat session is revived
>>>> later on by any one of the original participating UAs (i.e.
>>>> re-initiating it), the same Conversation-ID of the previous group chat
>>>> INVITE would have to be used. As this later UA could be in a different
>>>> domain, carrying the original ['@' word]" part does not serve any
>>>> purpose (but can be confusing).
>>>>
>>>>
>>>> Regards
>>>> Cristina
>>>> _______________________________________________
>>>> RAI mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rai
>>>
>>> _______________________________________________
>>> RAI mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rai
>>>
>>
>> _______________________________________________
>> RAI mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rai
>