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

From: William Marshall <[email-masked]>
Date: Mon, 4 Feb 2002 12:26:51 -0500 (EST)

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Feb 2002 14:43:25 -0500

> were a number that I feel are more important.  These I'm repeating here

No, they were not ignored. We did not get to them. THere were tons of
comments, Bill, and there was no way to get them all in before bis-07.
We are not supermen, and it was already quite an effort to get this out
with all the bnf comments and the new loose route, unify, and other
text. One of us will answer your comments on the list shortly.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Robert Sparks <[email-masked]>
Date: Mon, 04 Feb 2002 17:24:37 -0600

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

> Affects lines 1094-7, 1103-4, 1306-7

I'll let the chairs comment on this.

> Content-Length, column for Proxy, change to "amr".

Bug entered - this will be fixed in -08.

> then need a change, "in the same fashion" to "using the procedures of

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

> 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

> 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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 04 Feb 2002 18:48:08 -0500

> requirements on future extensions the _only_ class of requirements

My suggestion is that all of them should move into or close to the IANA
sections, since they are needed by things that need IANA registration in
any event. The section can then be prefixed by a "this is for specifying
compliancy of protocol designers, not implementations" (obviously, not
worded that way...)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Feb 2002 16:33:20 -0500

going through this thread, logging the bugs needed to be fixed. Ran into
a question here:

> Affects lines 1094-7, 1103-4, 1306-7

I think much of this thread was not properly interpreted by the list,
because people are not aware of the specific content of these lines. And
that makes a big difference.

These lines are about the usage of option tags in Supported and Require.
The spec says that these headers can only contain references to
standards track RFCs. That does NOT mean that one can't define an
extension to sip outside of IETF and use it (that is covered by
tsvchange). This requirement does say that such an extension could not
be *required* by clients, and it cannot be indicated as being explicitly
supported (which would allow servers to require it).

These words about Require and Supported come from IESG, and they are
based on bad experiences with protocols in the past that did not have
such restrictions. Specifically, a protocol in the past allowed for
mandatory vendor specific extensions. This was abused by a large vendor,
whose servers always required support of their extensions from clients.
That vendor was able to call their product compliant to the spec. What
we are hoping to avoid is similar problems with SIP. You can't force
someone to only put standards-track tags in Require/Supported, but if
they do, you can at least publically state that it is not compliant to
the specification.

Since this issue is really independent of tsv-change, there is no need
to reference tsv-change at all, and I have no plans to do so.

-Jonathan R.