Hadriel Kaplan wrote:
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
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, then
Is 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
