Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418

From: "Attila Sipos" <[email-masked]>
Date: Fri, 27 Jul 2007 06:33:04 +0100

>>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-masked]] 
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-masked] for questions on current sip Use 
>> [email-masked] 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-masked] for questions on current sip Use 
> [email-masked] 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-masked] for questions on current sip Use
[email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip