Subject: [sipcore] Editorial comments on rfc4244bis-02

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Nov 2010 23:48:53 -0400

Howdy,
I read the latest 02 draft and found it better than 01. (or I'm growing numb to it ;)

I'll use the tracker for technical comments, but this email for editorials:

1) I recommend moving section 7.1 and 7.2 to be the first section after the overview - i.e., before the UA and proxy behavior sections, since those sections use terms defined in section 7.  I don't care whether 7.3 goes with it or stays put as a new section.

2) I recommend that within section 7.1, move the ABNF to be before the list of field definitions - that way it flows more naturally (and the way a lot of other RFCs are done).

3) It feels like a lot of the processing rules of a UAC are effectively the same as that of a Proxy on its client-transaction side, and the rules for a UAS are the same as that of a Proxy on its server-transaction side.  Or at least, they _should_ be the same.  For example, the UAC must do the same thing a proxy does for 3xx or failure response cases.  And a UAS has to do the same thing a Proxy does when it receives a request without itself in the bottom-most H-I.  I don't know if it's better or worse to stop copying the same text and consolidate somehow.

4) Section 7.1, pages 16/17 says:
   Note that since both the Reason and Privacy parameters are escaped in
   the hi-targeted-to-uri, these fields will not be available in the
   case that the hi-targeted-to-uri is a Tel-URI [RFC3966].
I suggest adding the following sentence after that:
"In such cases, the Tel-URI SHOULD be transformed to a SIP URI per section 19.1.6 of [RFC3261]."

5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog."  Ummm... what type of NOTIFY requests would those be?? (other than proprietary)  Actually, that raises a question - can this appear in proprietary methods?

6) Section 5.1 "In addition, the UAC SHOULD add a History-Info..." change to MUST.

7) Section 7.3.4, first bullet: s/MSUT/MUST/

8) Section 4, "(e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.)" change to "(e.g., INVITE, REGISTER, MESSAGE,
   REFER, OPTIONS, PUBLISH, SUBSCRIBE, etc.)".  Also this sentence is way ugly.

9) Section 4, page 7, second para says: "Further detailed is provided in Section 7.3.1."  Changed "detailed" to "detail".

10) Appendix B examples show H-Is which are incorrectly formatted.  Things like:
   History-Info: <sip:[email-masked]?Reason=SIP;cause=302>;\
                 index=1.1;rc=1
whereas it should be:
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
                 index=1.1;rc=1
I don't know if this was done on purpose - I recall seeing somewhere something to the effect of examples being wrong to help readability - but please don't help people by making incorrectly formatted examples. :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 01:35:16 -0500

> 5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog."  Ummm... what type of NOTIFY requests would those be?? (other than proprietary)  Actually, that raises a question - can this a…

In case of forking, NOTIFY requests can initiate a dialog.
And with 3256bis dialogs are *always* initiated by NOTIFY.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Nov 2010 07:26:56 -0500

True, I forgot about the forked case... but I don't think that's what they're talking about here, since regardless it's in the reverse direction towards the UAC and follows the SUBSCRIBE's (or REFER's) route set.  Or is the intent to use H-I for requests from the UAS to the UAC as well, in which case why isn't it used in in-dialog requests? (I don't see the point of it, but that's never stopped us before ;)

-hadriel

On Nov 7, 2010, at 1:35 AM, Paul Kyzivat wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Nov 2010 10:35:47 -0500

> True, I forgot about the forked case... but I don't think that's what they're talking about here, since regardless it's in the reverse direction towards the UAC and follows the SUBSCRIBE's (or REFE…

Sorry - I did just reply narrowly.
You are right - every NOTIFY, even the "dialog initiating" ones are 
requests that are "in dialog" and hence AFAIK don't get H-I in them, nor 
AFAIK can they affect the H-I of the SUBSCRIBE or REFER that caused them.

	Thanks,
	Paul