Dale, I guess it would be application specific. For example, a missing version field in SDP could generate a 6xx class response (thus aborting any other forks). An unknown XML element could be an extension, so it shouldn't generate a 6xx response. An XML syntax error (e.g. missing closing tag) on the other hand might generate one
I guess sending a 6xx would depend on the definition of "foreseen extensions". Since these are usually not well defined, I guess 4xx is the safest choice in many cases Thanks, Jeroen ----- Original Message ----- From: "Dale R. Worley" <[EMAIL PROTECTED]> To: "Sip-Implementors" <[email protected]> Sent: Friday, April 07, 2006 3:31 PM Subject: Re: [Sip-implementors] best response code for bad request body > On Fri, 2006-04-07 at 08:40 +0200, Jeroen van Bemmel wrote: >> Wouldn't a 6xx class response be better? Since the UAS can determine that >> it >> will fail globally, perhaps a 606 (Not Acceptable, global equivalent of a >> 488) would be better? > > That's a fascinating idea... I have always had a violent dislike of the > 6xx responses (as one of those means that the UA is speaking for the > entire universe of UAs that might be receiving forks of the call). But > if the request body violates the applicable standards, the UA could > determine that no UA should accept the request. So it is sensible to > give a 6xx response in this situation. > > But I think that using a 4xx would still be preferable, because the UA > might be mistaken in its judgment about the request body, or the > requester might intend the request for a UA that would accept the out- > of-specification request body. > > What do you think? > > Dale > > --- > interop.pingtel.com -- the public SIP phone interoperability test server > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
