Re: Body handling - Contexts WAS (Re: multiple bodies in any SIP message)

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
>>> -----Original Message-----
>>> From: Gonzalo Camarillo [mailto:[email protected]]
>>> 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 protected] [mailto:[email protected]] 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 protected] for questions on current sip
Use [email protected] for new developments on the application of sip