Re: multiple bodies in any SIP message

Hadriel,

There is good stuff in here. I've been trying to say some (not all) of 
the same things, but haven't done as good of a job of it.

I'll also observe that this is the discussion I was hoping would come 
out around the body-handling draft. I guess it was too abstract then, 
and took a specific use case to get people thinking about it.

More (a lot more) inline...

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.

I think this teasing apart of various processing contexts is very 
useful. It may need some tweaking, but certainly seems on the right 
track, and maybe well town the track. This is really an extension to the 
architectural model of sip, and we shouldn't discount its importance.

The C-Ds of "session" and "early-session" are unusual in that they can 
appear in a number of requests and responses. I guess these *could* be 
defned as user-context, or method-only-context, or all-messages-context. 
(Regardless of which context they are associated with, there need to be 
some special rules for how they can be used.)

Note that all of these can be in responses. Yet in the INFO case we 
aren't allowing use in responses. So again I think we have a *general* 
mechanism that may be used in requests and responses, and potentially 
special restrictions that are applied to particular cases.

There is another ugly special case that hasn't been mentioned: multipart 
bodies themselves. At least an outermost multipart/mixed needs to be 
handled as all-messages-context *by default* for backward compatibility. 
That means when it is C-D of "render", since that is the default for it.

I guess a multipart/mixed that has some other C-D need not be treated 
that way. E.g. there could be one with C-D of "by-reference", and some 
header that references it. But maybe that needs to be forbidden to 
ensure some existing app doesn't misinterpret it. But if it were 
forbidden, I don't know what someone would do if that is what they need.

> 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.

This seems right, at least for *outer* body parts. Once you get inside a 
multipart whose handling has already been determined by a C-D at that 
outer level, I'm not certain what to do with C-Ds that appear on the 
contained parts.

> 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.

This seems to be building on Christer's proposal. Up to a point I think 
its probably ok. I was thinking that we didn't need to go this far, but 
maybe we do.

The notion of C-D is not unique to SIP, so there are C-D types out there 
that say nothing about their relationship to SIP. And of course there 
are C-Ds that we will define as being associated with the method-only or 
all-messages contexts.

So, I think a new C-D could be defined for use with a particular 
package. But to do so it would, I think, require an RFC. (Whatever the 
rules are for new C-D types.) Since we aren't going to require an RFC 
for info-packages, an info-package that needs a new C-D would still need 
an RFC. I also think an info-package could potentially specify that a 
particular (existing) C-D be associated with its user-context - as long 
as that C-D isn't associated with a message- or all-messages- context.

> 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.

I agree with this, for the most part.

IMO the key is that when a body part is referenced from a header, the 
*reference* defines one sort of processing for the body part. Generally 
speaking you don't want any *other* processing to happen to it based 
simply on its presence. The by-reference C-D is, IMO, really just a 
context that has no *implicit* processing based on its presence.

*In principle* there could be a body part that is referenced more than 
once, in which case it would be processed once for each reference. 
Similarly, there could be a body part that is present and intended to be 
processed based on its context, and there is *also* a reference to it 
that should be processed based on the reference. This is not a likely 
case by any means, but I think it is cleaner to separate the two 
mechanisms. Using the same body for both then just falls out. An 
(unlikely and generally nonsensical) example might be a PUBLISH request 
containing a presence body, that also has a Geoloc header referring to 
the same body part.

To summarize my point: the C-D of a body part provides a way to identify 
a context that in turn defines some processing to be performed on that 
part. A cid-reference to a body part *also* provides a way to define 
some processing to be performed on a part. Either, both, or neither may 
apply to any given body part. (The *neither* is important, because there 
may be a reference in an optional header that isn't processed by the 
recipient.)

> 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. 

I agree it sounds harsh. IMO it is *too* harsh. That may mean I can't 
include an application/sdp in a MESSAGE, or in an info-package, even if 
it carefully *doesn't* use C-D of "session".

I think we should assume that complying UAs *should* be using C-D 
already to disambiguate, and they are simply broken if they don't.

> 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. 

This is a poster child for the problem. AFAIK "application/pidf+xml" is 
appropriate for its use, and forcing it to define a new C-T for the same 
thing in order to get around this would be a pain. At least in this case 
the possibility of conflict with non-conforming implementations isn't 
great because Geoloc isn't likely to be needed in PUBLISH or NOTIFY 
where conflicts might be possible.

But Geoloc should use "by-reference" when it doesn't want the body 
processed other than as a result of the header reference.

> 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.

I agree we should further discuss the backward compatibility issues. But 
I think we need not / should not be quite so resrictive.

> 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)

I agree with this.

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