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

[Hans Persson <[e-mail]>]

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:[e-mail]), the registrar and the
> location service then know that Bob ([e-mail]) is reachable
> at sips:[e-mail], 

Move "([e-mail])" 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:[e-mail]), 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:[e-mail]), 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 <[e-mail]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  [phone]   http://www.ingate.com/

Private: <[e-mail]>  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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip