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
