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

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Jul 2007 16:03:19 -0500

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 26 Jul 2007 16:30:50 -0500

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)

>very with the status quo either.
>
>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.
>
>on this topic, it appears that the 480 approach is the preferred approach.
>
>along with the reasons behind your opposition.
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Jul 2007 16:49:35 -0500

I think the 480 approach described below is the right thing to do.

RjS

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Jul 2007 17:21:39 -0500

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-masked]] 
> 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
> 
> >URI is used in a request-URI (i.e., sip instead of sips, or 
> vice-versa) came up.
> >
> 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)
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Jul 2007 23:37:36 +0100

Francois,

I am reasonably happy with this proposal, BUT I must point out the
following from RFC 3261:
"If the Request-URI indicates a resource at this proxy that does not
   exist, the proxy MUST return a 404 (Not Found) response.

   If the target set remains empty after applying all of the above, the
   proxy MUST return an error response, which SHOULD be the 480
   (Temporarily Unavailable) response."

Doesn't this fit into the first category, suggesting that 404 would be
appropriate? Or do we regard the existence of an AoR as meaning that
both SIP and SIPS resources exist, even if one or other has no
registered contacts?

John

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 26 July 2007 22:03
> To: IETF SIP List
> Subject: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Jul 2007 17:41:59 -0500

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, July 26, 2007 15:38
> Subject: RE: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
> 
> Francois,
> 
> I am reasonably happy with this proposal, BUT I must point 
> out the following from RFC 3261:
> Doesn't this fit into the first category, suggesting that 404 
> would be appropriate? Or do we regard the existence of an AoR 
> as meaning that both SIP and SIPS resources exist, even if 
> one or other has no registered contacts?

Basically, 480 is the error code that is supposed to be used when
the user is known to exist (i.e., the AOR is in the database), but 
he is not "logged-in" at present. So the presence of the AOR does
mean that both the SIP and SIPS AOR exist, but they don't necessarily
have a binding assigned to it at the time. Thus the 480.

That's the feedback I got from others.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 26 Jul 2007 17:59:32 -0500

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...

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2007 19:17:16 -0400

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 27 Jul 2007 01:59:07 -0400

I agree with Paul mostly. 
Especially since I think we would also want the UAC to *upgrade* if it tried
sip but the AoR was only registered at sips. (note I mean the UAC upgrading,
not the proxy of course)
Obfuscating the error seems wrong. (clever though :)

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, July 26, 2007 7:17 PM
> To: Robert Sparks
> Cc: IETF SIP List; Francois Audet

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 27 Jul 2007 17:08:15 +1000

I also agree with Paul's views. Can someone elaborate as to why it is not
desirable for a UAC to retry automatically? This could be a check box in the
setting menu.

Regards,
Hisham

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Jul 2007 09:35:12 -0500

The intent is to be UNDISTINGUISHABLE.

We do NOT want the equipment to automatically downgrade. We want
the user to make the decision in a concious way.

Furthermore, we want to emphasise that the SIP and SIPS are 
different addresses and are not interchangeable.

Rohan Mahy, Jon Peterson, Eric Rescorla,

Since you were the main people advocating this change, can 
you make clear on the list what the rationale is.

Thanks.

> Sent: Thursday, July 26, 2007 16:17
> To: Robert Sparks
> Cc: Audet, Francois (SC100:3055); IETF SIP List
> 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?
> 
> 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:
> >> 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).
> >>
> >> 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.
> >>
> >> This is the last remaining issue to be closed in the draft, as a 
> >> result of WGLC.
> >>
> >>
> >> 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
> > 
> > 
> > 
> > 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
> > 
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Jul 2007 09:40:11 -0500

400 == Bad Request (i.e., there is something wrong with it)

480 == Temporarily Unavailable (i.e., there is currently no
       Contact binding associated with the URI) 

If I send a request to a SIPS Request-URI and there is no
current binding to a SIPS Contact, then I will receive a
480.

If I send a where the Request-URI is SIPS, but the Contact
is SIP, then I get a 400.

> Sent: Thursday, July 26, 2007 16:00
> 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...
> 
> >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.
> >
> 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).
> > >
> > > 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.
> > > >
> > > and NOT to use
> > > >Please let the list know if you are strongly opposed to this 
> > > >outcome, along with the reasons behind your opposition.
> > > >

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2007 07:58:20 -0700

You mean, security through obscurity? I guess it's about par for
SIPS course.

       Mike

Francois Audet wrote:
>>>> In the meeting, the issue of the error code to be used 
>>>>         
>> when the wrong 
>>     
>>>> That proposal did not seem to get much traction. And 
>>>>         
>> people were not 
>>     
>>>> Please let the list know if you are strongly opposed to 
>>>>         
>> this outcome, 
>>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Jul 2007 10:06:18 -0500

Oh, please with the rethoric. 

Again, the idea is that a sip address is different than a sips address.

If you use a sip address when a sips is expected, then you'd get 
the behavior you'd get for when there is no binging assigned.

It's as simple as that.

> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Friday, July 27, 2007 07:58
> To: Audet, Francois (SC100:3055)
> Cc: Paul Kyzivat; [email-masked]; Rohan Mahy; Eric 
> Rescorla; IETF SIP List
> You mean, security through obscurity? I guess it's about par 
> for SIPS course.
> 
>        Mike
> 
> Francois Audet wrote:
> > We do NOT want the equipment to automatically downgrade. We 
> want the 
> > user to make the decision in a concious way.
> >
> > Since you were the main people advocating this change, can you make 
> > clear on the list what the rationale is.
> >
> > Thanks.
> >  
> >
> >   
> returned as 
> >> a result of no registrations at all? Or is it intended to be 
> >> The reason is that there are UIs where it makes sense to 
> downgrade. 
> >> For
> >> instance:
> >>
> 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"
> >> display some sort of indication that the call is more 
> secure than if 
> >> sip is used.
> >>
> policy issue,

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jul 2007 11:06:25 -0400

I understand that if the user entered a sips URI then it should be the 
user that must decide to downgrade. But if the user didn't know whether 
to use sip or sips in the first place, and the UA decides to try sips 
first then I see no problem in the UA having a policy that causes it to 
downgrade.

This is highly related to how security is managed in the user interface.

	Paul

Francois Audet wrote:
>> downgrade. For

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 27 Jul 2007 10:20:31 -0500

Hi,

I think 480 has the correct semantics.  When an authoritative proxy  
has no Contacts registered for a resource (in this case it is a  
"sips" resource), the correct response code is 480.  In addition we  
don't want the UAC to automatically downgrade because it mistakenly  
thinks that's the right thing to do.

My intent however was not to make this indistinguishable, since I  
proposed adding a Warning: header.  I think  it is useful to have the  
reason there where no relevant Contacts.

thanks,
-rohan

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2007 08:24:01 -0700

I don't see the point in parsimony on return codes unless you're trying to
obscure something. And I don't find "We don't want [...]" particularly
compelling as it implies there's a one-size-fits-all on UI design. Were
SIPS an end to end mechanism there _might_ be a case to be made (and
I'd be extremely dubious even then), but it's far more broken than that
so making proscriptions against this or that is rather pointless.

Never try to teach a *pig* to sing; it wastes your time and it *annoys 
the pig*. *...* Mark *Twain

       Mike
*
Francois Audet wrote:
>> different 
>>> addresses and are not interchangeable.
>>>
>>>> (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 
>>     
>>>> If the UA can't tell why the sips request failed then it 
>>>>         
>> will have to 
>>     
>>>>>> etc.). Of course, one can always put text in the reason 
>>>>>>             
>> phrase to 
>>     
>>>>>> [email-masked] for questions on 
>>>>>>             
>> current sip Use 
>>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Jul 2007 10:32:48 -0500

On the Warning header...

Values 300-379 are reserved for SDP-related stuff.

Values 380-389 are unassiged (but there is no text on it).

Values 390-398 are unassigned (but don't fall into the SDP
related stuff. 

399 means Miscellaneous and the text can be provided to the user.
It further says that Automata MUST NOT take action based on this.

Rohan, are you advocating using 399, or defining a new code from the
390-398 space?

> From: Alan Hawrylyshen [mailto:[email-masked]] On 
> Behalf Of Alan Hawrylyshen
> Sent: Friday, July 27, 2007 08:27
> To: Kyzivat Paul; Mahy Rohan
> Cc: Audet, Francois (SC100:3055); IETF SIP List; 
> [email-masked]
> On 27-Jul-2007, at 10:06 , Paul Kyzivat wrote:
> 
> > user that must decide to downgrade. But if the user didn't know 
> > whether to use sip or sips in the first place, and the UA 
> decides to 
> > try sips first then I see no problem in the UA having a policy that 
> > causes it to downgrade.
> 
> I was under the impression (based on meeting discussion) that :
> 1 - the downgrade was undesirable because it reveals 
> (possibly) information about the targeted party in the clear, and;
> 2 - The 480 with a Warning header was an option to provide 
> automata- friendly indication of the failure reason.
> 
> Alan Hawrylyshen
> 
> a l a n a t p o l y p h a s e d o t c a
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jul 2007 08:37:26 -0700

At Fri, 27 Jul 2007 09:35:12 -0500,
> you make clear on the list what the rationale is.

Right. So, I want to avoid automatic downgrade. I think that
at minimum that means that we should avoid using a return
code ordinary associated with automatic retry. Better yet
would be to use a hard failure return code and then a textual
error message...

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2007 08:47:25 -0700

> would be to use a hard failure return code and then a textual

Do people seriously believe that any amount of protestation from the IETF
is going to prevent implementors from downgrading? If the receiver(s) really
don't want the SIP method, they don't have to accept them. If they do, 
then no
amount of hand wringing MUST NOT's is going to prevent the inevitable.

The only thing this kind of hand wringing is likely to produce is more
incompatibility between the puritans and the sinners.

       Mike

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 27 Jul 2007 11:02:12 -0500

Michael,

At issue here is what the default implementor is likely to do.  With  
a new 4xx, the misguided but well-meaning implementor is likely to  
try to "helpfully" "repair" the error without thinking about or  
understanding the security context.

Using a Warning code raises the bar significantly, but still allows  
automata to at least log what happened.

thanks,
-rohan

On Jul 27, 2007, at 10:47 AM, Michael Thomas wrote:

>>> Since you were the main people advocating this change, can you  
>>> make clear on the list what the rationale is.
>>>
>>
> don't want the SIP method, they don't have to accept them. If they  
> do, then no

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Jul 2007 11:05:41 -0500

> Do people seriously believe that any amount of protestation 
> from the IETF is going to prevent implementors from 
> downgrading? If the receiver(s) really don't want the SIP 
> method, they don't have to accept them. If they do, then no 
> The only thing this kind of hand wringing is likely to 
> produce is more incompatibility between the puritans and the sinners.

Doesn't this argue agaist your own previous email?

The 480 approach doesn't allow for automatic retry, because you
can't figure out from the error code that it might actually work 
by downgrading.

I'm am quite lost at understanding what concrete outcome you want
to see.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2007 09:39:06 -0700

Rohan Mahy wrote:
> Michael,
>
> At issue here is what the default implementor is likely to do.  With a 
> new 4xx, the misguided but well-meaning implementor is likely to try 
> to "helpfully" "repair" the error without thinking about or 
As I said, a receiver is completely at liberty to prevent the downgrade 
by not
accepting the downgraded request.  Problem solved by those who care. On
the other hand I think it's pretty presumptuous that we "know" in all cases
whether it's wrong to "repair" the error. Paul brought up several examples.
Also: if the receiver allows non-SIPS requests why shouldn't you infer that
they want you to "repair" the request? It sure seems like this is a 
misguided
attempt at forcing ineffectual nannyware which is a pointless enterprise for
IETF protocols.

       Mike

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 28 Jul 2007 20:24:43 -0500

A 399 Miscellaneous?  That doesn't make sense...

Warning codes are not limited to 3XX, so if a new Warning code is 
what Rohan wants to convey more information in the response (which I 
believe should be done one way or another) - it can be almost any 
value other than 300-379 or 399 IMO.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Jul 2007 22:04:28 -0400

Alan Hawrylyshen wrote:
>> whether to use sip or sips in the first place, and the UA decides to 
> 1 - the downgrade was undesirable because it reveals (possibly) 
> information about the targeted party in the clear, and;

Its only undesirable if the UAC had any expectation that the information 
would not be revealed. I repeat that this is largely a function of the 
UI and contract between the UI and the user. I don't think we can or 
should make assumptions about that that is.

> automata-friendly indication of the failure reason.

I don't have strong feelings about what the response is, so long as the 
particular case is distinguishable in some way.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Jul 2007 10:54:57 -0500

RFC 3261, p. 181:

	"The first digit  of warning codes beginning with "3" indicates
warnings
	specific to SIP."

Then it explains within the 3XX space, how they are used.

> Sent: Saturday, July 28, 2007 18:25
> To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat 
> Paul; Mahy Rohan
> Cc: IETF SIP List; [email-masked]
> Warning codes are not limited to 3XX, so if a new Warning 
> code is what Rohan wants to convey more information in the 
> response (which I believe should be done one way or another) 
> - it can be almost any value other than 300-379 or 399 IMO.
> 
> >Values 390-398 are unassigned (but don't fall into the SDP related 
> >stuff.
> >
> > > From: Alan Hawrylyshen [mailto:[email-masked]] 
> On Behalf Of 
> > > Alan Hawrylyshen
> > > > try sips first then I see no problem in the UA having a policy 
> > > > that causes it to downgrade.
> > >

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Jul 2007 10:55:09 -0500

Correct.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Jul 2007 10:54:57 -0500

RFC 3261, p. 181:

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Jul 2007 10:55:09 -0500

Correct.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Jul 2007 09:08:44 -0700

At Fri, 27 Jul 2007 09:39:06 -0700,
Michael Thomas wrote:
> accepting the downgraded request.

Unless, of course, someone is impersonating the receiver.

>  Problem solved by those who care.

Regrettably no.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2007 09:19:04 -0700

> Unless, of course, someone is impersonating the receiver.
Given how tangled up SIPS is, I really no idea what you're talking
about, or whether it's even responsive to my suggestion. Last I heard,
the entire raison d'etre of SIPS was that the next hop is cryptographically
identified via TLS. I'm guessing that you're not suggesting that TLS
is useless against impersonation attacks.

       Mike

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Jul 2007 11:38:45 -0500

In the interest of moving forward on this arcane issue of marginal
interest, I am making the
following concrete proposal.

Here are 2 alternatives. I'd like to have a virtual show of hands on
which option is 
preferred by people.

OPTION 1

	Use Response code 480, with new Warning header field 390 (URI
Scheme Not Supported)
	for both cases when SIP or SIPS is rejected.

	The proxy or UAS may use the warning text field to provide more
indications, e.g.:

	Warning: 390 isi.edu "SIPS Not Allowed"
	Warning: 390 isi.edu "SIPS Required"

OPTION 2

	Use Response code 480, with 2 new Warning headera field 390
(SIPS Not Allowed)
	and 391 (SIPS Required).

	The proxy or UAS may use the warning text field to provide user,
e.g.:

	Warning: 390 isi.edu "Please use a SIP URI"
	Warning: 391 isi.edu "A secure SIPS URI is required"

OPTION 1 has the characteristic of being "opaque" to Automatas, but it
is generic
enough to support other URI schemes. The precise reasons is described in
human-readable
format.

OPTON 2 has the characteristic of precisely describing the reason for
the rejection. It
is NOT opaque to Automatas. If new warnings are necessary for other URI
shemes, new warning
headers can be defined.

In both cases, existing UACs (or UACs that do not wish to have any
special behavior based
on this) will exhibit the desired behavior, i.e., it will look like
"temporarily unavailable".

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Jul 2007 12:17:32 -0500

> following concrete proposal.
. . .

> 	Warning: 391 isi.edu "A secure SIPS URI is required"

In the interest of coming to a conclusion, please sign me up for option 
2, but I'm willing to accept option 1 nearly as readily.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jul 2007 13:47:07 -0400

I am ok with either of these, though I somewhat prefer Option 2.

I don't know what you mean about Option 1 being opaque to automata. It 
seems to me it provides comparable info to Option 2, giving that the UAC 
knows what it used in the request.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Jul 2007 12:59:02 -0500

> Sent: Monday, July 30, 2007 10:47
> Cc: IETF SIP List
> I don't know what you mean about Option 1 being opaque to 
> automata. It seems to me it provides comparable info to 
> Option 2, giving that the UAC knows what it used in the request.

It means an Automata can not "upgrade" or "downgrade" automatically with
OPTION 1, as the indication is not a "hard" indication. It is a Warning
text
that is not standardized, and will vary by language, operators, region,
etc.

Best it can do is "record" the Warning text. That can be done
automatically
of course.

---

From: "Charles Eckel \(eckelcu\)" <[email-masked]>
Date: Mon, 30 Jul 2007 13:11:34 -0700

I do not have a real preference, but provided the reason for using 480 vs. 418 is to minimize naïve downgrading from SIPS to SIP, I do not see how option 2, resulting in:

480 

helps matters.

Cheers,
Charles

> Sent: Monday, July 30, 2007 10:59 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: IETF SIP List

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Jul 2007 15:21:34 -0500

Existing implementations would ignore the Warning, and normal treatment for 480
would occur. I.e., it would be the same treatment as if the user is recognized as
beeing a valid user, but he's currently not logged in.

With 418, existing implementations would treat it as 400. I.e., it would be
as if the message itself had an error.

This may need to different UI for the user (e.g., different tone played, different
message displayed, etc.)

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 13:12
> To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat)
> Cc: IETF SIP List
> I do not have a real preference, but provided the reason for 
> using 480 vs. 418 is to minimize naïve downgrading from SIPS 
> to SIP, I do not see how option 2, resulting in:
> 
> 480
> automata. 
> > > It seems to me it provides comparable info to Option 2, 
> giving that 
> > > the UAC knows what it used in the request.
> > 
> > OPTION 1, as the indication is not a "hard" indication. It is a 
> > Warning text that is not standardized, and will vary by language, 
> > operators, region, etc.
> > 
> > automatically of course.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Jul 2007 13:38:34 -0700

At Mon, 30 Jul 2007 09:19:04 -0700,
> is useless against impersonation attacks.

Of course not.

The point here is that if a caller automatically downgrades to SIP,
an active attacker can then intercept the request and accept it,
regardless of the receiver's preferences.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2007 13:54:41 -0700

> regardless of the receiver's preferences.

Um, so? That's the risk that the sender takes by sending stuff in the 
clear. And
where's the problem here anyway? The steps are: try SIPS, then try SIP. 
If the
first succeeds, there's no attack. So it's only in some slim window of 
when the
receiver was down, or something like that. Doesn't seem to me to be 
something
to get all exercised about, especially when you factor in all of the 
other insecurities
associated with SIPS.

       Mike

---

From: "Rai, Anupam (Anupam)" <[email-masked]>
Date: Mon, 30 Jul 2007 15:52:58 -0600

An active attacker could very well DoS the SIPS attempt making it look
like "reciever was down". Hence downgrade must never bet attempted under
such condition. There must be some explict indication, like the one
discussed here, to indicate that contact does not accept SIPS.

-Anupam

> Sent: Monday, July 30, 2007 1:55 PM
> To: Eric Rescorla
> Cc: IETF SIP List; Rohan Mahy; Francois Audet; Paul Kyzivat; 
> [email-masked]
> >>>>> At issue here is what the default implementor is likely to do.  
> >>>>> With a new 4xx, the misguided but well-meaning implementor is 
> >>>>> likely to try to "helpfully" "repair" the error without 
> thinking 
> >>>>> about or understanding the security context.
> >>>>>
> >>>>> Using a Warning code raises the bar significantly, but still 
> >>>>> allows automata to at least log what happened.
> >>>>>       
> >>>>>           
> >>>> As I said, a receiver is completely at liberty to prevent the 
> >>>> downgrade by not accepting the downgraded request.
> >>>>     
> >>>>         
> >> about, or whether it's even responsive to my suggestion. Last I 
> >> heard, the entire raison d'etre of SIPS was that the next hop is 
> >> cryptographically identified via TLS. I'm guessing that you're not 
> >> suggesting that TLS is useless against impersonation attacks.
> >>     
> >
> > Of course not.
> >
> > The point here is that if a caller automatically downgrades 
> to SIP, an 
> > active attacker can then intercept the request and accept it, 
> Um, so? That's the risk that the sender takes by sending 
> stuff in the clear. And where's the problem here anyway? The 
> steps are: try SIPS, then try SIP. 
> If the
> first succeeds, there's no attack. So it's only in some slim 
> window of when the receiver was down, or something like that. 
> Doesn't seem to me to be something to get all exercised 
> about, especially when you factor in all of the other 
> insecurities associated with SIPS.
> 
>        Mike
> 
> 
> [email-masked] for questions on current sip

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2007 15:02:24 -0700

And the way to deal with this is some obscure ietf nanny text in some 
document
that may or may not be read by developers? I'm sorry, but I don't find 
this a very
compelling way to go about fixing this kind of problem.

But if you're going to do this at all, at least instruct them that they 
should only
try the SIP downgrade at first contact, so that you don't have to keep 
exposing
yourself on subsequent invitations. Telling them to not do it at all is 
about the
worst advise because it will be ignored.

       Mike

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Jul 2007 15:08:34 -0700

At Mon, 30 Jul 2007 13:54:41 -0700,
> to get all exercised about, especially when you factor in all of the 

I'm not saying it's something huge to get exercised about. However, since
the question is what behavior to define here, we might as well get it
right.

-Ekr

---

From: "Hisham Khartabil" <[email-masked]>
Date: Tue, 31 Jul 2007 10:51:46 +1000

With a new 4xx response, existing implementations would treat it as 400
anyway.

In any case, option 1 is good enough, but I am not a fan of using reason
phrases as indicators to humans. I call someone is Japan and get a Japanese
string telling me 'SIPS required'. I would have no clue what its saying.

Hisham

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 30 Jul 2007 23:43:40 -0500

>Then it explains within the 3XX space, how they are used.

btw -- for location-conveyance-07, I created 15 new Warning codes (#s 
701 through 712, then 720, 721, and 722).  All this at the suggestion 
of Henning (who knows something about 3261 text...  ;-)

btw II - I have since replaced the Warning header indication with a 
new Geolocation-Error header, but this was so I could stuff more into 
the new header than the Warning header would allow.

In all this, I did not get one person claiming Warning codes were 
limited to 3XX.  Henning merely said the "first batch of codes were 
in the 300s, and that there was nothing limiting a new ID from 
defining new codes in any other number range"...

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Jul 2007 08:49:24 -0500

Ok, that's fine with me. It's just a glitch in 3261 then. I'd rather we
stick with the Warn-Codes approach.

Did you assign a purpose for 7XX-series warn-codes yet? I'm wondering
what
range should be used for this purpose.

James, I didn't see your codes on IANA's web site. What values are you
using?
I don't want to overlap.

> Sent: Monday, July 30, 2007 21:44
> >         "The first digit  of warning codes beginning with "3" 
> >indicates warnings
> >         specific to SIP."
> >
> 701 through 712, then 720, 721, and 722).  All this at the 
> suggestion of Henning (who knows something about 3261 text...  ;-)
> 
> btw II - I have since replaced the Warning header indication 
> with a new Geolocation-Error header, but this was so I could 
> stuff more into the new header than the Warning header would allow.
> 
> In all this, I did not get one person claiming Warning codes 
> were limited to 3XX.  Henning merely said the "first batch of 
> codes were in the 300s, and that there was nothing limiting a 
> new ID from defining new codes in any other number range"...
> 
> 
> > > To: Audet, Francois (SC100:3055); Alan Hawrylyshen; Kyzivat Paul; 
> > > Mahy Rohan
> > > believe should be done one way or another)
> > > > > > user that must decide to downgrade. But if the user didn't 
> > > > > > know whether to use sip or sips in the first place, 
> and the UA
> > > > > decides to

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 31 Jul 2007 09:04:24 -0700

Michael,

The semantics of a request to a sip: resource are different from a  
request to a sips: resource.  If there are no Contacts registered  
against a sips: resource, then the correct thing for the proxy to do  
is to send a 480.  This is the same thing the proxy would do if there  
were no Contacts registered against a sip: resource.

We are not talking about a ciphersuite downgrade here. Providing an  
error response code that encourages a client to downgrade is just  
plain irresponsible.

thanks,
-rohan

On Jul 27, 2007, at 9:39 AM, Michael Thomas wrote:
>> likely to try to "helpfully" "repair" the error without thinking  
> downgrade by not

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 31 Jul 2007 12:43:36 -0500

Francois

I don't believe it is a glitch so much as it is an initial range, 
which can be expanded with a PS RFC, especially one with an update to 
3261 (which you are doing).

I was using 7XX (assigning 701 through 739) - though I pulled the 
Warning codes from the conveyance draft, therefore I am no longer 
using these codes (since I created a new SIP header 
(Geolocation-Error) to accomplish the same task as the Warning codes 
plus add new information with header parameters for the new header).

My point was that it is possible to go outside the 3XX range for 
SIP... you just have to define it.

BTW - I am ok with the 480+Warning Code, but am cautious about the 
Warning header (with its 'why' information) being stripped along the 
way back to the UAC.

Ultimately, do we want zero communications between this UAC and UAS 
(because the UAC can always get a 480 without additional information 
letting it know what was really wrong with the request), or do we 
want to send the UAC something it can understand about this scenario?

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Jul 2007 12:51:17 -0500

> Ultimately, do we want zero communications between this UAC 
> and UAS (because the UAC can always get a 480 without 
> additional information letting it know what was really wrong 
> with the request), or do we want to send the UAC something it 
> can understand about this scenario?

Yes, we want the default to be a "hard failure" that looks like if the
target was not corrently registered.

That's the reasoning behind the 480.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 31 Jul 2007 17:25:08 -0400

Yeah but a 480 implies the resource is not available, whereas in reality the
resource *is* available using a different scheme.  I guess one question is
if the sips scheme literally means the UAS is a different "resource".  If
so, then registering a sips contact only should not implicitly make the UAS
available for routing plain sip.  The draft currently says they represent
the *same* resource.

I'm not convinced by the downgrade argument.  The far-end can just as easily
send a 3xx redirecting the UAC to the sip contact.  Per this new draft the
proxies must not recurse on that, and the UAC should inform the user before
doing so.  But I think a new 4xx response code would be much more likely to
make that a reality, as any vendor implementing support for recursing on a
418 would have read the draft and seen where it says "inform the user".  If
they didn't read the draft, they'd fail the request since they got an
unknown 4xx response. (compare that to a 3xx, which is known/usable without
reading this draft)  Am I missing the gist of the concern?

-hadriel

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2007 12:04 PM
> To: Michael Thomas
> Cc: Rohan Mahy; IETF SIP List; Francois Audet; [email-masked];
> Paul Kyzivat

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Jul 2007 16:50:39 -0500

480 means that the user identified by the Request-URI is recognized, but
there is currently no valid forwarding location for that user. In this
case,
no SIPS contacts.

What many people are missing in the 480 vs. 418 argument is the
following:

- Existing implementations will treat new 4XX error codes as 400,
  which basically means "the protocol message is broken".

- Existing implements will treat 480 with new Warning just like
  480 witn no warning, i.e., as "Temporarily unavailable".

There is a huge difference between the 2. 400 will lead you to believe
that there is something wrong with the equipment (i.e., you may file a
complaint with the manufacturer). Very bad.

480 just means the other end is not available at that address. Good. 
Everybody is happy.

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Tuesday, July 31, 2007 14:25
> To: 'Rohan Mahy'; 'Michael Thomas'
> Cc: 'IETF SIP List'; Audet, Francois (SC100:3055); 
> [email-masked]; 'Paul Kyzivat'
> Yeah but a 480 implies the resource is not available, whereas 
> in reality the resource *is* available using a different 
> scheme.  I guess one question is if the sips scheme literally 
> means the UAS is a different "resource".  If so, then 
> registering a sips contact only should not implicitly make 
> the UAS available for routing plain sip.  The draft currently 
> says they represent the *same* resource.
> 
> I'm not convinced by the downgrade argument.  The far-end can 
> just as easily send a 3xx redirecting the UAC to the sip 
> contact.  Per this new draft the proxies must not recurse on 
> that, and the UAC should inform the user before doing so.  
> But I think a new 4xx response code would be much more likely 
> to make that a reality, as any vendor implementing support 
> for recursing on a
> 418 would have read the draft and seen where it says "inform 
> the user".  If they didn't read the draft, they'd fail the 
> request since they got an unknown 4xx response. (compare that 
> to a 3xx, which is known/usable without reading this draft)  
> Am I missing the gist of the concern?
> 
> -hadriel
> 
> 
> > Cc: Rohan Mahy; IETF SIP List; Francois Audet; 
> > [email-masked]; Paul Kyzivat
> Problem solved 
> > > by those who care. On the other hand I think it's pretty 
> > > presumptuous that we "know" in all cases whether it's wrong to 
> > > "repair" the error. Paul brought up several examples.
> > > Also: if the receiver allows non-SIPS requests why shouldn't you 
> > > infer that they want you to "repair" the request? It sure 
> seems like 
> > > this is a misguided attempt at forcing ineffectual 
> nannyware which 
> > > is a pointless enterprise for IETF protocols.
> > >
> > >       Mike
> > 
> > 
> >

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Jul 2007 16:58:10 -0500

Hi all,

It seems from the mailing list discussion that the preferred approach is
to
use the 480 (Temporarily Unavailable) response code, with a Warning
header field.

The Warning header could use one of the following 2 newly defined
warn-codes:

   380  SIPS Not Allowed: The UAS or proxy can process the request
        because the SIPS scheme is not allowed (e.g., because there are
        currently no registered SIPS Contacts).

   381  SIPS Required: The UAS or proxy cannot process the request
        because the SIPS scheme is required.

If you cannot live with this approach, please voice your opinion.

Thanks.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 31 Jul 2007 19:01:16 -0500

At 04:58 PM 7/31/2007, Francois Audet wrote:
>    380  SIPS Not Allowed: The UAS or proxy can

s/can/cannot

>process the request

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 31 Jul 2007 20:14:59 -0700

The resource that was requested (sips:[email-masked]) is NOT  
available.  There may be a related but different resource available,  
so it is nice as a courtesy to provide this information, but the  
basic semantics should still be a 480.

thanks,
-rohan

On Jul 31, 2007, at 2:25 PM, Hadriel Kaplan wrote:

>>> infer that