Subject: [Sip] bis-05 NITS

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Nov 2001 15:30:24 -0000

A number of minor issues with the new draft. This is the first batch and I
am sending them as I work through the document.

1)	General. Sometimes the text has "option-tag" and sometime "option
tag". Make consistent throughout the document.

2)	Section 6: definition of Proxy: Current sentence "A proxy server
primarily plays to role of routing, " should be ""A proxy server primarily
plays the role of routing, ".

3)	Section 6: definition of Session: Remove extra spaces before commas
(3 times) towards end of definition.

4)	Section 6: the definition of stateless proxy and stateful proxy are
reversed to what alphabetical order would demand.

5)	Section 6: two last paragraphs after definitions. These are not part
of any of the definitions, and the text is not really definition text. It
would appear to me that these two paragraphs would actually fit better in
section 5 (Structure of the protocol).

6)	Section 7, last paragraph immediately before section 7.1. Delete
words "Note, however, that" as they are unnecessary for the meaning
conveyed.

7)	Section 7.1, 1st paragraph. We have a number of symbols used here to
represent control characters etc in the character set. CR and LF are defined
in the penultimate paragraph of section 7 before 7.1 is reached, but nowhere
have we said what SP means. Also elsewhere we use the term whitespace, so we
are not consistent within the document.

8)	Section 7.1, 1st paragraph. We here use the term "element". We do
not appear to have defined what this means, and the meaning here is
different to all occurences of the same word up to this point. We either
need to use a new term, or categorise it in some way to indicate it is a
different element to "network element" etc that has been used previously. Is
it a "lexical element" or "syntactic element".

9)	Section 7.1, request-URI item: Current text "The Request-URI MUST
NOT contain unescaped spaces or control characters and MUST NOT be enclosed
in "<>"." would be better written as "Implementations MUST NOT include
unescaped spaces or control characters in the Request-URI and
implementations MUST NOT enclose the Request-URI in "<>".

10)	Section 7.1, request-URI item: Current text "It MAY translate
non-SIP URIs using any mechanism at its disposal, resulting in either a SIP
URI or some other scheme." would be clearer if ""SIP servers MAY translate
non-SIP URIs using any mechanism at its disposal, resulting in either a SIP
URI or some other scheme." which is presumably what "It" corresponds to.

11)	Section 7.1, SIP Version item: The main heading of this item should
be hyphenated, i.e. "SIP-Version", as has been done for Request-URI.

12)	Section 7.1, SIP Version item: Within item remove extra space from
middle of "SIP-Version.

13)	Section 7.1, SIP Version item: Current text "The string is
case-insensitive, but implementations MUST send upper-case." would be better
as "The SIP-Version is case-insensitive, but implementations MUST send
upper-case.

14)	Section 7.3.1, 2nd paragraph. Delete "Note that" from start of
sentence as unnecessary.

15)	Section 7.3.3. This is the first usage of "MTU" rather than in
section 7.5, and therefore the expansion "maximum transmission unit" should
be defined here rather than in section 7.5.

16)	Section 7.4. 1st paragraph: Current text "Requests, including new
requests defined in extensions to this specification, MAY contain message
bodies unless otherwise noted." would be better written as "Implementations
MAY include message bodies in requests, including new requests defined in
extensions to this specification." The final words "unless otherwise noted"
have been removed because the changes summary at the end of the document
indicates that bodies are now allowed in all requests and responses.

17)	Section 7.4. 2nd paragraph: Current text "For response messages, the
request method and the response status code determine the type and
interpretation of any message body. All responses MAY include a body." would
be better written as "For responses, the request method and the response
status code determine the type and interpretation of any message body.
Implementations MAY include a body in all responses.

18)	Section 7.4.1, 1st paragraph: Current text "The Internet media type
of the message body MUST be given by the Content-Type header field." would
be better rewritten as "Implementations MUST indicate the Internet media
type of the message body by the Content-Type header field."

19)	Section 7.4.1, 2nd paragraph: Delete words "be able to" as
unnecessary to the statement of the requirement. It is assumed that "MUST"
is meant here rather than "can".

20)	Section 7.5, 1st paragraph. Insert word "implementations" after
"SIP" thus "Unline HTTP, SIP implementations MAY use...".

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

_______________________________________________
Sip mailing list  http://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