Subject: Re: [Sip] Body handling - Contexts WAS (Re: multiple bodies in any SIP message)

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 08 Jan 2009 16:17:49 +0200

Hi,

by now, most people should be back from their vacation. I will wait a 
few days for further comments and, if everybody is happy with the 
current draft and no one proposes new text, we will go ahead request its 
publication.

Thanks,

Gonzalo

Hadriel Kaplan wrote:
> I think that's really a question for the others (Paul, Dean, Eric).  I interpreted body-handling to address the issue already, but maybe not the backward compatibility issue.
> 
> Also, section 8.1. talks about the context being defined by the method, C-D and C-T.  It should probably mention that the Event package for SUB/NOT/PUB and soon the Info-Event package narrows the context further.  And I'm not sure that C-T has anything to do with defining a context.
> 
> -hadriel
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[email-masked]]
>> Sent: Tuesday, December 16, 2008 4:05 AM
>> To: Hadriel Kaplan
>> Cc: Eric Burger; SIP List
>> Subject: Body handling - Contexts WAS (Re: [Sip] multiple bodies in any
>> SIP message)
>>
>> Hi Hadriel,
>>
>>  > I think the body-handling draft already does it, although maybe I'm
>>  > reading into it what I want to and not what it really says.
>>
>> the draft already talks about contexts:
>>
>> http://tools.ietf.org/html/draft-ietf-sip-body-handling-05#section-8.1
>>
>> I would like to agree on a concrete way forward. Do you think we should
>> add something to the body handling draft? Maybe expand the information
>> on contexts? Maybe provide guidelines for extension developers so that
>> they take them into account when defining new extensions?
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> Hadriel Kaplan wrote:
>>> [note: changing the thread to be consistent]
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Eric
>>>> Burger
>>>> Sent: Sunday, December 07, 2008 10:37 AM
>>>> Everyone seems to think there needs to be a generic way of identifying
>>>> body bits.
>>>> I do not see an obvious, generic way of doing this.
>>>> Thus for those out there who think there is a generic way of
>>>> identifying body parts for SIP, please write text.
>>> I think the body-handling draft already does it, although maybe I'm
>> reading into it what I want to and not what it really says.
>>> You asked, so this email is long.  This is what I think is the way to do
>> it...
>>> :Executive summary: basically we let C-D of "render" mean render to the
>> specific context of the message; we mandate future extensions which are
>> not for that context disambiguate themselves, by not using a C-D of
>> "render" or the other ones already in use, and that they can't use a C-T
>> already used today either. (and that includes changing geoloc's C-T
>> immediately)
>>> :The Details:
>>>
>>> Definitions:
>>> User-context = the specific context defined by the method name, and
>> package if it's a method which has a package sub-context
>> (SUB/NOT/PUB/INF).  The target user is the user-context's app-layer.  For
>> example an "application/dtmf-relay" body-part would want to be targeted to
>> the user-context defined by the "dtmf" package in an INFO.
>>> Method-only-context = the context defined by the method name alone,
>> ignoring any package.  The target is the specific message processor/state-
>> machine for that method, but for any/all packages/sub-contexts.  For
>> example the Event and Subscription-State headers are for this context in a
>> SUBSCRIBE.  For methods that don't have a package (INV/UPD/ACK/PRA/MSG),
>> the method-only-context and user-context are the same.  So the "session"
>> and "early-session" C-D's are really for a user-context, but it's the same
>> context as method-only-context.  I don't know of any bodies which are
>> currently only for a method-only-context.(?)  Nor am I convinced we even
>> need this context to be defined separately.
>>> All-messages-context = the context is just the SIP message processing
>> rules common to all messages.  The target is the SIP message processor
>> common to all SIP messages.  The mandatory SIP headers (Call-ID, To, From,
>> etc.) are examples of things targeted for this context.  An AIB, geoloc,
>> and maybe sipfrag(?) bodies are targets for this context.
>>> Note on above: If you think of this as a layered model with an API, or
>> better yet a class object model - basically the all-messages-context is
>> for things needing to be handled/extracted in the base SIP message class,
>> the method-only-context is for stuff to be handled in a derived class for
>> a given method, and the user-context is for stuff to be handled by a
>> derived class from that for a given package, which may just be the same
>> class for some methods (INV/UPD/etc.).
>>> Rules:
>>> 1) Any body-part with a C-D of "render", means to render it to the
>> "user" - not the human user, but the *user-context*.  This lets us get
>> backwards-compatibility for free, because a C-D of "render" is implicit
>> and what current SIP messages actually have and UA's expect.  That C-D
>> becomes the "default" so to speak, which it already is today.
>>> 2) Any package (event of info) can define additional C-D's that belong
>> to it, just like they can define C-T's that they support.  I am not
>> entirely thrilled with letting packages define C-D's, but some already do
>> ("signal", for example).  If we'd rather just grandfather those and say no
>> more that's fine.  ISTM that a package could get that semantic purpose
>> information from within the boy content itself (in XML, for example) if it
>> really needs such.  Methods already do too, like "session" or "early-
>> session".  If we decide packages can have their own C-D's, then we need
>> additional rules not to step on body parts for others, but I'll skip that
>> for now.
>>> 3) Any body-part that is NOT for the user-context, for example a geoloc,
>> needs to disambiguate itself from the rest, by using a C-D other than
>> "render" or the ones already defined.  If it needs a sub-context other
>> than the all-messages-context, or is in fact tied to a SIP header, then it
>> needs to use CID, and a C-D of "by-reference".  I would in fact suggest
>> that all future extensions which need to be for something other than the
>> user-context MUST have a referencing SIP header and use a CID and a C-D of
>> by-reference.
>>> 4) Furthermore, any future extension which is not for the user-context
>> MUST NOT use any C-T currently defined in any RFC or WG draft for SIP,
>> including already defined event-packages.  That sounds harsh, but that's
>> what we need to do to get a very high degree of backwards-compatibility I
>> think.  So this means you can't do a geoloc-type thing using "text/plain",
>> for example, or really even "application/pidf+xml", which is what geoloc
>> currently uses in its draft.  And body-handling or some other draft should
>> list all such C-T's, so future extensions can know the list to avoid.  And
>> if we want to just say no C-T currently define by IANA period, I'm fine
>> with that too.  Note this does NOT prevent future SIP RFCs from using a C-
>> T defined by such an extension as geoloc.  For example, if geoloc uses
>> "application/foobar", then a future Event-package could use that too;
>> because that future event package would normatively reference body-
>> handling.
>>> 5) IF we need an option tag (and I do NOT think we do), then we should
>> create one and only one tag right now, for the body-handling draft's
>> logic.  Future extensions which are not for the user-context would then
>> NOT need more option tags simply due to body-handling issues, but can use
>> that generic one.  I would also put in some extreme language into the
>> body-handling option tag about what it means to put such a thing in a
>> Require header, to dissuade people from doing that.
>>> 6) If there are some already defined things which do not follow the
>> above rules, we either (a) grandfather them into body-handling right now,
>> or if they're not really in use, then either (b) deprecate or (c) replace
>> them. (and I would vote for (b), fwiw)
>>> -hadriel
> 

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Burger <[email-masked]>
Date: Mon, 12 Jan 2009 19:57:06 -0500

So I went with C-D for the last round of INFO.  This isn't e-mail, so  
matching the C-D with the method, on a per-method basis, works in all  
cases, as the C-D is a unique (because of the IANA registry) and the  
method defines it. Thus no one will use INFO's C-D for something else  
(unless they want to get slapped silly).

On Jan 8, 2009, at 9:17 AM, Gonzalo Camarillo wrote:

> Hi,
>
> by now, most people should be back from their vacation. I will wait  
> a few days for further comments and, if everybody is happy with the  
> current draft and no one proposes new text, we will go ahead request  
> its publication.
>
> Thanks,
>
> Gonzalo
>
> Hadriel Kaplan wrote:
>> I think that's really a question for the others (Paul, Dean,  
>> Eric).  I interpreted body-handling to address the issue already,  
>> but maybe not the backward compatibility issue.
>> Also, section 8.1. talks about the context being defined by the  
>> method, C-D and C-T.  It should probably mention that the Event  
>> package for SUB/NOT/PUB and soon the Info-Event package narrows the  
>> context further.  And I'm not sure that C-T has anything to do with  
>> defining a context.
>> -hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jan 2009 09:29:09 -0500

Eric Burger wrote:
> So I went with C-D for the last round of INFO. 

I still haven't found time to review the latest. But you have now 
increased my motivation to do so!

> This isn't e-mail, so 

Well...

(Here it comes: Paul's exception to the rule)

I might find some reason to put part or all of an INFO message in a 
sipfrag, and then send it to someone in a non-INFO message. (I haven't 
worked out a real use case yet.) So, will I get slapped silly for that? 
I think the  context for interpreting that is determined by the 
container it is in, so it shouldn't be a problem.

	Thanks,
	Paul

>>> I think that's really a question for the others (Paul, Dean, Eric).  
>>> I interpreted body-handling to address the issue already, but maybe 
>>> not the backward compatibility issue.
> ------------------------------------------------------------------------
>

---

From: Eric Burger <[email-masked]>
Date: Tue, 13 Jan 2009 10:01:46 -0500

On Jan 13, 2009, at 9:29 AM, Paul Kyzivat wrote:
>> This isn't e-mail, so matching the C-D with the method, on a per- 
>> method basis, works in all cases, as the C-D is a unique (because  
>> of the IANA registry) and the method defines it. Thus no one will  
>> use INFO's C-D for something else (unless they want to get slapped  
>> silly).
>
> Well...
>
> sipfrag, and then send it to someone in a non-INFO message. (I  
> haven't worked out a real use case yet.) So, will I get slapped  
> silly for that? I think the  context for interpreting that is  
> determined by the container it is in, so it shouldn't be a problem.

Fair enough. In fact, using C-D as the tag makes your scenario work!

>>> by now, most people should be back from their vacation. I will  
>>> wait a few days for further comments and, if everybody is happy  
>>> with the current draft and no one proposes new text, we will go  
>>> ahead request its publication.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>> Hadriel Kaplan wrote:
>>>> package for SUB/NOT/PUB and soon the Info-Event package narrows  
>>>> the context further.  And I'm not sure that C-T has anything to  
>>>> do with defining a context.
>>>> -hadriel