Re: [Sip] multiple bodies in any SIP message

[Hadriel Kaplan <HKaplan at acmepacket.com>]

[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
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip