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

["DRAGE, Keith (Keith)" <[e-mail]>]

Obviously this hits dispatch first, if it ever comes back.

I was merely countering the assertion that the charter of INSIPID precludes it.

Keith

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: 17 July 2012 02:51
> To: DRAGE, Keith (Keith)
> Cc: [e-mail]
> Subject: Re: [RAI] FW: Expert Review of 6 new SIP header fields defined by
> OMA CPM 1.0
> 
> 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
> >