Subject: [Sip] Draft -08 comments, part 2: clarifications and consistency

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

Here's part two of my comments on draft -08: minor clarifications and
consistency changes.  Part 1 was editorial changes, and part 3 will be major
issues.

Again, 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.

Section 3 (or perhaps somewhere else?)
There should be a note about the fact that \motivation blocks (the blocks
that are indented, and smaller in the PS/PDF version) are non-normative.

Also, the way the formatting works in the text version, some motivation
blocks (ones in numbered lists) aren't distinguishable from their
surrounding text.  This would require some nroff hackery to fix, though.

Section 4, line 393 / Section 7, line 783 / Normative References
>  ... [3] ...
   RFC 2822 is cited as a normative reference.  I'm pretty sure it should be
   informative.

Section 4, line 399
>   Call-ID contains a globally unique identifier for this call,
>   generated by the combination of a pseudorandom string and the
>   softphone's IP address.
                ^^^^^^^^^^
In the example, the Call-ID is actually based the soft phone's FQDN
("pc33.atlanta.com"), not its IP address.  So this should say
"fully-qualified domain name", "host name", or similar.

Section 6, line 638
>        Header field value: A header field value consists of a field
>             name and a field value, separated by a colon.

A header field value contains a field value?  This is either wrong or very
confusingly worded.  I'm not exactly sure how it should be re-worded,
because I'm not totally sure what the terminology is supposed to be.

Section 6, line 738
>        URL-encoded: A character string encoded according to RFC 1738,
>             Section 2.2 [6].

This should probably cite RFC 2396, section 2.4, instead.  I'm pretty sure
that section of 2396 entirely updates the corresponding parts of 1738.  This
will remove RFC 1738 from the normative references. 

Section 7.1, line 795
>             Unlike HTTP/1.1, SIP treats the version number as a
>             literal string. In practice, this should make no
>             difference.

This clarification obscures more than it clarifies, I think.  What does
this mean?

Section 8.3, line 1298
>   For
>   well-formed CANCEL requests, it SHOULD return a 2xx response. This
>   response ends the SIP transaction.

This section about redirect servers and CANCEL is unclear.  I think this
would be clearer expressed as "it SHOULD return a 2xx to the CANCEL request,
and then return 487 (Request Cancelled) to corresponding original
transaction, if it has not yet completed."  Alternately, the description of
server behavior on CANCEL in section 9.2 should add a description of
redirect server behavior.

Section 10.2.2, line 1623
>   The REGISTER-specific Contact header field value of "*" applies to
>   all registrations, but it MUST NOT be used unless the Expires header
>   field is present with a value of "0".

An additional clarification would be helpful here, I think: 'Note that this
expiration be expressed in an Expires header field, not the "expires"
parameter.  The ABNF for Contact described in Section 25 disallows header
field parameters on "Contact: *".'

Section 11, line 1755
>   All UAs MUST support the OPTIONS method.

This doesn't mention proxies, redirect servers, or registrars -- which I
think also ought to support OPTIONS.

Section 16.5, line 2553
>   If the Request-URI does not provide sufficient information for the
>   proxy to determine the target set, it SHOULD return a 485 (Ambiguous)
>   response. This response SHOULD contain a Contact header field
>   containing URIs of new addresses to be tried.

This contradicts section 21.4.23, which says that the 485 response MAY
contain Contact headers, but that servers MUST be configurable to suppress
them.  I think that 21.4.23's requirement strengths should be used, for
privacy reasons.

Section 16.6, line 2673
>             If a proxy needs to be in the path of any type of dialog
>             (such as one straddling a firewall), it SHOULD add a

The wording there is infelicitous -- it's not clear whether the "one" in
"one straddling" means "one proxy" or "one dialog".  If it's supposed to be
the former, the parenthetical phrase should be "(for instance, a proxy
straddling a firewall)"; if the latter, "(such as a dialog straddling a
firewall)".

Section 16.6, line 2690
>             The proxy MAY add any other appropriate header fields to
>             the copy at this point.

"Appropriate" here is vague.  There should probably be a forward reference
to section 20, and in particular to the "proxy" column of tables 2 and 3.

Section 16.6, line 2755
>             A common way to create this value
>             is to compute a cryptographic hash of the To tag, From tag,
>             Call-ID header field, the Request-URI of the request
>             received (before translation) and the sequence number from
>             the CSeq header field, in addition to any Proxy-Require and
>             Proxy-Authorization header fields that may be present.

Two sentences earlier, the text mentions that the value placed in the branch
parameter SHOULD reflect any Route fields, in addition to the other header
fields mentioned here.  This should be added, in the list with the
Proxy-Require and Proxy-Authorization headers.

Section 16.7, line 2903
>             3-6xx responses are delivered hop-hop. When issuing a 3-6xx
>             response, the element is effectively acting as a UAS,
>             issuing its own response, usually based on the responses
>             received from downstream elements. An element SHOULD
>             preserve the To tag when simply forwarding a 3-6xx response
>             to a request that did not contain a To tag.

While it's implicit here, I think it'd be useful to note that in the case
when the element is acting as a UAS for generating 3-6xx, it must (among
other things) insert To tags in its responses.  This would make the final
sentence make a lot more sense in the context, too.

Section 16.11, line 3042
>          Otherwise, the
>          first component of the branch ID is computed as a hash of the
>          topmost Via,  the tag in the To header field, the tag in the
>          From header field,  the Call-ID header field, the CSeq number
>          (but not method), and the Request-URI from the received
>          request.

This should be the same list of headers as in the text from 16.6 I quoted
above, right?  So it should include Proxy-Require, Proxy-Authorization, and
Route, i.e. everything that affects routing decisions.  Yes?

Section 17, line 3225
>   The 2xx response and its ACK receive special treatment. This response
>   is retransmitted only by a UAS, and its ACK generated only by the
>   UAC. This end-to-end treatment is needed so that a caller knows the
>   entire set of users that have accepted the call. Because of this
>   special handling, retransmissions of the 2xx response are handled by
>   the UA core, not the transaction layer. Similarly, generation of the
>   ACK for the 2xx is handled by the UA core. Each proxy along the path
>   merely forwards each 2xx response to INVITE and its corresponding
>   ACK.

The paragraph implies this, but it probably ought to be made clear that this
behavior only applies to INVITE transactions.  This is correct in the state
machines.

Section 17.1.1.1, line 3257
>   For each final response that is received at the client
>   transaction, the client transaction sends an ACK, the purpose of
>   which is to quench retransmissions of the response.

This is only true for non-2xx final responses.  This is also correct in the
state machines.

Section 18, line 3535
>   The transport layer is responsible for managing persistent
>   connections for transport protocols like TCP and SCTP, or TLS over
>   those, including ones opened to the transport layer. 

The meaning of "including ones opened to the transport layer" is unclear.
Does this mean connections for which this entity is a transaction-layer
server -- i.e. the accept() socket call rather than connect()?  

Section 18.1, line 3575
>   If an element sends a request over TCP because of these message size
>   constraints, and that request would have otherwise been sent over
>   UDP, if the attempt to establish the connection generates either an
>   ICMP Protocol Not Supported, or results in a TCP reset, the element
>   SHOULD retry the request, using UDP. This is only to provide
>   backwards compatibility with RFC 2543 compliant implementations that
>   do not support UDP.

Should be "that do not support TCP", yes?

Section 18.2.1, line 3626
>   It is also RECOMMENDED that a
>   server listen for requests on the default SIP ports (5060 for TCP and
>   UDP, 5061 for TLS over TCP) on all public interfaces. 

Shouldn't this specify the default port for SIP over SCTP and SIP over TLS
over SCTP?  I presume these are also 5060 and 5061 respectively.

Section 19.1.2, table 1, note 1 (no line number)
>   (1): The default port value is transport and scheme  dependent.   The
>   default  is  5060  for  sip: using UDP, TCP, or SCTP.  The default is
>   5061 for sip: using TLS over TCP and sips: over TCP.

Hasn't sip: using TLS over TCP disappeared from this draft, replaced by
sips:?  Looks like the figures might have been missed in the removal.  Also,
what about sips: over SCTP?

Section 20.2 (Accept-Encoding), line 4050
>   The
>   semantics in SIP are identical to those defined in [H14.3].

This contradicts the statement a few paragraphs down, which says that the
semantics of a missing Accept-Encoding are different in SIP from those in
HTTP.

Section 20.10 (Contact), line 4150
>   The second example below shows a Contact header field value
>   containing both a URI parameter (transport) and a header parameter
>   (expires).

No it doesn't -- none of the examples have URI parameters.  One probably
should.

Section 20.11 (Content-Disposition), line 4172
>   If this header field is missing, the MIME type determines the default
>   content disposition. If there is none, "render" is assumed.

This is presumably trying to back-reference section 13.2.1, line 2129, but
it's doing a particularly bad job of it.  This should explicitly mention
which MIME types imply which content dispositions.

Section 20.17 (Date), line 4229
>   rfc1123-date is case-sensitive.

Could this be worded better?  You're referencing a BNF component here, which
nothing else in section 20 does.

Section 20.17 (Date), line 4232
>        The Date header field can be used by simple end systems
>        without a battery-backed clock to acquire a notion of
>        current time. However, in its GMT form, it requires clients
>        to know their offset from GMT.

"...if the current time is to be presented to a user."

Section 20.27 (Proxy-Authenticate), line 4327
   [no quote]
There's no mention of the fact that the Proxy-Authenticate header field can
appear multiple times in a message.  I know [H14.33] and section 7.3.1
specify this, but this probably bears repeating here, with similar language
to that of section 20.28 (Proxy-Authorization) -- don't comma-separate them.
This comment also applies to section 20.44, WWW-Authenticate.

Section 20.34 (Route), line 4391
>   Examples of the use of the Record-Route
>   header field are in Section 16.12.1.

This is true, but not immediately relevant to this section, which is talking
about Route, not Record-Route.  Change to "of the use of Route", I presume.

Section 20.38 (Timestamp), line 4418
   [no quote]
This section probably ought to include an example of Timestamp with the
optional delay parameter, as well.

Section 22.1, line 4839
>   For this reason,
>   any credentials in the INVITE that were accepted by a server MUST be
>   accepted by that server for the ACK.

I'd re-word this as "any credentials in an INVITE that were accepted by a
server MUST be accepted by that server for the INVITE's ACK."  Or something
like that.  "The INVITE" in the original wording seems to refer to a
specific INVITE, but the surrounding context doesn't imply one.

Section 22.1, line 4840
>   UACs creating an ACK message
>   will duplicate all of the Authorization and Proxy-Authorization
>   header field values that appeared in the INVITE to which the ACK
>   corresponds.

Does this only apply to end-to-end ACKs, or should proxy servers insert
Authorization and Proxy-Authorization in hop-by-hop (non-2xx) ACKs as well?

Section 25.1, line 5640
>   This is intended to behave exactly as HTTP/1.1 as described in RFC
>   2616 [8]. 

I'd change the first "as" to "like" -- it flows better.

Section 25.1, table, above line 5682
>        transport-param   =  "transport="
>                             ( "udp" / "tcp" / "sctp" / "tls"
>                             / other-transport)

"tls" should be dropped here.

Section 25.1, table, above lines 5695 and 5696
>        Accept-Encoding  =  "Accept-Encoding" HCOLON
>                            ( encoding *(COMMA encoding) )
>        encoding         =  codings *(SEMI accept-param)

>        Accept-Language  =  "Accept-Language" HCOLON
>                            ( language *(COMMA language) )
>        language         =  language-range *(SEMI accept-param)

When I said in my comment to 07.9 that Accept-Encoding and Accept-Language's
parameters should be just like that of Accept, I didn't mean it *this*
literally.  A-E and A-L ought to have their own grammar elements, probably
"a-e-param" and "a-l-param", defined the same as that of accept-param.

This allows people adding new header paramers in a SIP extension to just
redefine the BNF elements accept-param, a-e-param, or a-l-param, without
having their new parameters apply to all three headers.

Section 25.1, table, above line 5711
>        wkday         =  "Mon" / "Tue" / "Wed"
>                         / "Thu" / "Fri" / "Sat" / "Sun"
>        month         =  "Jan" / "Feb" / "Mar" / "Apr"
>                         / "May" / "Jun" / "Jul" / "Aug"
>                         / "Sep" / "Oct" / "Nov" / "Dec"

Since section 20.17 says that the Date is case-sensitive, these grammar
elements probably need to be spelled out in hex.

Section 26.2.1, line 5907
>   TLS provides transport-layer security over connection-oriented
>   protocols (for the purposes of this document, TCP); "tls" (signifying
>   TLS over TCP) can be specified as the desired transport protocol
>   within a Via header field value or a SIP-URI.

Looks like a pre-sips remnant.

Section 26.2.1, line 5917
>   For
>   purposes of backwards compatibility, proxy servers, redirect servers,
>   and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Backward compatibility with what?  2543 didn't say anything about TLS, other
than that it would be a nice idea to use it.  We don't have to keep
compatibility with older bis drafts.

Section 26.2.2, line 5943
>   The use of
>   "transport=tls" has consequently been deprecated, partly because it
>   was specific to a single hop of the request. This is a change since
>   RFC 2543.

Again, 2543 didn't say anything about TLS.  This is a change since earlier
bis drafts, only, and so probably shouldn't be mentioned.

Section 28.1, line 6391
>        o Comments (expressed with rounded brackets) have been removed
>          from the grammar of SIP.

Comments are still present in Retry-After, Server, and User-Agent.  I think
this is okay, but the change notice should clarify this.

-- 
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