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
