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 PROTECTED] > 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 PROTECTED]), the registrar and the > > location service then know that Bob ([EMAIL PROTECTED]) is > reachable at > > sips:[EMAIL PROTECTED], > > Move "([EMAIL PROTECTED])" 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 PROTECTED]), 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 PROTECTED]), 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 PROTECTED]> Ingate - Firewalls with SIP & NAT > Ingate Systems AB +46 13 210857 http://www.ingate.com/ > > Private: <[EMAIL PROTECTED]> 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
