Hadriel Kaplan wrote:
-----Original Message----- From: Paul Kyzivat [mailto:pkyzivat at cisco.com] Sent: Tuesday, December 02, 2008 1:36 PM - *some* error code that can be returned as the response to INFO, which indicates: I didn't like the *content* of the package. If we have a single response that can be used for that, thenIs there some reason you need a different response code than 415 or 400? Do you think the UAC can take some different automated action due to getting back a 488-type response than a 400, for example?
I hate using the -00 responses because they are so vague. If worse comes to worse then 400 can be used with a phrase to describe the actual problem. That can be enough for debugging. (I don't really expect anybody is going to recover from these errors.) But if somebody responds to me with this sort of error I would like to be able to tell that is the problem without having to talk to a developer of the responding device.
The main thing is to give guidance on what error should be used.
[I personally hate new response codes - middleboxes always seems to be asked to map them to a different number.]I expect that Reason can be used to refine it.Unless this has changed, I thought the Reason header was only allowed in requests? (even though I know people put it in responses, and honestly it was silly to only apply it to requests to begin with)
The Reason header field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field.AFAIK there are no responses that allow it. But we could make a normative change to do so, to whatever response code we decide should be used. Or we can just punt this to the reason-phrase of the response.
Thanks, Paul _______________________________________________ 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