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

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.

	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