[note: changing the thread to be consistent]
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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