Is the 480 intended to be *indistinguishable* from a 480 returned as a
result of no registrations at all? Or is it intended to be
distinguishable but more obscure than an explicit error response?
I think it needs to be distinguishable, one way or another.
The reason is that there are UIs where it makes sense to downgrade. For
instance:
The input to the UI of the UA is just a dial string, not a URI. It is up
to the UA to decide what scheme to apply. It can do this based on
policy, or perhaps based on a "secure" button on the phone. Typically
the user won't know whether a particular number should be sip or sips.
(Or even what that means.) The phone may decide to try sips first and
downgrade to sip if the sips doesn't work. If sips works then it can
display some sort of indication that the call is more secure than if sip
is used.
If the UA can't tell why the sips request failed then it will have to
retry the call in all cases.
The bottom line is that whether to downgrade is a valid policy issue,
and we shouldn't arbitrarily block it from working.
Paul
Robert Sparks wrote:
I think the 480 approach described below is the right thing to do.
RjS
On Jul 26, 2007, at 4:03 PM, Francois Audet wrote:
In the meeting, the issue of the error code to be used when the wrong
URI is
used in a request-URI (i.e., sip instead of sips, or vice-versa) came
up.
The status quo is 2 new error codes (418 and 419). Another proposal was
to use only one
(i.e., 418 with 2 new headers).
That proposal did not seem to get much traction. And people were not
very with the
status quo either.
Another proposal was to use 480 (Temporarily Unavailable) and NOT to use
an explicit
indication of the required/supported URIs (SIP, SIPS, etc.). Of course,
one can always
put text in the reason phrase to describe the error for displaying to
the end-use.
After talking to all the individual who seemed to have strong opinions
on this topic,
it appears that the 480 approach is the preferred approach.
Please let the list know if you are strongly opposed to this outcome,
along with the
reasons behind your opposition.
This is the last remaining issue to be closed in the draft, as a result
of WGLC.
_______________________________________________
Sip mailing list https://www1.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://www1.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://www1.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
