NITs I found while reading the SIP spec

[Yaron Goland <[e-mail]>]

5 NITs

5.1 1.3 Definitions

In general I find it more useful to be given definitions in order of
dependence rather than in alphabetic order but that is just personal
preference.

Call - Has an open "(" with no close ")"

Final Response - The sentence is syntactically confusing. I would suggest
something along the lines of:
Final Response: A response that terminates a SIP transaction, as opposed to
a provisional response that leaves the transaction outstanding.

Invitation - The spacing for Invitation contains an "a" that should be an
"an", it currently says "an INVITE request followed by a ACK request." It
should read "an INVITED request followed by an ACK request."

Location Service - "beyond the scope of THIS document" not "the".

5.2 1.4.2. Locating a SIP Server

After explaining the various steps to resolve an address the spec states "If
a server is found using one of the methods below, the other methods are not
tried. " Since are specified previous to the sentence it would be more
appropriate to state "If a server is found using one of the previous
methods..."

5.3 1.4.5. Location a User

First Paragraph, last sentence, reads: "The location services yield a list
of a zero or more possible locations, possibly even sorted in order of
likelihood of success." I would rephrase this as "The location services
yield a list of zero or more locations, possibly sorted in order of
likelihood of success."

Third Paragraph, second sentence, remove the word "simply", it is an
unnecessary modifier.

In general I think it is unnecessary to discuss location servers. It is
always best to leave unspecified things, unspecified. You need only describe
behavior within the strict purview of SIP. So how a proxy or redirect server
actually gets an address is its own business. I think matters are just
confused by going into long discussions about location servers and alternate
protocols. It is much less confusing to just say "A proxy/redirect server
will use its own mechanisms to determine one or more addresses for the
specified callee." Less is more, especially in an 106 page draft.

Fourth Paragraph, third sentence, "each host most remove its Via," I suspect
you mean "each host MUST remove its Via".

Second to Last Paragraph, last sentence, you specify that user agents SHOULD
NOT notify the user when duplicate requests are received. I personally
dislike UI requirements in protocol specs. It is completely appropriate to
state that receiving two requests, because of forking, is NOT an error and
as such there is no need to notify the user but please do not put SHOULD
level requirements on UI.

5.4 2 SIP Uniform Resource Locators

RFC 1630 is out of date. The more correct guide is
http://www.ietf.org/internet-drafts/draft-fielding-uri-syntax-02.txt.

Why does the SIP URL begin with "SIP://" when no hierarchical namespace
(authority) is being defined? The correct format would be "SIP:".

Why do short SIP URLs have a production for port but full SIP URLs do not?

There is a draft out on how to create telephone URLs
(http://www.ietf.org/internet-drafts/draft-antti-telephony-url-04.txt). I
would suggest carefully reviewing it and thinking of revising your own phone
production based on the extensive information provided in the draft.

Your hostnumber production does not support IPv6

No production is given for password

I honestly don't grok the headers production. What is the huge quote
enclosed space for?

I searched [19], I can't find any reference to urlc.

While it is true that the short form SIP URL can be used unambiguously it is
a general principal of protocol design to never provide two ways of doing
the exact same thing. This just leaves more room for screw ups. I would
strongly urge the group to reconsider the wisdom of saving 4 bytes (assuming
the groups uses SIP:) at the cost of increasing complexity.

5.5 6.18 From

The second sentence of the first paragraph states that "The field MUST be a
SIP URL..." but then the first sentence of the second paragraph states "The
>From field is a URI..." which the BNF backs up. The two sentences contradict
each other.

5.6 6.38.3 Syntax

What rx parameter? I suspect you mean "received" parameter. Either that or
"rx" is the short form of received, in which case it needs to be added to
the BNF.

5.7 6.39 Warning

The BNF for the warn-code is 2DIGIT but you use a four digit with a "."
warning format because of your desire to use 606 warnings. I would suggest
that this is an inappropriate use of the warning header. Instead your should
introduce new 6xx codes to cover what you now call warnings. Regardless of
the outcome, either the examples must change or the BNF production for
warn-code in 6.39 must be changed.

5.8 10 SIP Transport

Um.. what is the story with section 10 & 11? It looks like some kind of
editing error.

5.9 14.1.2 The Authorization Request Header

Shouldn't signed-by just be a URI? Why does it have to be a SIP-URL?