Subject: [Sip] further comments on bis-06

From: William Marshall <[email-masked]>
Date: Sun, 3 Feb 2002 00:34:57 -0500 (EST)

Following are additional comments to add to my original list.

First, a few general comments.  The use of MUST, MAY, SHOULD, etc, is
covered in RFC2119.  However, use of "must", "may", and "should" (in
lower case) are not spec words.  But they are confusing, and could
be misinterpreted as spec words.  Therefore, wherever I saw one
of them, I included an editorial change below to re-word the
sentence without it.

Second, the reference structure helps a lot in understanding the
protocol, but should not be normative.  In particular, normative
language regarding interaction between layers of the reference
structure is not appropriate.  Wherever I saw such use of a MUST,
I included an editorial change below to re-word the sentence without
the spec word.

Section 10.3 has a noticeable lack of spec words.  I recommend the
following be promoted:  line 1647 must to MUST; line 1667 sends to MUST
send; line 1675 returns to MUST return; line 1698 is to MUST be; line 1699
updates or removes to MUST update or remove; line 1703 are to MUST be; 
line 1704 fails to MUST fail; line 1705 are to MUST be.

Section 12.2.1 and 12.2.2, it is not clear that UAC/UAS might be different
than the roles in the initial INVITE.  This could be clarified in 12.2,
or make the following changes:
line 1892:	change to "Behavior of UA initiating a request within a dialog"
line 1921,1928,1930, and 1943:	change UAC to UA
line 1946:	change to "Behavior of UA receiving a request within a dialog"
line 1948,1951,1952,1956,1957(4timess),1959,1964:	change UAS to UA

Minor technical items:

Content-Length is never mentioned as a header that a proxy MUST add;
however, if the UA sends a request/response over UDP (and therefore
without a Content-Length header) but the proxy uses TCP, then the 
proxy must add it.

Section 8.1.1.6, line 1040:  My recollection of the list discussion
was that the value 70 was RECOMMENDED, not MUST.  But perhaps I
missed something.

Section 8.1.4.5:  While processing the list of Contact headers, if one
returns another 3xx response with more Contact headers, ...
Perhaps some words should be added about adding to the list,
and not replacing the previous list.

Section 10.2.4, line 1606:  "unless redirected." seems to be the only
mention anywhere about a 3xx response to a REGISTER.  Is this allowed?
Perhaps it should reference 8.1.4.5 in line 1606.

Section 10.2.7, line 1630:  "SHOULD wait some reasonable time interval"
is untestable.  Suggest changing to "MUST NOT retry immediately.."

Section 11.2, line 1748:  "The response code chosen is the same that
would have been chosen had the request been an INVITE."  The "is" should
be a spec word.  Should it be a SHOULD or a MUST?

Section 12.1.1, line 1831:  "and have global scope".  This seems
particularly NAT-unfriendly, even for local calls with both parties
behind the same NAT.  Also it is given as a requirement for the UAS, but
not the UAC.  I recommend it be dropped here.

Section 15, line 2285-6:  "A UA joining a multicast session MAY terminate
the SIP dialog immediately after the INVITE transaction used to join 
the session has completed."  I'd hate to recommend such an action, since
it may have unintended consequences to the QoS of the media stream in
some cases.

Section 15, lines 2291-2295, spec language is very confusing.  "As a
general rule...MUST"  later "SHOULD".  I think these are clear MUSTs.

Section 16.7.  Timer C fires, and the proxy resets it with an infinite
value.  Is that really OK?  We already allow the proxy to have an arbitrary
large initial setting of Timer C.  Perhaps 16.7 should say the proxy SHOULD
generate a CANCEL.

Section 23.1.6, line 4660:  shouldn't there be a "user=phone" on
these SIP URLs?  Also 4662, 4671, 4672, 4678, 4679, 4689, 4694.

Editorial changes:
line 702:	...ACK for the response... to ...ACK for the response to
	an INVITE transaction...
line 702-3:	...ACK for a 2xx response... to ...ACK for a 2xx response
	to an INVITE transaction...
line 922:	add "Note the Content-Length header is always present
	with UDP."
line 994:	change"ahhs.aa" to "localhost"
line 1005:	is the space allowed between ">" and ";tag"?
line 1059:	bad section number cross reference
line 1065:	change "Only a single URI MUST be present" to "A Request
	MUST NOT contain multiple Contact header values."
line 1091:	change to "See Sections 24.11 through 24.15."
line 1278:	change SHOULD to "will typically".  Spec is in line 8146.
line 1281:	change should to SHOULD.  Possibly to a MUST
line 1311:	change "MUST do so if support for tht extension is indicated
	in the Supported header in the request" to "MUST NOT do so if that
	extension is not listed in the Supported header in the request."
line 1314:	can't spec new specs.  Change sentence to "To ensure that this
	can be fulfilled, any specification of a new extension needs to
	include a discussion of how to return gracefully to baseline SIP ..."
line 1319:	"NOT RECOMMENDED" is not a spec word.  Change sentence to
	"This behavior will generally break interoperability, and SHOULD NOT
	be done."
line 1398:	for consistency, change GSTN to PSTN.  only occurence.
line 1406:	needs spec word.  change to "Malformed values SHOULD be
	treated as equivalent to 3600."
line 1410:	spec is in UAC section, change here to "... the extension will
	be taged in the Proxy-Require field..."
line 1489:	change first sentence to "SIP proxies offer a discovery 
	capability"
line 1489-90:	change "... SIP must discover the current host(s) that 
	the destination user is reachable at." to "... a SIP proxy 
	discovers the current host(s) where the destination user is
	reachable."
line 1517:	change "may" to "can"
line 1519:	change "may" to "can" twice
line 1538.5:	add "A REGISTER request MUST NOT contain Record-Route or
	Route header fields."  (This is currently in the server section,
	line 1642, but is actually a UAC requirement.)
line 1458:	change to a spec word.  "Malformed values SHOULD be treated
	as equivalent to 3600."
line 1550-1:	change "...to which SIP requests for the address of record 
	should be forwarded." to "... to which the UAC desires requests to be
	forwarded."
line 1576:	needs a spec word.  "...a default suggestion of one hour 
	(3600) SHOULD be assumed."
line 1589-90:	change "but it MUST only be used when the Expires header
	field is present with a value of "0"." to "but it MUST NOT be used
	unless the Expires header field is present with a value of "0"."
line 1627-8:	change "UACs should follow the procedures ..." to
	"UACs follow the procedures ..."
line 1642:	change "MUST NOT" to "will not".  Spec language inserted
	at 1538.5 above.
line 1644:	change "A registrar must know" to "A registrar knows"
line 1647:	should be a spec word.  "Each REGISTER message MUST be
	processed independently of any other registration or binding changes."
line 1768:	change UA to UAS
line 1792:	no space in "method-independent"
line 1872:	change UA to UAS
line 1961:	change must to MUST
line 2008:	change UA to UAC
line 2015:	change UA to UAC
line 2016:	change UA to UAS
line 2020:	change Caller to UAC
line 2025:	change UA to UAC
line 2026:	change UA to UAC
line 2031:	change UA to UAC
line 2034:	change UA to UAC
line 2064:	drop space before closing right paren
line 2074:	change "Section 24" to "Section 24 and 23.1.4"  But nowhere
	can I find rules for comparing CSeq header values.
line 2098-9:	change "2xx response using the procedures of Section 12.1.2.
	Otherwise, a new dialog in the "confirmed" state is constructed in
	the same fashion." to "2xx response using the procedures of
	Section 12.2.1.2.  Otherwise, a new dialog in the "confirmed" state
	MUST BE constructued using the procedures of 12.1.2."
line 2103,2109:	I don't think the spec should specify which element in the
	reference architecture MUST generate a particular request.  Suggest
	changing "UAC core" to "UAC".
line 2120:	change caller to UAC
line 2121:	change caller to UAC
line 2122:	change Callee to UAS
line 2148:	change to "If the INVITE does not contain a session 
	description, the UAS is being asked to participate in a session and 
	the UAC has asked that the UAS provide the offer of the session."
line 2150:	change callee to UAS
line 2152: 	change to "If the UAS is not able to answer the invitation
	immeidately, it can choose to indicate some kind of progress..."
line 2158:	change "will require" to "desires"
line 2186:	add space after period before "Note"
line 2208:	change "NOT RECOMMENDED" to "SHOULD NOT be done,"
line 2227:	drop "Note that, as opposed to initial INVITEs (see 
	Section 13)." and change "re-INIVTEs" to "Re-INVITEs"
line 2230:	change "Note that a UAC" to "A UAC"
line 2312:	change "uses BYE request" to "uses a BYE request"
line 2328:	spurious space at beginning of line
line 2335:	change "and MUST pass that to the server transaction for
	transmission" to "and passes that to the server transaction..."
	i.e. remove the spec language for inter-module control flows.
line 2347:	change "proxy must first decide" to "proxy first decides"
line 2348:	change "may" to "could"
line 2404-5:	spec is in line 2403.  change "SHOULD NOT" here to "would
	not", twice.
line 2407:	change "may" to "can"
line 2421:	change "field value with A sent-by" to ".. a sent-by"
line 2431:	change "may" to "can"
line 2433:	change "telling the proxy it should not process the request"
	to "telling the proxy not to process the request"
line 2442:	change "the proxy must decide" to "the proxy decides"
line 2477:	add a closing right paren
line 2499:	change "may" to "can"
line 2529:	I think this "must" should be a spec word, "MUST"
line 2545:	change "Only those fields detailed in the processsing 
	described below may be removed." to "Fields not detailed in the 
	process described below MUST NOT be removed."
line 2583:	should be a spec word, change must to MUST
line 2586:	should be a spec word, change must to MUST
line 2699.5:	add point 2, Record Route
line 2700:	change to point 3
line 2814:	change "may" to "could"
line 2817:	change "The client must receive all of those challenges and 
	supply credentials..." to "The client receives all of those 
	challenges and supplies credentials..."
line 2833-4:	change "one of the operations it must perform is" to "one
	of the operations is performs is"
line 2850:	change "the proxy may perform any feature..." to "the proxy
	performs any feature..."
line 2852:	ref to "Section 3" should probably be to "Step 3"
line 2854:	"The proxy MUST pass the response to the server transaction
	associated with the response context" to "The proxy passes the 
	response..." i.e. remove the spec word for internal control within
	the reference design
line 2857:	"..the element MUST forward the response statelessly by
	sending it to the server transport."  Again, we should not spec
	control within the reference design.  "...the element forwards ..."
line 2858:	change "should" to "would"
line 2888:	change "may" to "can"
line 2892:	change "INVITEs" to "INVITE's"
line 2912:	should be a spec word, change "must" to "MUST"
line 2913:	should be a spec word, change "must" to "MUST"
line 2920:	should be a spec word, change "must" to "MUST"
line 2949:	should be a spec word, change "inspects" to "MUST inspect"
line 3051:	another spec word related to design of future extensions.
	change "SHOULD" to "would"
line 3126:	add the text from lines 3143-4 immediately after the
	section title:  "These rules for construction of ACK only apply
	to the client transaction.  A UAC core which generates an ACK for 
	2xx MUST instead follow the rules described in Section 13."
lines 3143-4:	moved to line 3126, so drop
line 3159:	capitalize, "Non-INVITE"
line 3270:	capitalize, "Non-INVITE"
line 3382:	change "may" to "can"
line 3400:	change "MUSTcontain" to "MUST contain"
line 3401:	change "MUSTinclude" to "MUST include"
line 3617:	remove extra space "Digest   need"
line 3624:	remove space in "auth-scheme"
line 3629:	remove space in "Proxy-Authorization"
line 3658:	drop lc "should"  requirement given elsewhere for UAC
line 3720:	add "All" before 407, to not start sentence with digit.
line 3754:	add closing right paren after 16.6
line 3757:	spec is in section 16.6, change "MUST be" to "is"
line 3765:	also in 16.6, change "MUST be" to "is"
line 3767:	also in 16.6, change "MUST be" to "is"
line 3775:	drop space in "Proxy-Authenciation"
line 3859:	should be a spec word, change "should" to "SHOULD"
line 4261:	change "MUSTNOT" to "MUST NOT"
line 4600:	bad cross reference to undefined section
line 4626:	change "must" to "needs to"
line 4745:	move 'a' to be in alphabetical order, above 'c'
line 4748:	move 'o' to be in alphabetical order, after 'm'
line 4757:	move 'c' to be in alphabetical order, before 'm'
line 4839:	remove space from "case-sensitive"
line 6774:	rfc 1806 superceeded by 2183.

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Fri, 08 Feb 2002 14:12:02 -0600

> of them, I included an editorial change below to re-word the

Thanks for pointing at these.

   > I included an editorial change below to re-word the sentence without

Where the requirement could have been confusing, I made an adjustment.
In general, these are concise statements of "MUST follow the steps
specified in xxxx". I don't see them causing harm.

   > line 1704 fails to MUST fail; line 1705 are to MUST be.

I made these changes and touched other places like them in this section.

   > line 1948,1951,1952,1956,1957(4timess),1959,1964:	change UAS to UA

Reiterated in 12.2 that UAC/UAS are roles a UA plays and
that those roles may change from transaction to transaction in a dialog.

   > without a Content-Length header) but the proxy uses TCP, then the

Per separate thread - the ability to add when transiting between UDP and
a stream-oriented protocol will be reflected in the appropriate places.

   > was that the value 70 was RECOMMENDED, not MUST.  But perhaps I

This was fixed in time for -07.

   > and not replacing the previous list.

Good idea.

   > Perhaps it should reference 8.1.4.5 in line 1606.

3xx to a unicast REGISTER is allowed. The text will be modified to make
this more clear.

   > is untestable.  Suggest changing to "MUST NOT retry immediately.."

I made a similar adjustment (to SHOULD NOT, not MUST NOT).

   > be a spec word.  Should it be a SHOULD or a MUST?

Changed to MUST based on the text around it.

   > not the UAC.  I recommend it be dropped here.

The requirements for the UAC are reflected where the UAC forms requests
for messages in a dialog, but not for initial requests. That will be
corrected.

The global scope here means valid outside the scope of the dialog, not
globally resolvable in DNS. The question being answered is whether a
URI provided in a Contact header in a dialog initiating or refreshing
message can be used outside that dialog. The text will be modified to
be more precise.

   > it may have unintended consequences to the QoS of the media stream in

MAY is not a recommendation. Having a MAY allows a UA to drop the dialog
state if it no longer needs it. However, your point that terminating
the dialog may have side-effects in the network is well taken.

   > general rule...MUST"  later "SHOULD".  I think these are clear MUSTs.

We'll straighten out the text.

   > large initial setting of Timer C.  Perhaps 16.7 should say the proxy
SHOULD

If a proxy wants to extend the time the transaction can pend, why not
let it. If it decides to quit checking in on the transaction and use
an infinite value, that should be its prerogative (the transaction
will eventually be torn down by the actions of the endpoints). This
allows a proxy to decide to extent individual transactions as they
progress.

   > these SIP URLs?  Also 4662, 4671, 4672, 4678, 4679, 4689, 4694.

Sure - I'll add it.

Unless I've commented below, the Editorial changes below have been addressed

   > line 994:	change"ahhs.aa" to "localhost"

Do you feel strongly about this one? There's pushback the other way.

   > line 1005:	is the space allowed between ">" and ";tag"?

Yes

   > line 1278:	change SHOULD to "will typically".  Spec is in line 8146.

8146 must be a typo - where were you pointing?

   > 	"This behavior will generally break interoperability, and SHOULD NOT

Actually, "NOT RECOMMENDED" is an alias for "SHOULD NOT" in RFC2119.
We'll add "NOT RECOMMENDED" to the list in Section 3 (its the only
normative descriptor defined in RFC2119 that isn't currently reflected
in Section 3).

   > 	line 1642, but is actually a UAC requirement.)

And its not quite right. Record-Route has no meaning for Register,
but Route can (in the case of preloaded Routes). This text, and the
other places where this is discussed will be fixed. Your point about
keeping the normative text in the right sections will be reflected.

   > line 1872:	change UA to UAS
Changed to "remote UA" instead
   > line 1961:	change must to MUST
Changed to "need to". MUST take into consideration is untestable.

   > line 2016:	change UA to UAS

I disagree with those two - the roles the two UAs are playing are pretty
clear, and the dialog is established between the UAs. Saying a dialog
is established between a UAC and a UAS will lead some to confusion when
it comes time to send a request in the opposite direction.

   > line 2025:	change UA to UAC

Again, I think UA is right - it will be playing the UAS role on the
mentioned subsequent requests.

   > line 2031:	change UA to UAC

The above two similarly discuss things about the UA when it can either
be acting as a UAC or a UAS.

   > 	can I find rules for comparing CSeq header values.

Section 24 points back to 23.1.4 where it needs to.
However, I think this line should be modified to reuse the
request/response matching text in the transaction section.

I don't see a place that says "two CSeq header fields are equal if"
either. That'll get fixed.

   > 	changing "UAC core" to "UAC".

The point here is that it is the TU (synonym for core - see TU in the
definitions) is responsible for the ACK. The transaction layer
is not going to handle it.

I don't understand your objection - can you clarify?

   > line 2529:	I think this "must" should be a spec word, "MUST"

I don't think a lowercase must introduces a possibility for confusion
here.

   > 	challenges and supplies credentials..."

used "needs to"

   > line 2888:	change "may" to "can"

Made it MAY