inline.
Paul
P.S. Its a pity that we haven't anything better to do on a holiday
weekend. :-)
Hadriel Kaplan wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul
Kyzivat
Sent: Friday, November 28, 2008 5:22 PM
If you want to do it that way, then I suggest we use C-D (with a new
disposition type) to define the info-package, and make that new
disposition type be the default CD for INFO messages.
Hmm... interesting idea. So define a single, global C-D value like "package", which all packages use?
Yes, that is what I had in mind.
Wouldn't that limit what a specific package could do? (like how would you get a
package that wants render, vs. icon, vs. one which wants signal?)
If it wants bodies like that, which are processed based on their type
and disposition, it can just include them for processing in their own
right independent of the method.
For actual info package bodies, the handling should be determined by the
definition of the info package, not by the content disposition. If we
are identifying the body of the info package via cid, then the c-d of
the info package should be by-reference as defined in the body handling
draft.
Send the 200 OK and let the application sort out the body. SIP has done
its job - don't be a layer violator and conflate an application error
with a transport error!
I don't think I agree with this, but it could stand some further
discussion. Are you asserting this behavior is special for INFO? Or that
it is true for all messages?
I don't find anything in 2976 that calls for a success response when the
content of the body is incorrect.
Yeah there's no debate that SIP expects INVITE/UPDATE to be handled integral
with body processing. What's always been argued is how to handle things like
MESSAGE, SUB/NOT and INFO. Several people have argued the body part content of
those was at a higher layer. The text in SUB/NOT RFC only defined a response
code for bad Event-types or unknown body content-types I think, but left body
processing failure out of it. And none of the packages seem to go any deeper
as far as I can tell.
Of course in practice some (many?) devices respond with failure codes when body
processing fails no matter the method.
Wasn't this debated a couple few ago on this list?
-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
_______________________________________________
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
