Subject: [Sip] Draft -08 comments, part 1: editorial

From: Jonathan Lennox <[email-masked]>
Date: Tue, 26 Feb 2002 18:31:02 -0500

I've just done a full read-through of draft -08.  This is the first time
I've read the whole document since bis -02 or -3, and I must say, this
document is *worlds* better.  Congratulations to all the authors and
editors!

I've divided my comments up into three sections: purely editorial changes,
minor clarifications and consistency changes, and major issues where I
dislike the normatively defined behavior.  This message contains the
editorial changes.

All my comments use the line numbers from the PS/PDF versions of the spec,
but I've quoted all the text from the text version, because it's easier to
quote, and to confirm that any problems I've found exist in both versions.
(As you requested, I've ignored PDF-only formatting issues.)

"Status of this memo" section, line 11
   To view the list Internet-Draft Shadow Directories, see
                   ^ add "of"

In general (many places throughout the document), first occurance in Section
4, line 430
   Draft -08 changed all sorts of usages of un-adorned references [n] to
   instead read RFC NNNN [n], which is much clearer.  However, this wasn't
   done for the drafts which are going to RFC in the bundle with 2543bis,
   which it probably should.  First example of this is Section 4, line 430;
   I won't call them all out, since a search-and-replace on the \cite
   commands will be more effective.

Section 8.1.1.2, line 897
   All SIP implementations MUST support the SIP and URI scheme. Any
                                                ^ drop "and"

Section 8.1.3.5, line 1234
   server. The client SHOULD retry the request, this time, using a SIP URI.
                                                         ^ drop ","

Section 10.1, line 1530
    An illustration of the overall registration process is given in 2.
                                                  insert "Figure"  ^ 

Section 13.2.1, line 2129
        If the Content-Disposition header field is missing, bodies
        of Content-Type application/sdp imply the disposition
        "session", while other content types imply "render".

This shouldn't be a \motivation (indented, and smaller in the PS/PDF) --
it's a normative statement.

Section 16.6, line 2601
        4.   Optionally add a Record-route header field value
                                     ^ change to "R"
   (convention in the document is to spell it Record-Route) 

Section 16.6, line 2660
             If the Request-URI contains a SIPS URI, or the
             topmost Route header field (after the post processing of
             bullet 6 contains a SIPS URI, the URI placed into the
                     ^ insert ")"
             Record-Route header field MUST be a SIPS URI.  

Section 16.6, line 2752
             This is to
             ensure that if the request is routed back to the proxy and
             one of those fields changes, it is treated as a spiral and
             not a loop (Section 16.3 A common way to create this value
                                     ^ insert "). "

Section 16.7, line 2901
             The UAS does not have to be a
             discreet process from the proxy.
             ^ change to "discrete", unless the UAS is good at keeping
               secrets.

Section 16.7, line 2903
             3-6xx responses are delivered hop-hop. 
                                              ^ insert "by-" 

Section 17.1.2.1, line 3360
   This is why request retransmissions need to
   continue even after a provisional response, they are to ensure
                                             ^ change to ": "
   reliable delivery of the final response.

Section 20.30, line 4355 
   Examples of its use with the Route header field are described in
   Sections 16.12.1.
          ^ delete "s"

Section 22.1, line 4856
   A UAC MUST NOT re-attempt requests with the credentials
   that have just been rejected (though the request may be are retried
                                                           ^ delete "are"
   if the nonce was stale).

Section 22.3, line 4906
   The use of Proxy-Authentication and Proxy-Authorization parallel that
   described in [17], with one difference.
                ^ insert "RFC 2617"

Section 22.3, line 4914
   When the originating UAC receives the 407 (Proxy Authentication
   Required) it SHOULD, if it is able, re-originate the request 
             ^ insert "response"

Section 23.2, line 5087
   Note well however, that this key exchange mechanism does not
   guarantee the secure exchange of keys when self-signed certificates,
   or certificates signed by an obscure authority, are used - it is
                           change to "--" ( "---" in LaTeX) ^
   vulnerable to well-known attacks.

Section 23.4.3, line 5308
   motivationNote that if this mechanism is used for anonymity, the From
   ^ "insert '\'" -- i.e., fix LaTeX markup

Section 26.1, line 5764
   These attacks assume an environment in which attackers can
   potentially read any packet on the network - it is anticipated that
             change to "--" ( "---" in LaTeX) ^

Section 26.2, line 5874
   Full encryption of messages provides the best means to preserve the
   confidentiality of signaling - it can also guarantee that messages
                                ^ change to "--" ( "---" in LaTeX)

Section 26.2.2, line 5924
   A SIPS URI can be used as an address-of-record for a particular user
   - the URI by which the user is canonically known (on their business
   ^ change to "--" ( "---" in LaTeX)

Section 26.2.2, line 5941
   motivationNote that in the SIPS URI scheme, transport is independent
   ^ "insert '\'" -- i.e., fix LaTeX markup

Section 26.3.2.1, line 6033
        proxy server - attackers cannot create spoofed requests
                     ^ change to "--" ( "---" in LaTeX)
(There are a bunch more of these, but I'll stop mentioning them now.  A grep
should find them.)

Section 28.1, line 6392
          It is now well specified; if a request had a Route
          header field, its CANCEL or ACK for a non-2xx response to the
          request need to carry the same Route header field values.
                      ^ add "s"

Section 28.1, line 6425
        o RFC 2543 defined, but did no sufficiently specify, a mechanism
                                      ^ add "t"

-- 
Jonathan Lennox
[email-masked]

_______________________________________________
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