Re: INFO Framework - one pakage per INFO
Hadriel Kaplan <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <E6C2E8958BA59A4FB960963D475F7AC31374B1F161@mail> |
> -----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? 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 [email protected] for questions on current sip Use [email protected] for new developments on the application of sip