Re: [Sip] INFO Framework - one pakage per INFO

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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?  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?)


> > 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip