>>The bottom line is that whether to downgrade is a valid >>policy issue, and we shouldn't arbitrarily block it from working.
I would agree with this. I think a UA user would always like the most secure call possible. If the user only wants secure calls, then it can configure that on the phone and so this would block any automatic downgrade. In an other situation, the user could hear a warning tone or message saying that the security downgrade is about occur. Then if the user doesn't like it they can just hang up. As Paul says, downgrade is valid. Regards, Attila -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: 27 July 2007 00:17 To: Robert Sparks Cc: IETF SIP List; Francois Audet Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418 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 _______________________________________________ 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
