[salud] Christer's review of draft-ietf-salud-alert-info-urns-09

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 07 January 2014 12:05 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0A7631ADFA0 for <salud@ietfa.amsl.com>; Tue, 7 Jan 2014 04:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id U8mym3nm2QQ3 for <salud@ietfa.amsl.com>; Tue, 7 Jan 2014 04:05:25 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 051AA1AD9B7 for <salud@ietf.org>; Tue, 7 Jan 2014 04:05:24 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-39-52cbed7b47f9
Received: from ESESSHC009.ericsson.se (Unknown_Domain []) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 79.16.23787.B7DEBC25; Tue, 7 Jan 2014 13:05:15 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC009.ericsson.se ([]) with mapi id 14.02.0347.000; Tue, 7 Jan 2014 13:04:41 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "salud@ietf.org" <salud@ietf.org>
Thread-Topic: Christer's review of draft-ietf-salud-alert-info-urns-09
Thread-Index: Ac8LoI2GwVZiq6LbSqq5Xri0pXR59A==
Date: Tue, 7 Jan 2014 12:04:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5EF0E7@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5EF0E7ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvrW7129NBBsve6lrc7TjA6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF2rd7EWzA+qeLhjA3MD40r3LkZODgkBE4mLf7tYIWwxiQv3 1rOB2EIChxglJqzI62LkArIXM0qcmbaOvYuRg4NNwEKi+582SI2IgKrE9dXdLCC2sICjRNfi O2wQcTeJ5+vnMUPYehLzml+B1bAIqEh09t5hB7F5BXwlOt6+BtvLCLT3+6k1TCA2s4C4xK0n 85kg7hGQWLLnPDOELSrx8vE/qDsVJa5OXw5Vny/xYVsr1ExBiZMzn7BMYBSahWTULCRls5CU QcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM7LmJmTnp5YabGIFBf3DLb90djKfOiRxi lOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY1635CW+icd5GjRry0oVpSS9 045VtfsXTzPreRNY71hn+NB58k7+eQJ7b28wuNJ55eXqOv1JS+adePW+6UTe2zreH7OWTLi3 qjlxaup1//rjFzg+L9yzX1z3ckfy59OqX2t0l1o8UUx1sl0o0jSvVUvupBH/fgfdhVHxSQ4n 6re+PLkv9niwvhJLcUaioRZzUXEiAOucW7pIAgAA
Subject: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 12:05:28 -0000


I have now read the draft. In general I am ok with it. There is text which is not wrong, but which I think could be simplified, but I will not focus on that.

Some comments below.


Remove the references from the Abstract.


There are a number of editorial inconsistences that needs to be fixed.

E.g. "Alert-Info header field" vs "SIP Alert-Info header field" vs "Alert-Info"

E.g. "180 (Ringing)" vs "180 Ringing"



As the draft updates RFC 3261, I would like to have a section named "Update to RFC 3261". Now there are only a few places in the introduction talking about the update.


I am not sure the text in section 1.2 belongs to the Introduction. It is basically the "Update to RFC 3261" section I mentioned in Q3.


I am not sure the text in section 1.3 belongs to the Introduction. We normally have a separate section.


Section 1.1 says:

"In [RFC3261] this is done by including a URI in the Alert-Info header field, that specifies the tone."

Should the text say that the header field includes a REFERENCE to a tone? Later in the paragraph, you DO talk about the referenced tone.


Section 1.1 says:

"The URI is most commonly the HTTP URL to the audio file."

s/"the audio file"/"an audio file"


Section 1.1. says:

"It is not possible to provide semantic indications or names for rendering characteristics
                that signals the intent and allows the recipient UA to decide how to render the received
information in an appropriate way."

The sentence is very confusing. Why not simply say something like:

                "It is not possible to define semantics associated with a given tone."


Section 4 defines the ABNF for the URN, but the is no text on how to "map" it into the Alert-Info header field ABNF:

For example, I assume that the URN is encoded using the opaque-part format of the absoluteURI, and that the sceme value is "urn". I think it would be good to indicate that.