[sipcore] Editorial comments on rfc4244bis-02

Hadriel Kaplan <HKaplan@acmepacket.com> Sun, 07 November 2010 03:48 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603DB3A69C9 for <sipcore@core3.amsl.com>; Sat, 6 Nov 2010 20:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level:
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3SKXi8Tu-zL for <sipcore@core3.amsl.com>; Sat, 6 Nov 2010 20:48:41 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1932A3A69A7 for <sipcore@ietf.org>; Sat, 6 Nov 2010 20:48:41 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 6 Nov 2010 23:48:57 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 6 Nov 2010 23:48:55 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "sipcore@ietf.org WG" <sipcore@ietf.org>
Date: Sat, 06 Nov 2010 23:48:53 -0400
Thread-Topic: Editorial comments on rfc4244bis-02
Thread-Index: Act+LrMzO9XiO8INQXWiOQ9Q1iQ1cQ==
Message-ID: <0CDF97F6-E125-45F8-B266-65E79BAE6F1A@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sipcore] Editorial comments on rfc4244bis-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2010 03:48:48 -0000

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:bob@192.0.2.4?Reason=SIP;cause=302>;\
                 index=1.1;rc=1
whereas it should be:
   History-Info: <sip:bob@192.0.2.4?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