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

From: James Polk <[email-masked]>
Date: Mon, 16 Jul 2012 18:51:17 -0500

I'm not sure I agree with everything you said, but could be wrong.

It appears what OMA wants is to relate non-dialog transactions 
together, with the ability to pick back up a relationship that 
existed in the past, went either dormant or idle, then someone from 
that previous transaction(s) starts again what they call the 
Conversation-ID or that someone not in the previous (set of) 
transaction(s) joins while not changing the Conversation-ID.

This to me is completely new wrt the scope of INSIPID's charter and 
not an issue the current requirements not articulating this as a 
use-case. The reason why I asked was that I could see it as a phase 
II approach for INSIPID after the initial work is completed (i.e., 
via a recharter).  Of concern would be the idea of having a 
Session-ID from INSIPID be unique through space and time, but 
resurrectable. IOW, any Session-ID would be able to be active 
whenever an entity or actor wants to use it again. IMO this violates 
the "unique through space and time" aspect. I can see there being a 
real problem for one of the charter stated use-cases about logging 
and analysis. If a provider thinks it has a good handle on a 
communications session, from start to end (i.e., which final response 
is the final response for the Session-ID?). Wouldn't it be a real 
problem for there really to be no end (because it is resurrectable)?

James

(copying insipid for those who aren't on the rai list)

At 06:18 PM 7/16/2012, 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.
>
>Keith
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> > Kyzivat
> > Sent: 16 July 2012 21:16
> > To: [email-masked]
> > 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
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/rai
> > >
> > > _______________________________________________
> > > RAI mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/rai
> > >
> >
> > _______________________________________________
> > RAI mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rai
>_______________________________________________
>RAI mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rai

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 17 Jul 2012 02:21:31 +0200

We agree that the requirements currently preclude it.

In the charter that only words that would preclude it are:

" This group will focus on a document that will specify a SIP
identifier that has the same aim as the From-tag, To-tag and Call-ID
conjunction, but is less likely to be mangled by intermediaries."

There are plenty of other words that would allow it, and the quoted words above are only "focus", not "concentrate entirely".

But in any case, let us see if we have a proposal coming in.

Keith

> From: James Polk [mailto:[email-masked]]
> Sent: 17 July 2012 00:51
> To: DRAGE, Keith (Keith); Paul Kyzivat; [email-masked]
> Cc: [email-masked]