Subject: RE: [Sip] Re: draft-ietf-sip-sips-03

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Apr 2007 16:03:00 -0500

Hi Hans,

Thank you for your careful review. I will incorporate all your changes and request
for clarification in the next version of the draft.

You had one question buried in there that I think deserve attention from the group:

> In general, I feel that I don't understand the reasoning 
> behind when to respond 403 and when to respond 404 in this draft.
 
Basically, I've used 403 (Forbidden) when a UAC tries to register with the wrong
scheme in the Contact.

And I've used 404 (Not Found) when a UAC sends a non-REGISTER request to a SIP URI when only a SIPS URI exists for that resource. I used to have 403 for that, but I received
some comments from somebody on the list that 404 (Not Found) would be more appropriate.

I don't feel strongly about this issue.

If anybody has any ideas, please go ahead. 

> -----Original Message-----
> From: Hans Persson [mailto:[email-masked]] 
> Sent: Friday, April 27, 2007 08:15
> To: SIP IETF
> Cc: Audet, Francois (SC100:3055)
> Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
> 
> sön 2007-03-18 klockan 23:27 -0400 skrev Paul Kyzivat:
> 
> > Just read the most recent version. Its looking good to me. 
> Just a few 
> > typo comments.
> 
> And so did I, just now.
> 
> I have a few comments and questions and a slew of nits.
> 
> 
> > SIPS URIs however can be used in many other header fields: 
> in Contact 
> > for registration, Contact in dialog-creating requests, 
> Route, Record- 
> > Route, Path, From, To, Refer-To, Refer-By, etc.  This specification
> 
> Referred-By, I assume.
> 
> 
> > This specification mandates that a resource described by a SIPS 
> > Request-URI can not be "downgraded" to a SIP URI when a proxy is 
> > forwarding a request by changing the scheme, or by sending the 
> > associated request over a non secure link.  See Section 4.2.
> 
> I had trouble parsing this. Suggestion for modification:
> 
> >>> This specification mandates that when a proxy is forwarding a 
> >>> request a resource described by a SIPS Request-URI can not be 
> >>> "downgraded" to a SIP URI by changing the scheme, or by 
> sending the 
> >>> associated request over a non-secure link.  See section 4.2.
> 
> 
> > Consider this example:  If Bob registers with a SIPS Contact header 
> > field (e.g., sips:[email-masked]), the registrar and the 
> > location service then know that Bob ([email-masked]) is 
> reachable at 
> > sips:[email-masked],
> 
> Move "([email-masked])" to after "If Bob".
> 
> 
> > Furthermore, if Bob wants to ensure that every request 
> delivered to it 
> > be always transported over TLS, Bob can use [I-D.ietf-sip-outbound] 
> > when registering.
> 
> Use "to him" instead of "to it".
> 
> 
> > However, if Bob had registered instead with a SIP contact 
> header field 
> > instead of a SIPS contact header field (e.g., 
> > sip:[email-masked]), then a request to AOR
> 
> I suggest this instead:
> 
> >>> However, if Bob had registered with a SIP Contact header field 
> >>> instead of a SIPS Contact header field (e.g., 
> >>> sip:[email-masked]), then a request to the AOR
> 
> 
> > 3.3.  Usage of tls transport parameter and TLS Via parameter
> 
> Suggestion:
> 
> >>> 3.3.  Usage of the transport=tls URI parameter and the TLS Via 
> >>> parameter
> 
> 
> > If the Request-URI is a SIP URI, a sips option-tag in a 
> Require header 
> > field MUST NOT be used, and a Supported header field MUST be used 
> > instead.  If a UAS receives a request with the sips option-tag in a 
> > Supported or Require header field and it accepts the 
> registration, it 
> > MUST include the sips option-tag in Supported or Require 
> header in a 
> > 200 (OK) response.
> 
> Since this is talking about registration, I assume that 
> "request" should be "REGISTER request".
> 
> 
> > When a target refresh occurs within a dialog (e.g., re-INVITE, 
> > UPDATE), unless there is a need to change it, the UAC and UAS MUST 
> > include a contact header field with a SIPS URI if the 
> original request 
> > used a SIPS Request-URI.
> 
> What exactly does "a need" mean here?
> 
> 
> > 4.1.5.  Usage of tls transport parameter
> 
> Suggestion:
> 
> >>> 4.1.5.  Usage of the transport=tls parameter
> 
> 
> > Specifically, when a proxy receives a request with a SIPS Request- 
> > URI, the proxy MUST forward or retarget the request to a SIPS 
> > Request-URI.  If the target UAS had registered previously 
> using a SIP 
> > Contact header field instead of a SIPS Contact header 
> field, the proxy 
> > MUST NOT forward the request to the URI indicated in the 
> SIPS Contact 
> > header field.  If the proxy needs to reject the request for that 
> > reason, it MUST reject it with a 404 (Not Found).
> 
> Shouldn't this read "the SIP Contact header field"?
> 
> 
> > Proxies can use the sips option-tag in Supported, Require 
> and Proxy- 
> > Require header fields to detect UAs that do not conform to this 
> > specification.
> 
> How would a proxy use the Proxy-Require header to detect what 
> a UA supports?
> 
> 
> > The proxy MAY instead map the request with a 416 (Unsupported URI 
> > Scheme)
> 
> Where did the word "map" come from? I suggest "respond to".
> 
> 
> > Using a Redirect Server instead of a Proxy, with TLS has some 
> > limitations that has to be taken into account.
> 
> Suggestion:
> 
> >>> Using a Redirect Server with TLS instead of a Proxy has some 
> >>> limitations that have to be taken into account.
> 
> 
> > When a redirect server receives a request with a SIPS 
> Request-URI, the 
> > redirect server MAY redirect with a 3XX response to either 
> a SIP or a 
> > SIPS Contact header field.  If the target UAS had registered 
> > previously using a SIPS Contact header field, the redirect server 
> > SHOULD return a SIPS Contact header field to "upgrade" to 
> SIPS if it 
> > is in an environment where TLS is usable (as described in 
> the previous 
> > paragraph).
> 
> There is no "upgrade" here. Both the request and the 
> registration are SIPS already.
> 
> 
> In the call flow chart in section 5.1, the image for the 
> second 200 OK for each REGISTER points the wrong way.
> 
> 
> In general, I feel that I don't understand the reasoning 
> behind when to respond 403 and when to respond 404 in this draft.
> 
> 
> The rest of my nits is minor stuff like typos, incorrect 
> pluralization, capitalization errors, etc. I attach a diff 
> below. Note that the diff also contains a few of my notes 
> (and the above changes), so don't apply it indiscriminately.
> 
> Hans
> 
> -- 
> Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
> Ingate Systems AB  +46 13 210857   http://www.ingate.com/
> 
> Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 27 Apr 2007 18:13:43 -0500

On Apr 27, 2007, at 4:03 PM, Francois Audet wrote:

> And I've used 404 (Not Found) when a UAC sends a non-REGISTER  
> request to a SIP URI when only a SIPS URI exists for that resource.  
> I used to have 403 for that, but I received

Nonchair comment:

If we agree that SIP and SIPS point at the same thing, then rejecting  
a SIP request with a 404 when there is an "equivalent" registration  
seems wrong. 403 seems better, but what it seems like we need is an  
"Invalid Scheme" response. I'm also tempted by 488 (Not Acceptable  
Here) even though we normally use that for SDP.

Even a 400 (Bad Request) seems better than 404.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 28 Apr 2007 09:15:44 +0300

Francois Audet writes:

 > And I've used 404 (Not Found) when a UAC sends a non-REGISTER request
 > to a SIP URI when only a SIPS URI exists for that resource.

apache web server returns 403 in that case.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 29 Apr 2007 14:55:15 +0100

Isn't this what 416 is for?

John 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 28 April 2007 00:14
> To: Francois Audet
> Cc: SIP IETF; Hans Persson

---

From: Dean Willis <[email-masked]>
Date: Sun, 29 Apr 2007 19:32:54 -0500

> Isn't this what 416 is for?

In 2003, Adam said this about 416, and I'm not sure I recall how we  
resolved it:

> Just posting here to request a new bug to be opened against
> RFC 3261.
>
> 21 Response Codes
>
>    The response codes are consistent with, and extend, HTTP/1.1  
> response
>    codes.  Not all HTTP/1.1 response codes are appropriate, and only
>    those that are appropriate are given here.  Other HTTP/1.1 response
>    codes SHOULD NOT be used.
>
> Strictly speaking, this is no longer true -- and I suspect time will
> make it less and less so.
>
> Compare, for example, SIP "416 Unsupported URI Scheme" with
> HTTP "416 Requested Range Not Satisfiable".
>
> We should open up a bug against the spec to revise this language
> when we open it for revisions again.
>
> If complete consistency is required, we need to renumber SIP 416,
> and develop some sort of joint IANA registry (in conjunction with
> and with the buy-in of the HTTP community) to prevent these types
> of collisions in the future. Given how disruptive such a change
> would be, I suspect we should just let the number spaces diverge.

although I think the resolution was that SIP and HTTP had diverged  
and we should just get that through our heads.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Apr 2007 11:00:36 -0500

No.

416 is for "I don't understand your scheme, you can try sip: instead".
It is very likely
that the endpoint will then try sip:

It makes no sense in the other direction, i.e., when you receive SIP but
you only
allow for a SIPS resource (it would cause an infinite loop).

The interesting thing with 416 is that a proxy or UAS that doesn't
support SIPS is that
it is likely to use it. If the UAC is "dumb" it would retry it with sip
(which would
effectively be a downgrade, and therefore would be bad).

A proxy or UAS that wants to REJECT a SIPS request and not risk having
the UA re-attempting
the session by downgrading should therefore use something else.

Initially, I tought 403 was the proper mechanism. Juha seems to agree.
Dean also seems to 
like it.

Robert, any toughts? I think I remember it was you who preferred 404?

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Sunday, April 29, 2007 06:55
> To: Dean Willis; Audet, Francois (SC100:3055)
> Subject: RE: [Sip] Re: draft-ietf-sip-sips-03
> 
> > > Basically, I've used 403 (Forbidden) when a UAC tries to register 
> > > with the wrong scheme in the Contact.
> > >
> > > I used to have 403 for that, but I received some comments from 
> > > somebody on the list that 404 (Not Found) would be more 
> appropriate.
> > >
> > 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: Dean Willis <[email-masked]>
Date: Mon, 30 Apr 2007 11:50:46 -0500

> 416 is for "I don't understand your scheme, you can try sip: instead".

What I think we need is something that says "I do not like your  
scheme. Here's a list of alternatives that I prefer."

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Apr 2007 17:38:57 -0500

You can send 3XX with the scheme(s) you support.

That's what the document currently describes. 

> Sent: Monday, April 30, 2007 09:51
> To: Audet, Francois (SC100:3055)
> Cc: SIP IETF; Elwell, John; Hans Persson
> What I think we need is something that says "I do not like 
> your scheme. Here's a list of alternatives that I prefer."
> 
> --
> Dean
> 
> 
> 
> [email-masked] for questions on current sip