Keith,
OK, I am willing to give up on the Reason phrase.
We already have precedent (488) for a 4xx response indicating trouble
with the content of a body. At the moment it seems to be specific to SDP.
The question is:
- can we use 488/606 to mean trouble with some other kind of body?
- or must we reserve 488/606 for SDP. If it is only for SDP:
- can we have a different code to mean "other body trouble"?
- or must we settle for 400 for this?
I'm willing to live with 400 if that is what others prefer.
I am ambivalent about generalizing 488.
Another code would be nice, but I think we will spin awhile getting
agreement on it.
Thanks,
Paul
DRAGE, Keith (Keith) wrote:
I don't want to go this way at all.
I guess I could live with a 4xx - 6xx response being an implicit indication of
failure of a INFO request, even it is caused by the application, rather than
analysis at the SIP level.
As soon as you want detail of the failure, that has to be an application level
information, and it has to be transferred as an INFO package body, and in my
view that still has to go in another INFO request, and not in the response.
And for the Reason header proposal/suggestion below, any standards track RFC
can define the usage of Reason in response, but to my mind this changes the
semantics of the Reason header way beyond its original intention.
regards
Keith
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Kyzivat
Sent: Tuesday, December 02, 2008 8:28 PM
To: Hadriel Kaplan
Cc: SIP List
Subject: Re: [Sip] INFO Framework - one pakage per INFO
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
_______________________________________________
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
