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

From: Dean Willis <[email-masked]>
Date: Tue, 1 May 2007 13:19:07 -0500

On Apr 30, 2007, at 5:38 PM, Francois Audet wrote:

>
>> -----Original Message-----
>> From: Dean Willis [mailto:[email-masked]]
>> What I think we need is something that says "I do not like
>> your scheme. Here's a list of alternatives that I prefer."

> You can send 3XX with the scheme(s) you support.
>
> That's what the document currently describes.
>

The problem I see, and I may just be imagining this, is that there's  
no way for the receiver of a 302 to know whether it means

1) The party you have called cannot be reached, please try this other  
party.

or

2) The mechanism (scheme) you have chosen to use cannot be used right  
now. Please try this other mechanism.

or

3) You need some additional parameters to reach the party you have  
selected along with the scheme you have selected.

There are heuristics that might apply. For example, if the only  
difference between the R-URI of a request and the Contact of a 302  
response is in the scheme, then we probably have a scheme change.

But with all the parameters appearing on R-URI, that's not a really  
solid heuristic.

--
Dean

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 01 May 2007 19:27:04 -0400

Dean Willis wrote:
> The problem I see, and I may just be imagining this, is that there's no 
> way for the receiver of a 302 to know whether it means
> 

I don't see that the distinction matters. You called URL-1 and are told 
you should try URL-2. You get a hint on the significance depending on 
whether it is a 301 or 302 response. (If the recipient doesn't support 
sip, then 301 is the way to go I think.)

Don't think too hard about it - just do what you are told in this case.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 May 2007 18:30:24 -0500

I agree with Paul.

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, May 01, 2007 16:27
> To: Dean Willis
> Cc: Audet, Francois (SC100:3055); SIP IETF
> Subject: Re: [Sip] Re: draft-ietf-sip-sips-03
> 
> 
> 
> Dean Willis wrote:
> > 
> >>> What I think we need is something that says "I do not like your 
> >>> scheme. Here's a list of alternatives that I prefer."
> > 
> I don't see that the distinction matters. You called URL-1 
> and are told you should try URL-2. You get a hint on the 
> significance depending on whether it is a 301 or 302 
> response. (If the recipient doesn't support sip, then 301 is 
> the way to go I think.)
>

---

From: Hans Persson <[email-masked]>
Date: Fri, 27 Apr 2007 17:15:02 +0200

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/
--- draft-ietf-sip-sips-03.txt	2007-04-16 20:19:42.000000000 +0200
+++ draft-ietf-sip-sips-03-hp.txt	2007-04-27 16:33:06.540654276 +0200
@@ -14,7 +14,7 @@
    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
+   aware will be disclosed, in accordance with section 6 of BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
@@ -41,7 +41,7 @@
 Abstract
 
    This document provides clarifications and guidelines concerning the
-   use of SIPS URI scheme in the Session Initiation Protocol (SIP).  It
+   use of the SIPS URI scheme in the Session Initiation Protocol (SIP).  It
    also makes normative changes to SIP.  This document also provides a
    discussion of possible future steps in specification.
 
@@ -115,7 +115,7 @@
 1.  Introduction
 
    The meaning and usage of the SIPS URI scheme and of TLS [RFC4346] is
-   underspecified in SIP [RFC3261] and has been the source of confusion
+   underspecified in SIP [RFC3261] and has been a source of confusion
    for implementers.
 
    This document provides clarifications and guidelines concerning the
@@ -225,7 +225,7 @@

    satisfactory solution to this problem.  [I-D.ietf-sip-outbound] also
-   solve the problem that if UA b is behind a NAT or Firewall, proxy B
+   solves the problem that if UA b is behind a NAT or Firewall, proxy B
    would not even be able to establish a TCP session in the first place.
 
    Furthermore, consider the problem of using SIPS inside a dialog.  If
@@ -243,7 +243,7 @@
 
    Because of all the problems caused by the last hop exception, this
    specification deprecates the last hop exception when forwarding a
-   request to the last hop (see Section 4.2).  This will ensure that TLS
+   request to the last hop (see section 4.2).  This will ensure that TLS
    is used on all hops all the way up to the remote target.
 
    The SIPS scheme implies transitive trust.  Obviously, there is
@@ -265,7 +265,7 @@
    [RFC4474] provides an authenticated identity mechanism and a domain-
    to-domain integrity protection mechanism.
 
-   Some have asked why is SIPS useful in a global open environment such
+   Some have asked why SIPS is useful in a global open environment such
    as the Internet, if (when used in a Request-URI) it is not an
    absolute guarantee that the request will in fact be delivered over
    TLS on each hop?  Why is SIPS any different than just using TLS
@@ -290,7 +290,7 @@
    would only be functionally equivalent to using SIPS in a Request-URI.
    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
+   Route, Path, From, To, Refer-To, Referred-By, etc.  This specification
    clarifies the significance of using SIPS URIs in these cases.  SIPS
    URIs can also be used in human-usable format (e.g., business cards,
    user interface, etc.).  SIPS URIs can even be used in other protocols
@@ -336,10 +336,10 @@
 Internet-Draft                    SIPS                        April 2007

-   URIs.  The proxies may insert Record-Route using SIP URIs even if it
+   URIs.  The proxies may insert Record-Route headers using SIP URIs even if it
    uses TLS transport.
 
-   Some user agents, redirect server and proxies may have local policies
+   Some user agents, redirect servers and proxies may have local policies
    that enforce TLS on all connections, independently of if SIPS is used
    or not.
 
@@ -354,32 +354,32 @@
    the SIPS URI will necessarily be reachable, in particular, if the
    proxy can not establish a secure connection to a client or another
    proxy.  This does not suggest either that proxies should arbitrarily
-   "upgrade" SIP URIs to SIPS URIs when forwarding a request (See
-   Section 4.2).  Rather, it means that when a resource is addressable
+   "upgrade" SIP URIs to SIPS URIs when forwarding a request (see
+   section 4.2).  Rather, it means that when a resource is addressable
    with SIP, it will also be addressable with SIPS.
 
-   For example, consider the case of a UA that has registered with SIPS
-   contact header field.  If a UAC later addresses a request using a SIP
+   For example, consider the case of a UA that has registered with a SIPS
+   Contact header field.  If a UAC later addresses a request using a SIP
    Request-URI, the proxy will forward the request addressed to a SIP
    Request-URI to the endpoint, as illustrated by message F13 in
-   Section 5.3 and in Section 5.4.  The proxy forwards the request to
+   section 5.3 and in section 5.4.  The proxy forwards the request to
    the UA using a SIP Request-URI and not the SIPS Request-URI used in
-   registration (and it does this by substituting the sip scheme to the
-   sips scheme in the registered contact header field binding).  If the
+   registration (and it does this by substituting the SIP scheme for the
+   SIPS scheme in the registered Contact header field binding).  If the
    proxy did not do this, and instead used a SIPS Request-URI, then the
    response (e.g., a 200 to an INVITE) would have to include a SIPS
-   contact header field.  That SIPS contact header field would then
-   force the other UA to use a SIPS contact header field in any mid-
+   Contact header field.  That SIPS Contact header field would then
+   force the other UA to use a SIPS Contact header field in any mid-
    dialog request, including the ACK (which wouldn't be possible if that
    UA did not support SIPS).
 
-   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.
+   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.
 
    For example, the sip:[email-masked] and sips:[email-masked] AORs
-   must refer to the same user "Bob" in domain "example.com": the first
+   must refer to the same user "Bob" in the domain "example.com": the first
    URI is the SIP version, and the second one is the SIPS version.  From
    the point of view of routing, requests to either sip:[email-masked]
    and sips:[email-masked] are treated the same way.  Location services
@@ -397,32 +397,32 @@
    the same user.  At first glance, section [RFC3261]/19.1.4 seems to
    contradict this idea by stating that a SIP and a SIPS URI are never
    equivalent.  Specifically, it says that they are never equivalent for
-   the purpose of comparing bindings in contact header field URIs in
+   the purpose of comparing bindings in Contact header field URIs in
    REGISTER requests.  The key point is that this statement applies to
-   the contact header field bindings in a registration: it is the
-   association of the contact header field with the AOR that will
+   the Contact header field bindings in a registration: it is the
+   association of the Contact header field with the AOR that will
    determine if the user is reachable or not with a SIPS URI.
 
-   Consider this example.  If Bob registers with a SIPS contact header
+   Consider this example:  If Bob ([email-masked]) registers with a SIPS Contact header
    field (e.g., sips:[email-masked]), the registrar and the
-   location service then knows that Bob ([email-masked]) is reachable
+   location service then know that Bob is reachable
    at sips:[email-masked], and at
-   sip:[email-masked].  If a request is sent to AOR
-   sips:[email-masked], Bob's proxy will route it to Bob at Request-URI
-   sips:[email-masked].  If a request is sent to AOR
-   sip:[email-masked], Bob's proxy will route it to Bob at Request-URI
+   sip:[email-masked].  If a request is sent to the AOR
+   sips:[email-masked], Bob's proxy will route it to Bob at the Request-URI
+   sips:[email-masked].  If a request is sent to the AOR
+   sip:[email-masked], Bob's proxy will route it to Bob at the Request-URI
    sip:[email-masked].  The proxy should attempt to transport
    the request over TLS if a TLS connection can be established even if a
    SIP URI is used.  Indeed, some proxies may even have local policies
    of always using TLS.  Furthermore, if Bob wants to ensure that every
-   request delivered to it be always transported over TLS, Bob can use
+   request delivered to him be always transported over TLS, Bob can use
    [I-D.ietf-sip-outbound] when registering.
 
-   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
+   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
    sips:[email-masked] would not be routed to Bob, since there is no
-   SIPS contact header field for Bob, and "downgrades" from SIPS to SIP
+   SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP
    are not allowed.
 
    See Section 5 for illustrative call flows.
@@ -448,19 +448,19 @@
 Internet-Draft                    SIPS                        April 2007

-   SIPS URI with a contact header field containing a SIP URI.
-   [RFC3261]/8.1.3.4 states that if the UAC decide to recurse to the SIP
+   SIPS URI with a Contact header field containing a SIP URI.
+   [RFC3261]/8.1.3.4 states that if the UAC decides to recurse to the SIP
    URI, it "SHOULD inform the user".  When a proxy is handling the 3XX,
-   it can obviously not indicate anything to the user that it is being
+   it obviously can not indicate anything to the user that is being
    redirected from SIPS to SIP: therefore, proxies would not be able
-   recurse on the contact header field, and instead would either forward
+   recurse on the Contact header field, and instead would either forward
    the 3XX to the UAC or reject the request.
 
 3.2.1.  Detection of hop-by-hop security
 
    The presence of a SIPS Request-URI does not necessarily indicate that
    the request was sent securely on each hop.  So how does a UAS know if
-   the SIPS was used for the entire request path to secure the request
+   SIPS was used for the entire request path to secure the request
    end-to-end?  Effectively, the UAS can not know for sure.  However,
    [RFC3261]/26.4.4 recommends how a UAS may make some checks to
    validate the security.  Additionally, the History-Info header
@@ -476,9 +476,9 @@
    be configured to only route SIPS.  Some proxies may be configured to
    detect non-compliances and reject un-secure requests.  For example,
    proxies could inspect Request-URIs, Path, Record-Route, To, From,
-   contact header field and Via headers to enforce SIPS.
+   Contact header fields and Via headers to enforce SIPS.
 
-   [RFC3261]/26.4.4 also explains that S/MIME may also be used by the
+   [RFC3261]/26.4.4 explains that S/MIME may also be used by the
    originating UAC to ensure that the original form of the To header
    field is carried end-to-end.  While not specifically mentioned in
    [RFC3261]/26.4.4, this is meant to imply that [RFC3893] would be used
@@ -574,7 +574,7 @@
 
    Note that the same rules apply to the Path Header [RFC3327].
 
-3.3.  Usage of tls transport parameter and TLS Via parameter
+3.3.  Usage of the transport=tls URI parameter and the TLS Via parameter
 
    [RFC3261]/26.2.2 makes it clear that the use of the "transport=tls"
    URI transport parameter in SIPS or SIP URIs has been deprecated:
@@ -625,7 +625,7 @@
    as a result of the redirection.
 
    A UAC that conforms to this specification MUST include a sips option-
-   tag in Supported or Require header field when sending a request.  The
+   tag in the Supported or Require header field when sending a request.  The
    Supported header is useful for a "backward compatible mode" where the
    UAS may not support this specification, but still support SIPS as per
    [RFC3261] (note however that since the usage of SIPS was greatly
@@ -635,12 +635,12 @@
    the network (for example, to enforce the deprecation of the last hop
    exception).  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
+   MUST be used instead.  If a UAS receives a REGISTER 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.  If the UAS does not support
    the sips option-tag, it will reject a request with a sips option-tag
-   in a Require header field, and it will no include the sips option-tag
+   in a Require header field, and it will not include the sips option-tag
    in a 200 (OK) sent in response to a request with a sips option-tag in
    a Supported header.  If a UAC sent a request with a sips option-tag
    in a Supported header, and the 200 (OK) did not include a sips
@@ -657,8 +657,8 @@
    mandated by [RFC3261]/12.1.1, "If the request that initiated the
    dialog contained a SIPS URI in the Request-URI or in the top Record-
    Route header field value, if there was any, or the Contact header
-   field if there was no Record-Route header field, the contact header
-   filed in the response MUST be a SIPS URI".
+   field if there was no Record-Route header field, the Contact header
+   field in the response MUST be a SIPS URI".
 
    If a UAS does not support SIPS, "it SHOULD reject the request with a
    416 (Unsupported URI scheme) response" as described in [RFC3261]/
@@ -675,7 +675,7 @@
    described in [RFC3261]/8.1.3.5 as it would be a security
    vulnerability.  If the UAC does re-attempt the call with a SIP URI,
    it SHOULD get a confirmation from the user to authorize re-initiating
-   the session with a SIP Requst-URI instead of a SIPS Request-URI.
+   the session with a SIP Request-URI instead of a SIPS Request-URI.
 
    If a UAS does not wish to be contacted with a SIP URI, it MAY reject
    a request to a SIP Request-URI with response code 404 (Not Found), or
@@ -687,31 +687,31 @@
    Upon receiving a 3XX response with a SIPS Contact header field, the
    UAC SHOULD automatically re-initiate the request using a SIPS
    Request-URI (i.e., it does not need to get a confirmation from the
-   user to autorize re-initiating the session with a SIPS Request-URI
+   user to authorize re-initiating the session with a SIPS Request-URI
    instead of a SIP Request-URI).
 
 4.1.1.  Service routes
 
-   If a UA registers with a SIPS contact header field, the registrar
+   If a UA registers with a SIPS Contact header field, the registrar
    returning a service route MUST return a service route consisting of
    SIP URIs if the intent of the registrar is to allow both SIP and SIPS
    to be used in requests sent by that client.  If a UA registers with a
-   SIPS contact header field, the registrar returning a service route
+   SIPS Contact header field, the registrar returning a service route
    MUST return a service route consisting of SIPS URIs if the intent of
    the registrar is to allow only SIPS URIs to be used in requests sent
    by that UA.  It is the responsibility of the UAC to use a Route
    header consisting of all SIPS URIs when using a SIPS Request-URI and
-   contact header field.  Specifically, If the service route included
+   Contact header field.  Specifically, if the service route included a
    SIP URI, the UAC MUST upgrade the SIP URIs to SIPS URIs simply by
    changing the scheme from "sip" to "sips" before sending the request.
-   Note that this allows for configuring or discovering one Service
-   Route with all SIP URIs and allowing sending requests to both SIP and
+   Note that this allows for configuring or discovering one service
+   route with only SIP URIs and allowing sending requests to both SIP and
    SIPS URIs.
 
 4.1.2.  Registration
 
    This section describes the registration procedures of SIPS versus SIP
-   contact header field that follows from the discussion in Section 3.2.
+   Contact header fields that follows from the discussion in section 3.2.
 
    The UAC registers either a SIPS or a SIP AOR.  From a routing
    perspective, it does not matter which one is used for registration as
@@ -728,31 +728,31 @@
 Internet-Draft                    SIPS                        April 2007

-   a SIPS contact header field.  Requests addressed to that UA's AOR
+   a SIPS Contact header field.  Requests addressed to that UA's AOR
    using either a SIP or SIPS Request-URI will be routed to that UA.
-   Note that this includes UA that support both SIP and SIPS.
+   Note that this includes UAs that support both SIP and SIPS.
 
    If a UA does not wish to be reached with a SIPS URI, it MUST register
-   with a SIP contact header field.  The UA MUST NOT include a sips
+   with a SIP Contact header field.  The UA MUST NOT include a sips
    option-tag in that case.
 
-   Because registering with a SIPS contact header field implies a
+   Because registering with a SIPS Contact header field implies a
    binding to both a SIPS Contact and a corresponding SIP Contact, a UA
    MUST NOT include both the SIPS and the SIP version of the same
-   contact header field in a REGISTER: it MUST only use the SIPS version
-   in this case.  Similarly, a UA SHOULD NOT register both a SIP contact
-   header field and a SIPS contact header field in separate
-   registrations as the SIP contact header field would be superfluous.
-   Note however that a UA could register first with a SIP contact header
+   Contact header field in a REGISTER: it MUST only use the SIPS version
+   in this case.  Similarly, a UA SHOULD NOT register both a SIP Contact
+   header field and a SIPS Contact header field in separate
+   registrations as the SIP Contact header field would be superfluous.
+   Note however that a UA could register first with a SIP Contact header
    field (meaning it does not support SIPS), and later register with a
-   SIPS contact header field (meaning it now supports SIPS).
+   SIPS Contact header field (meaning it now supports SIPS).
 
    If a UA wants to ensure that no requests are delivered without using
-   TLS on that last hop, the UA MUST use [I-D.ietf-sip-outbound].
+   TLS on the last hop, the UA MUST use [I-D.ietf-sip-outbound].
 
-   If all the contact header fields in a REGISTER are SIPS, a SIPS AOR
+   If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR
    MUST be used by the UAC in the REGISTER.  If at least one of the
-   contact header fields is SIP or is neither SIP nor SIPS (e.g.,
+   Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
    mailto, tel, http, https), a SIP AOR MUST also be used by the UAC.
    However, the registrar MUST treat the SIP and SIPS schemes of the AOR
    the same way (i.e., it MUST not care if it is SIP or SIPS).  These
@@ -762,17 +762,17 @@
    incoming requests addressed to a URI scheme that does not correspond
    to what it used for registration.  For example, a UA with a policy of
    "always SIPS" would address the Registrar using a SIPS Request-URI
-   over TLS, would register with a SIPS contact header field, and would
+   over TLS, would register with a SIPS Contact header field, and would
    reject requests addressed to a SIP Request-URI with 403 (Forbidden).
    A UA with a policy of "best-effort SIPS" would address the Registrar
-   using a SIPS Request-URI over TLS, would register with a SIPS contact
+   using a SIPS Request-URI over TLS, would register with a SIPS Contact
    header field, and would accept requests addressed to either SIP or
    SIPS Request-URIs.  A UA with a policy of "No SIPS" would address the
    Registrar using a SIP Request-URI, could use TLS or not, would
-   register with a SIP AOR and a SIP contact header field, and would
+   register with a SIP AOR and a SIP Contact header field, and would
    accept requests addressed to a SIP Request-URI.
 
-   A registrar MUST only accept a binding to a SIPS contact header field
+   A registrar MUST only accept a binding to a SIPS Contact header field
    if all the appropriate URIs are of the SIPS scheme, otherwise there
    could be an inadvertent binding of a secure resource (SIPS) to an
    unsecured one (SIP).  This includes the Request-URI, the Contacts and
@@ -788,15 +788,15 @@
    If the URIs are not of the proper SIPS scheme, the registrar MUST
    reject the REGISTER with a 403 (Forbidden).
 
-   The usage of the "transport" URI parameter in contact header fields
+   The usage of the "transport" URI parameter in Contact header fields
    in registration is of dubious usefulness.  The assumption is that a
    UAC would choose one transport for the registration itself, and a
    different transport for receiving requests.  Using the transport URI
    parameters also results in some complex problems.  For example,
-   should all the transports be listed as separate contact header fields
-   (e.g, udp, TCP, sctp, tls over TCP, tls over sctp)?  If so, there is
-   no way to signal tls over sctp defined yet.  Furthermore, how should
-   they be prioritized using a q-value?  If so, it is possible that
+   should all the transports be listed as separate Contact header fields
+   (e.g, UDP, TCP, SCTP, TLS over TCP, TLS over SCTP)?  If so, there is
+   no way to signal TLS over SCTP defined yet.  Furthermore, how should
+   they be prioritized using a q-value?  If so, it is also possible that
    certain proxies will interpret this as a forking scenario and they
    might decide to send one incoming request per transport.  Another
    issue is what happens if a UAC fetches bindings by sending an empty
@@ -804,33 +804,34 @@
    possible transport?  All this would generate unwarranted complexity.
 
    It is therefore RECOMMENDED that UACs do not use any transport URI
-   parameters in contact header fields in REGISTER.
+   parameters in Contact header fields in REGISTER.
 
    For backward compatibility, a registrar should accept a REGISTER
-   message with a transport URI parameter in the contact header field.
+   message with a transport URI parameter in the Contact header field.
    It is recommended that a registrar ignores that parameter, i.e., that
    it will not influence routing.
 
 4.1.3.  SIPS in a dialog
 
    If the Request-URI in a request that initiates a dialog is a SIP URI,
-   then the UAC needs to be careful about what to use in the contact
+   then the UAC needs to be careful about what to use in the Contact
    header field (in case Record-Route is not used for this hop).  If the
-   contact header field was a SIPS URI, it would mean that it would only
-   accept mid-dialog requests that are sent over secure transport on
-   each hop.  Since the Request-URI is in this case a SIP URI, it is
+   Contact header field was a SIPS URI, it would mean that it would only
+   accept mid-dialog requests that are sent over a secure transport on
+   each hop.  Since the Request-URI in this case is a SIP URI, it is
    quite possible that the UA sending a request to that URI may not be
    able to send requests to SIPS URIs.  If the top Route header field
-   does not contain a SIPS URI, the contact header field MUST be a SIP
+   does not contain a SIPS URI, the Contact header field MUST be a SIP
    URI, even if the request is sent over a secure transport (e.g., the
    first hop could be re-using a TLS connection to the proxy as would be
    the case with [I-D.ietf-sip-outbound]).
 
    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
+   include a Contact header field with a SIPS URI if the original
    request used a SIPS Request-URI.
 
+Exactly what does "a need" mean here?

@@ -852,10 +853,10 @@
 
    For example, when a REFER request is used to perform a call transfer,
    it results in an existing dialog being terminated and another one
-   being created based on the Refer-to URI.  If that initial dialog was
+   being created based on the Refer-To URI.  If that initial dialog was
    established using SIPS, then the new one MUST NOT be established
    using SIP, unless there is an explicit authorization given by the
-   recipient of REFER.  This could be a warning provided to the user.
+   recipient of the REFER.  This could be a warning provided to the user.
    Having such a warning could be useful for example for a secure
    directory service application, resulting in being routed to a UA that
    does not support SIPS.  If the proper treatment is to reject the
@@ -863,6 +864,9 @@
    with very simple phones, it could be rejected with error response 404
    (Not Found).
 
+I don't really see the reasoning behind when 403 is sent and when 404
+is sent.
+
    Note that a REFER may also be used for referring to resources that do
    not result in dialogs being created.  In fact, a REFER may be used to
    point to resources that are of a different type than the original one
@@ -870,12 +874,12 @@
    considerations related to this.
 
    Other examples of derived dialogs and transactions include the use of
-   Third-Party Call Control [RFC3725], the Replaces header [RFC3891],
+   Third-Party Call Control [RFC3725], the Replaces header [RFC3891], and
    the Join header [RFC3911].  Again, the general principle is that
    these mechanism SHOULD NOT result in an effective downgrading of SIPS
    to SIP, without the proper authorization.
 
-4.1.5.  Usage of tls transport parameter
+4.1.5.  Usage of the transport=tls parameter
 
    The "transport=tls" parameter MUST NOT be used by UAs.  However, for
    backward compatibility, if a "transport=tls" parameter is received by
@@ -898,18 +902,18 @@
 
       NOT be used in Route, Record-Route or Path headers, and MUST be
       ignored.
-   o  In a contact header field in a dialog, it could be interpreted as
+   o  In a Contact header field in a dialog, it could be interpreted as
       a request to send incoming mid-dialog requests using TLS.  Note
       that this would only have a significance if
       [I-D.ietf-sip-outbound] and Record-Route are not used, and if that
       URI is nevertheless reachable with TLS which is extremely
       unlikely.  If it was the case that it was reachable with TLS, say
       because there is an active TLS connection, then that connection
-      could be re-used anyways, regardless of the presence of the
+      could be re-used anyway, regardless of the presence of the
       transport parameter.  It is RECOMMENDED that the "transport=tls"
       parameter in a Contact header field in a dialog be ignored by the
       UAS.
-   o  In a contact header field in a REGISTER, it tells the registrar
+   o  In a Contact header field in a REGISTER, it tells the registrar
       that the UAC is reachable through TLS.  If the registrar and proxy
       are co-located, and are the proxy of that UAC, it tells what is
       already known because the request was sent over TLS (i.e., that it
@@ -921,7 +925,7 @@
    o  In a Request-URI, the transport parameter is problematic.  On the
       last hop, it is useless because the transport is evident.  A UAS
       MUST ignore the "transport=tls" parameter in a Request-URI.
-   o  In a contact header field in a 3XX response, it would essentially
+   o  In a Contact header field in a 3XX response, it would essentially
       mean a request to attempt to re-send the request, using TLS
       transport.  Since the transport=tls parameter only has local
       significance, it will only be successful if the 3XX is recursed by
@@ -934,7 +938,7 @@
    pair, both SIP and SIPS GRUUs will be assigned.  When a GRUU is
    obtained through registration, if the Contact header in the REGISTER
    request contains a SIP URI, the SIP version of the GRUU is returned.
-   If the Contact header filed in the REGISTER request contains a SIPS
+   If the Contact header field in the REGISTER request contains a SIPS
    URI, the SIPS version of the GRUU is returned.
 
    If the wrong scheme is received in the GRUU (which would be an error
@@ -960,12 +964,12 @@
    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
+   proxy MUST NOT forward the request to the URI indicated in the SIP(?)
    Contact header field.  If the proxy needs to reject the request for
    that reason, it MUST reject it with a 404 (Not Found).
 
    Proxies SHOULD transport requests using a SIP URI over TLS when it is
-   possible to set-up a TLS connection, or re-use an existing one.
+   possible to set up a TLS connection, or re-use an existing one.
    [I-D.ietf-sip-outbound] for example, allows for re-using an existing
    TLS connection.  Some proxies MAY have policies that prohibits
    sending any request over anything but TLS.
@@ -974,8 +978,8 @@
    MUST NOT forward the request to a SIPS Request-URI.  If the target
    UAS had registered previously using a SIPS Contact header field, and
    the proxy decides to forward the request, it MUST substitute the SIP
-   scheme to the SIPS scheme of the URI found in the registered Contact
-   header field binding and use it in the Request-URI of the forwarded
+   scheme for the SIPS scheme of the URI found in the registered Contact
+   header field binding and use the resulting URI in the Request-URI of the forwarded
    request, and those proxies MUST use TLS to forward the request to the
    UAS.  Some proxies MAY have a policy of not forwarding at all
    requests using a non-SIPS Request-URI if the UAS had registed using a
@@ -999,6 +1003,8 @@
    implementation-specific non-compliant procedures to handle legacy
    implementations.
 
+How would using a Proxy-Require header detect a non-conforming UA?
+
    It is RECOMMENDED to use an outbound proxy as per the procedures

@@ -1025,7 +1031,7 @@
    3XX response with a SIPS Contact header field, it MUST NOT recurse on
    the Contact header field.  The Proxy SHOULD forward the 3XX to the
    UAC instead of recursing, in order to allow for the UAC to take the
-   appropriate action.  The proxy MAY instead map the request with a 416
+   appropriate action.  The proxy MAY instead respond to the request with a 416
    (Unsupported URI Scheme) if it is not its policy to allow redirection
    to be done by the UA.
 
@@ -1041,13 +1047,13 @@
 
 4.3.  Redirect Server Behavior
 
-   Using a Redirect Server instead of a Proxy, with TLS has some
-   limitations that has to be taken into account.  Since there no pre-
+   Using a Redirect Server with TLS instead of a Proxy has some
+   limitations that have to be taken into account.  Since there is no pre-
    established connection (such as with [I-D.ietf-sip-outbound]) between
    the Proxy and the UAS, it is only appropriate for scenarios where
    inbound connections are allowed.  For example, it could be used in a
    server to server environment (redirect server or proxy server) where
-   mutual TLS is used, and where there is no NAT traversal issues.  A
+   mutual TLS is used, and where there are no NAT traversal issues.  A
    redirect server would not be usable if server-side authentication is
    used or if there is a NAT between the server and the UAS.
 
@@ -1076,7 +1082,10 @@
    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).  If the target UAS had registered previously
+   previous paragraph).  
+This is not an upgrade; both the request and the registration are SIPS
+already. 
+   If the target UAS had registered previously
    using a SIP Contact header field, the redirect server MUST return a
    SIP Contact header field in a 3XX response if it chooses to redirect;
    otherwise it may reject the request with a 416 (Unsupported URI
@@ -1106,7 +1115,7 @@
                 |______|        O / \ O            O / \ O
                /_______/         /___\              /___\
 
-               bob@bobppc     bob@bobphone          Alice
+               bob@bobpc      bob@bobphone          Alice

                                  Topology
@@ -1122,15 +1131,15 @@
 
    client running on his computer, and the other one is a SIP Phone.
    The PC client does not support SIPS and consequently only registers
-   with a SIP contact header field.  The SIP phone however does support
-   SIPS and TLS, and consequently registers with a SIPS contact header
+   with a SIP Contact header field.  The SIP phone however does support
+   SIPS and TLS, and consequently registers with a SIPS Contact header
    field.  Both of Bob's devices are going through Outbound Proxy B, and
    consequently, they include a Route header indicating Proxy B. Proxy B
    removes the Route header corresponding to itself, and adds itself in
    a Path header.  The registration process call flow is illustrated in
    Section 5.1.
 
-   After registration, there are 2 contact bindings associated with
+   After registration, there are two Contact bindings associated with
    Bob's AOR of [email-masked]: sips:[email-masked] and
    sip:[email-masked].
 
@@ -1142,10 +1151,10 @@
    in the Record-Route and forwards the request to Outbound Proxy B.
 
    The following subsections illustrates registration and three
-   examples.  In the first example (Section 5.2), Alice calls Bob using
-   Bob's SIPS URI.  In the second example (Section 5.3), Alice calls
+   examples.  In the first example (section 5.2), Alice calls Bob using
+   Bob's SIPS URI.  In the second example (section 5.3), Alice calls
    Bob's SIP AOR using TCP transport.  In the third example
-   (Section 5.4), Alice calls Bob's SIP AOR using TLS transport.
+   (section 5.4), Alice calls Bob's SIP AOR using TLS transport.
 
 5.1.  Bob Registers His Contacts
 
@@ -1184,7 +1193,7 @@
                   |                   |-------------->|
                   |                   |    200 F3     |
                   |      200 F4       |<--------------|
-                  |------------------>|               |
+                  |<------------------|               |
                   |                   |               |
                   |   Bob@bobphone    |               |
                   |      |            |               |
@@ -1193,7 +1202,7 @@
                   |      |            |-------------->|
                   |      |            |    200 F7     |
                   |      |   200 F8   |<--------------|
-                  |      |----------->|               |
+                  |      |<-----------|               |
                   |      |            |               |

@@ -1419,14 +1428,14 @@
 
 5.2.  Alice Calls Bob's SIPS AOR
 
-   Bob's registration has already occurred as per Section 5.1.
+   Bob's registration has already occurred as per section 5.1.
 
    In this first example, Alice calls Bob's SIPS AOR
    (sips:[email-masked]).  Proxy B consults the binding in the
-   registration database, and finds the 2 contact header field bindings.
+   registration database, and finds the two Contact header field bindings.
    Alice had addressed Bob with a SIPS Request-URI
    (sips:[email-masked]), so Proxy B determines that the calls needs to
-   be routed only to a SIPS contact header field, and therefore the
+   be routed only to a SIPS Contact header field, and therefore the
    request is only sent to sips:[email-masked].  Proxy B
    inserts itself in the Record-Route.  Bob answers at
    sips:[email-masked].
@@ -1723,11 +1732,11 @@
 
 5.3.  Alice Calls Bob's SIP AOR using TCP
 
-   Bob's registration has already occurred as per Section 5.1.
+   Bob's registration has already occurred as per section 5.1.
 
    In the second example, Alice calls Bob's SIP AOR instead
    (sip:[email-masked]), and she uses TCP as a transport.  Proxy B
-   consults the binding in the registration database, and finds the 2
+   consults the binding in the registration database, and finds the two

@@ -1736,12 +1745,12 @@
 Internet-Draft                    SIPS                        April 2007

-   contact header field bindings.  Alice had addressed Bob with a SIP
+   Contact header field bindings.  Alice had addressed Bob with a SIP
    Request-URI (sip:[email-masked]), so Proxy B determines that the
-   calls needs to be routed both to the SIP contact header field and the
-   SIPS contact header field, and therefore the request is forked sent
-   to sip:[email-masked] and sip:[email-masked].  Note
-   that the proxy substituted the SIP scheme to the SIPS scheme for
+   calls needs to be routed both to the SIP Contact header field and the
+   SIPS Contact header field, and therefore the request is forked and sent
+   to sip:[email-masked] and sip:[email-masked].  Note
+   that the proxy substituted the SIP scheme for the SIPS scheme for
    [email-masked].  Outbound Proxy B inserts itself in the
    Record-Route.  Bob's phone's policy is to accept calls to SIP and
    SIPS (i.e., "best effort") so both his PC Client and his SIP Phone
@@ -1827,6 +1836,7 @@
             |------------------>|              |             |
             |                   |              |             |
 
+No 180 from bobphone?
 
                          Alice Calls Bob's SIP AOR
 
@@ -2254,7 +2264,7 @@
 
 5.4.  Alice Calls Bob's SIP AOR using TLS
 
-   Bob's registration has already occurred as per Section 5.1.
+   Bob's registration has already occurred as per section 5.1.
 
    The third example is identical to the second one, except that Alice
    uses TLS as the transport for her connection to her outbound proxy.
@@ -2267,11 +2277,11 @@
    It should be noted that when using a SIP URI in the Request-URI, but
    TLS as a transport for sending the request, the Via field indicates
    TLS.  The Route header (if present) typically would use a SIP URI
-   (but it could also be a SIPS URI).  The contact header fields, To and
+   (but it could also be a SIPS URI).  The Contact header fields, To and
    From however would also normally indicate a SIP URI.
 
    The call flow would be exactly as per the second example
-   (Section 5.3).
+   (section 5.3).
 
    Messages F20'-F22' are identical to the ones in Section 5.3.  The
    other messages are as follows.
@@ -2650,14 +2660,14 @@
 
    SIP [RFC3261] itself introduces some complications with using SIPS,
    for example when using strict routing instead of loose routing.  When
-   a SIPS URI is used in a contact header field in a dialog initiating
+   a SIPS URI is used in a Contact header field in a dialog-initiating
    request and Record-Route is not used, that SIPS URI may not be usable
    by the other end.  If the other end does not support SIPS and/or TLS,
    it will not be able to use it.  The "last-hop exception" is an
    example of when this may occur.  In this case, using Record-Route so
    that the requests are sent through proxies may help in making it
    work.  Another example of issues with strict routing is that even in
-   a case where the contact header field is a SIPS URI, no Record-Route
+   a case where the Contact header field is a SIPS URI, no Record-Route
    is used, and the far end supports SIPS and TLS, it may still not be
    possible for the far end to establish a TLS connection with the SIP
    originating end if the certificate can not be validated by the far
@@ -2669,9 +2679,9 @@
    "Server-side authentication" (where the server side provides its
    certificate but the client side does not) is typically used between a
    SIP end-user device acting as the TLS client side (e.g., a phone or a
-   personal computer), and it's SIP server (proxy or registrar) acting
+   personal computer), and its SIP server (proxy or registrar) acting
    as the TLS server side.  "Mutual TLS" (where both the client and the
-   server side provide their respective certificate) is typically used
+   server side provide their respective certificates) is typically used
    between SIP servers (proxies, registrars), or statically configured
    devices such as PSTN gateways or media servers.  In the mutual TLS
    model, for two entities to be able to establish a TLS connection, it
@@ -2695,14 +2705,14 @@
    [I-D.ietf-sip-outbound] is the recommended approach.  For mutual TLS,
    it means that one should be very careful that the architecture of the
    network is such that connections are made between entities that have
-   access to each other's credential.  Record-Route [RFC3261] and Path
+   access to each other's credentials.  Record-Route [RFC3261] and Path
    [RFC3327] are very useful in ensuring that previously established TLS
-   connections can be re-used.  Other mechanism may also be used in
-   certain circumstances: for example, using root-certificates that are
+   connections can be re-used.  Other mechanisms may also be used in
+   certain circumstances: for example, using root certificates that are
    widely recognized may allow for more easily created TLS connections.
 
    The "last hop exception" introduces significant potential
-   vulnerabilities in SIP and therefore has been deprecated by this
+   vulnerabilities in SIP and it has therefore been deprecated by this
    specification.

@@ -2721,7 +2731,7 @@
 
    Name:  sips
    Description:  This option-tag is used to identify UACs, UASs and
-      Registrars that support the procedures of this specification.
+      registrars that support the procedures of this specification.

 9.  IAB Considerations
@@ -2891,7 +2901,7 @@
 
       Actually using TLS on every segment of a request path entails that
       the terminating UAS must be reachable over TLS (by registering
-      with a SIPS URI as a contact).  The SIPS scheme implies transitive
+      with a SIPS URI as a Contact).  The SIPS scheme implies transitive
       trust.  Obviously, there is nothing that prevents proxies from
       cheating.  Thus SIPS cannot guarantee that TLS usage will be truly
       respected end-to-end on each segment of a request path.  Note that
_______________________________________________
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