Re: multiple bodies in any SIP message

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


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

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

-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