[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Re: draft-ietf-sip-sips-03
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:hasse at ingate.com]
> 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:bob at bobphone.example.com), the registrar and the
> > location service then know that Bob (bob at example.com) is
> reachable at
> > sips:bob at bobphone.example.com,
>
> Move "(bob at example.com)" 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:bob at bobphone.example.com), 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:bob at bobphone.example.com), 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 <hasse at ingate.com> Ingate - Firewalls with SIP & NAT
> Ingate Systems AB +46 13 210857 http://www.ingate.com/
>
> Private: <unicorn at lysator.liu.se> 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip