Subject: [Sip] Revised draft: draft-willis-sip-path-06

From: "Dean Willis" <[email-masked]>
Date: Mon, 13 May 2002 18:35:22 -0500

Bernie and I have revised the Path draft to account (I think) for all
comments received during WGLC.

The latest version is available at:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.html
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.xml

Note: Insertion of this draft into the internet-drafts list should be
announced to the SIP working group.

Note that one of the big changes was using the term "header field" to
refer to what is colloquially called a "header" and "header field value"
for an element that might go into a header field. There were also
significant enhancement to the security considerations section and
general editing to correct typos and use consistent terminology. Thanks
for all the feedback, folks.

--
Dean Willis

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Tue, 14 May 2002 11:32:59 -0400

Here are some comments on the new path draft.

Section 1, 1st paragraph: s/p roxies/proxies/

Section 2: There is an inconsistency between the applicability statement
(point 2) and the statement in section 4.2 that the path-vector can be
discongruent with the route taken by the REGISTER request. I think the
statement in 4.2 is fine, but the applicability statement seems to prohibit
it.

Section 2: Is the MUST in point 2 of the applicability statement an RFC 2119
MUST? Also, does the document need an RFC 2119 terminology section?

Section 3, Last paragraph on page 4: Suggest changing "Support for the Path
header field may be indicated by...." to "Support for the Path header *is*
indicated by..." (or "is usually") since a UA is suppose to include the
Supported header to indicate its wiliness to have a path applied.

Section 4.1, 2nd paragraph: Does this need to be a normative statement "The
UA SHOULD include the option tag..."?

Section 4.1, 2nd paragraph: s/vfield/field/

Section 4.2, last paragraph: s/alterany/alter any/

Section 4.2, last sentence: This implies that proxies may alter Path header
values, but the table 3 addition on page 5 does not allow it. Under what
circumstances would a proxy alter the path values? RFC 3261 allows a proxy
to modify Record-Route in a response (according to table 3 & section 16.7),
but only the value that the proxy inserted. Do we need a similar requirement
here?

Section 4.3, 2nd paragraph: Should this note on the lr parameter be moved to
section 4.2 since it applies to the proxy rather than the registrar?

Section 4.3, 3rd paragraph: Do we need a normative statement here? Say "The
RECOMMENDED policy is for the registrar....".

Section 4.3, 3rd paragraph: I says a 420 is sent in the response. Shouldn't
this be a 421 (Extension Required) because the UA did not include
Supported:path. If it sends 420 with Unsupported: path, the UA won't know
what to do if it does not understand the path extension. Based on section
4.2, we are assuming that if there is a Require: path present, that an
intermediate proxy inserted it. Sending 420 assumes the UA put in
Require:path. If there is no Require:path, then 420 is definitely the wrong
response.

Section 4.5.1: a nit, but the REGISTER responses in the example do not have
a To tag as required by RFC 3261.

Section 5.1, last paragraph, next to last line:
s/that an intermediate has altered/that an intermediate proxy has altered/

Section 5.2, last paragraph: s/In addtion to/In addition to/

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]