Re: multiple bodies in any SIP message

Hadriel Kaplan wrote:
> [breaking this up 'cause it's getting long in the tooth]
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[email protected]]
>> Sent: Monday, December 08, 2008 10:34 AM
>>
>> 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.)
> 
> Right but I think those C-Ds only have meaning in a user-context: one for INVITE, UPDATE, ACK, and PRACK.  No?  I wasn't implying that a C-D or body-part could not apply to the user-context of multiple methods.  Just that the "target" of the body was the user-context.

I'm still having trouble on the fringes defining user-context.
In this case its something like dialog-usage context. That would work 
for events too, since each has its own dialog-usage. It would also, I 
think, work for *legacy* INFO.

But it doesn't work for info-packages. All the info packages are within 
a single invite-dialog-usage. Yet each has its own context.

So getting all the terminology to work right is tricky. But I think I 
agree with the gist of what you are saying.

>> 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.
> 
> Right, but if we don't allow INFO to carry app-level responses in the INFO's response, then it's actually ok because it's really the user-context layer making that decision, and user-context is already method-specific.  In other words, if you think of it as that class object hierarchy way, the base message class doesn't need to know/care whether INFO responses can or cannot have user-context bodies - it always assumes yes.  Only the derived class for an INFO needs to know.

OK.

> (and BTW I'm not sure there is general consensus yet on whether an INFO response can contain a body or not - PUBLISH can, for example)
> 
> 
>> 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.
> 
> True, good point.  We can just grandfather that as an exception to the rule and say "multipart/mixed" needs to be checked for C-Ds internally to figure out which parts belong to what, it its C-D is "render".

OK. I think we agree. Again it may be a little tricky to scope the 
exception properly.

	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