Re: [Sip] Last Call comments on 2543bis-07

[Robert Sparks <[e-mail]>]

William Marshall wrote:

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


This class of requirement is obviously on future specifications, not
implementations. As such, you could argue that they belong in the
guidelines draft. I would have no problem moving the three examples you
present here, but I get the feeling that this isn't a complete list. Is
requirements on future extensions the _only_ class of requirements
giving you trouble?

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


I'll let the chairs comment on this.


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


Bug entered - this will be fixed in -08.


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


The sentence says to update the route set as per 12.1.2, not follow all
of 12.1.2. This will be made more clear. 12.2.1.2 isn't strong enough,
the route-set really does get replaced when transitioning from early
to confirmed. Only the remote target gets updated by route refresh
requests (suggesting they are now badly named). I agree with the change
to "in the same fashion".


> 
> Some editorial stuff I mentioned before that still _needs_ to be fixed:
> 1081:  bad cross reference to "sec:proxy-response-processing-via"

fixed

> 2719.5:  add "record route" between steps 1 & 2, to match the description.

done

> 2665: wrong cross reference, should probably be "Step 3"

I disagree - it is a reference to what endpoints do with Record-Route,
not proxies.

> 4776:  bad cross reference to "sec:header-fields"

fixed

> 6316:  rfc1806 has been supersceeded by 2183

bug entered

> 
> Some editorial stuff that _really should_ be fixed, but was overlooked:
> 1385:  s/GSTN/PSTN/  (for consistency with PSTN in rest of document)

changed

> 2740:  remove the stray semicolon

done

> 3494:  s/MUSTcontain/MUST contain/

done

> 3495:  s/MUSTinclude/MUST include/

done

> 3524:  s/MUSTbe/MUST be/

dine

> 5018:  s/case- sensitive/case-sensitive/

done

> 6075:  s/optio/option/

done

> 6077:  needs a closing right bracket
done



_______________________________________________
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