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

On Jan 13, 2009, at 9:29 AM, Paul Kyzivat wrote:
> 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 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...
>
> (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.

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

> 	Thanks,
> 	Paul
>
>> 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

_______________________________________________
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