[Sip] Last Call comments on 2543bis-07

[William Marshall <[e-mail]>]

I see that most of my editorial corrections to bis-06 were ignored
by the editors.  While I accept that as editor's discression, there
were a number that I feel are more important.  These I'm repeating here
as last-call comments.

1) I'm still concerned by the number of "untestable MUSTs" in bis-07.
For example, an implementation of a UA has no control over definition
of future extensions of SIP, yet those are given as MUST-strength
requirements.  Example, in lines:
  889:  All new header fields MUST follow this generic format...
  1298: specification of a new extension MUST include discussion...
  3140-2:  Protocol extensions ... SHOULD use two transactions...

2) Carriers are unfortunately obliged to meet regulatory requirements.
At least some of these, related to Electronic Surveillance, will not
be standardized by IETF (see RFC 2804), though publication is 
encouraged (presumably as informational RFCs).  However, they may require
extensions to SIP, and definition of additional headers and option tags.  
It would be unfortunate if this resulting protocol could not be called 
SIP.  This is an ugly subject, granted, and I do not want it to delay 
publication of bis as an RFC.  My proposed resolution of this is
to have bis make reference to draft-tsvarea-sipchange-xx for the
guidelines of extensions being standard-track RFCs, and have the 
discussion when that draft is re-issued and last-called.
Affects lines 1094-7, 1103-4, 1306-7

3) The Content-Length header may need to be added by a proxy, like
if the UA sent the request/response via UDP without one, and the proxy
uses TCP.  Nowhere is this allowed.  Affects Table 2, line for
Content-Length, column for Proxy, change to "amr".

4)  When a dialog exists due to a provisional response, the 2xx response
moves it to "confirmed" (lines 2091-3).  However, the local sequence
number can't be reset to the value of the request - that would result
in the same CSeq being used as was in a PRACK.  So the reference to
Section 12.1.2 in line 2093 is wrong.  I believe the solution is to
reference Section 12.2.1.2, which updates the dialog state (and
consider the INVITE as a "route refresh request").  Line 2094 would
then need a change, "in the same fashion" to "using the procedures of
Section 12.1.2"

Some editorial stuff I mentioned before that still _needs_ to be fixed:
1081:  bad cross reference to "sec:proxy-response-processing-via"
2719.5:  add "record route" between steps 1 & 2, to match the description.
2665: wrong cross reference, should probably be "Step 3"
4776:  bad cross reference to "sec:header-fields"
6316:  rfc1806 has been supersceeded by 2183

Some editorial stuff that _really should_ be fixed, but was overlooked:
1385:  s/GSTN/PSTN/  (for consistency with PSTN in rest of document)
2740:  remove the stray semicolon
3494:  s/MUSTcontain/MUST contain/
3495:  s/MUSTinclude/MUST include/
3524:  s/MUSTbe/MUST be/
5018:  s/case- sensitive/case-sensitive/
6075:  s/optio/option/
6077:  needs a closing right bracket


Bill Marshall
[e-mail]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip