Francois
I just don't see the difference between a 480 and a 400 in this case.
Either way, the UAC is left clueless, and hopeless (because it
doesn't understand the real reason things went south).
I prefer telling the UAC what the error was. This is making a policy
decision for the user of the UAC at the protocol level without their
ability to make a choice, while blinding them to what actually happened.
I can give lots of examples outside of calling where this would be
endlessly frustrating, and a few that are within calling...
At 05:21 PM 7/26/2007, Francois Audet wrote:
Hi James,
The specific reason why many were advocating a 480 instead of a new
error code is exactly because they did NOT want the error code
to encourage UAC to reattempt the request by downgrading to
SIP automatically.
This is the point that Eric Rescorla was making in the meeting, and
it has been re-iterated in one way or another by both Jon Peterson
and by Rohan Mahy.
You *could* of course with this approach use a reason phrase in the
480 to provide a message to the user of what the issue is.
> -----Original Message-----
> From: James M. Polk [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 26, 2007 14:31
> To: Audet, Francois (SC100:3055); IETF SIP List
> Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
>
> At 04:03 PM 7/26/2007, 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).
>
> (BTW 419 is used by Cullen's hashcash draft)
>
> >Another proposal was to use only one (i.e., 418 with 2 new headers).
>
> I would advocate this proposal, especially verses a 480, as a
> (new) Reason code to give the specifics can easily be
> stripped along the way back to the UAC, leaving it clueless
> as to what the actual problem was. Also not all
> implementations support Reason (though they should).
>
> A 418 is specific to the point of what was wrong.... and all
> UACs have to deal with the fact they can become a 400 (thus
> removing the details)
>
>
> >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
