From Martin.Huelsemann@telekom.de  Thu May  3 02:08:30 2012
Return-Path: <Martin.Huelsemann@telekom.de>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E492021F8601 for <salud@ietfa.amsl.com>; Thu,  3 May 2012 02:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy3JPJ2vsZiJ for <salud@ietfa.amsl.com>; Thu,  3 May 2012 02:08:30 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id EB39B21F85F9 for <salud@ietf.org>; Thu,  3 May 2012 02:08:29 -0700 (PDT)
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 03 May 2012 11:08:26 +0200
Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.251]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Thu, 3 May 2012 11:08:25 +0200
From: <Martin.Huelsemann@telekom.de>
To: <dworley@avaya.com>, <salud@ietf.org>
Date: Thu, 3 May 2012 11:08:24 +0200
Thread-Topic: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday	8 May
Thread-Index: AQHNHzzfHp8dqKARSUC613YNWLMijZa32RDQ
Message-ID: <9762ACF04FA26B4388476841256BDE020115F04BAC73@HE111543.emea1.cds.t-internal.com>
References: <CD5674C3CD99574EBA7432465FC13C1B22726A0A63@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0A63@DC-US1MBEX4.global.avaya.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday	8 May
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 03 May 2012 09:08:31 -0000

Dear colleagues,

I've read the draft and I think it is ready. Thanks to the authors for the =
good work.

Regards, Martin





> -----Urspr=FCngliche Nachricht-----
> Von: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org]
> Im Auftrag von Worley, Dale R (Dale)
> Gesendet: Freitag, 20. April 2012 23:29
> An: salud@ietf.org
> Betreff: [salud] WGLC for draft-ietf-salud-alert-info-urns-06
> ending Tuesday 8 May
>
> [as chair]
>
> As nobody has indicated that there are any remaining issues
> regarding draft-ietf-salud-alert-info-urns-06, I am calling a
> working group last call, ending Tuesday
> 8 May.
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>

From christer.holmberg@ericsson.com  Fri May  4 02:17:05 2012
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7721F873A for <salud@ietfa.amsl.com>; Fri,  4 May 2012 02:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.146
X-Spam-Level: 
X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuiMC4q9yInk for <salud@ietfa.amsl.com>; Fri,  4 May 2012 02:17:05 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CDD4221F86F7 for <salud@ietf.org>; Fri,  4 May 2012 02:17:04 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-26-4fa39e8f5a6c
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 96.ED.26681.F8E93AF4; Fri,  4 May 2012 11:17:03 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 4 May 2012 11:17:02 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "salud@ietf.org" <salud@ietf.org>
Date: Fri, 4 May 2012 11:17:02 +0200
Thread-Topic: Re: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday 8 May
Thread-Index: Ac0p1qpFDtuyR/uMToyydo3im3M0qQ==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4435DC9C@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C4435DC9CESESSCMS0356e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday 8 May
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 04 May 2012 09:17:05 -0000

--_000_7F2072F1E0DE894DA4B517B93C6A05852C4435DC9CESESSCMS0356e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,



I have read the draft, and I support moving it forward.



Regards,



Christer



> As nobody has indicated that there are any remaining issues regarding

> draft-ietf-salud-alert-info-urns-06, I am calling a working group last

> call, ending Tuesday

> 8 May.

>

> Dale


--_000_7F2072F1E0DE894DA4B517B93C6A05852C4435DC9CESESSCMS0356e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoPlainText>Hi,<o:p></o:p=
></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>I=
 have read the draft, and I support moving it forward.<o:p></o:p></p><p cla=
ss=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>Regards,<o:p=
></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlain=
Text>Christer<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p=
 class=3DMsoPlainText>&gt; As nobody has indicated that there are any remai=
ning issues regarding <o:p></o:p></p><p class=3DMsoPlainText>&gt; draft-iet=
f-salud-alert-info-urns-06, I am calling a working group last <o:p></o:p></=
p><p class=3DMsoPlainText>&gt; call, ending Tuesday<o:p></o:p></p><p class=
=3DMsoPlainText>&gt; 8 May.<o:p></o:p></p><p class=3DMsoPlainText>&gt;<o:p>=
&nbsp;</o:p></p><p class=3DMsoPlainText>&gt; Dale<o:p></o:p></p><p class=3D=
MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>=

--_000_7F2072F1E0DE894DA4B517B93C6A05852C4435DC9CESESSCMS0356e_--

From prvs=5471008879=aallen@rim.com  Fri May  4 05:52:03 2012
Return-Path: <prvs=5471008879=aallen@rim.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7007E21F8618 for <salud@ietfa.amsl.com>; Fri,  4 May 2012 05:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.174
X-Spam-Level: 
X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.424,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa5c0z+2s+5z for <salud@ietfa.amsl.com>; Fri,  4 May 2012 05:52:02 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6521F8617 for <salud@ietf.org>; Fri,  4 May 2012 05:52:01 -0700 (PDT)
X-AuditID: 0a412830-b7f7d6d000000bc4-1b-4fa3d0f008a7
Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 74.48.03012.0F0D3AF4; Fri,  4 May 2012 12:52:00 +0000 (GMT)
Received: from XCT101ADS.rim.net (10.67.111.42) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 4 May 2012 08:52:00 -0400
Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.01.0339.001; Fri, 4 May 2012 07:51:59 -0500
From: Andrew Allen <aallen@rim.com>
To: "christer.holmberg@ericsson.com" <christer.holmberg@ericsson.com>, "salud@ietf.org" <salud@ietf.org>
Thread-Topic: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday 8 May
Thread-Index: AQHNKfSxg6+IbCfZmkyyqpTGhGyd+w==
Date: Fri, 4 May 2012 12:51:58 +0000
Message-ID: <BBF5DDFE515C3946BC18D733B20DAD2312359E@XMB105ADS.rim.net>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4435DC9C@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.254]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2312359EXMB105ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsXC5bjwgu6HC4v9DZZesra4MPMwo8XdjgOM Dkwev75eZfNYsuQnUwBTVAOjTVJiSVlwZnqevp1NYl5efkliSapCSmpxsq2ST2p6Yo5CQFFm WWJypYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jN S85PycxLt1XyDPbXtbAwtdQ1VLLTTejkyeid/Iep4IVJRcuDF+wNjMuMuxg5OSQETCS6m6aw QthiEhfurWfrYuTiEBLoY5J4vPghG0hCSGA5o8SpNh8IezOjxJlJ7iA2m4CyxPLfMxi7GDk4 RASyJM4s5wUJCwtESGz7OoUJxBYRiJSY2HOaDcLWk2h708kOYrMIqEi8vfeXGcTmFXCTeHrx DNgNnEC9E++vBKtnFJCV2H32OtgcZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/UPcrSiw7cZIN oj5XYsGp46wQ8wUlTs58wgJxvrTEjpNrGCcwis5CMnYWkpZZSFpmAX3GLKApsX6XPkSJosSU 7ofsELaGROucuezI4gsY2VcxCuZmFBuYGSbnJesVZebq5aWWbGIEpxQNgx2ME/ZqHWIU4GBU 4uGddW6xvxBrYllxZe4hRgkOZiUR3gtrgEK8KYmVValF+fFFpTmpxYcYXYGBNZFZijs5H5ju 8krijQ0McHOUxHljb9f6CwmkAxNYdmpqQWoRzBwmDk6QPVxSIsXANJRalFhakhEPSpbxxcB0 KdXAeM3CMkb3x0r/Y6yL2HbOLf56IZwrinHT0bzvilNse/tFWoJz/UOk/rAo9hw+POdClJGG p75JsmtISW7SBpHD0RvUu/TPyTwPTlicNj0pojz02davoncDIn+bCK8QTnkV/uyTjvjT3sBn rNyG0W8WsVW/Tslr6zOpCpgSrek2c8mHr6c+yAcpsRRnJBpqMRcVJwIAytP4sWoDAAA=
Subject: Re: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday 8 May
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 04 May 2012 12:52:03 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD2312359EXMB105ADSrimnet_
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64

DQpJIGhhdmUgbm90IHlldCBoYWQgYSBjaGFuY2UgdG8gZG8gYSBkZXRhaWxlZCByZXZpZXcg
b2YgdGhlIGZ1bGwgZHJhZnQgYnV0IHRoaXMgaXMgdmVyeSBpbXBvcnRhbnQgd29yayB0aGF0
IGlzIGdvaW5nIHRvIGJlIGltcGxlbWVudGVkIGluIGV2ZXJ5IHNpbmdsZSBtb2JpbGUgTFRF
ICg0RykgaGFuZHNldCB0aGF0IGRvZXMgVm9JUCBvdmVyIExURS4gVGhlcmVmb3JlIHRoaXMg
aXMgd29yayB0aGF0IHNob3VsZCBiZSBwcm9ncmVzc2VkIGFzIHJhcGlkbHkgYXMgcG9zc2li
bGUgYXMgdGhlIGRlcGxveW1lbnRzIG9mIGFuIGVudGlyZSBpbmR1c3RyeSBhcmUgZGVwZW5k
ZW50IG9uIGl0Lg0KDQpBbmRyZXcNCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0
bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBGcmlkYXksIE1heSAw
NCwgMjAxMiAwNDoxNyBBTQ0KVG86IHNhbHVkQGlldGYub3JnIDxzYWx1ZEBpZXRmLm9yZz4N
ClN1YmplY3Q6IFJlOiBbc2FsdWRdIFdHTEMgZm9yIGRyYWZ0LWlldGYtc2FsdWQtYWxlcnQt
aW5mby11cm5zLTA2IGVuZGluZyBUdWVzZGF5IDggTWF5DQoNCg0KSGksDQoNCg0KDQpJIGhh
dmUgcmVhZCB0aGUgZHJhZnQsIGFuZCBJIHN1cHBvcnQgbW92aW5nIGl0IGZvcndhcmQuDQoN
Cg0KDQpSZWdhcmRzLA0KDQoNCg0KQ2hyaXN0ZXINCg0KDQoNCj4gQXMgbm9ib2R5IGhhcyBp
bmRpY2F0ZWQgdGhhdCB0aGVyZSBhcmUgYW55IHJlbWFpbmluZyBpc3N1ZXMgcmVnYXJkaW5n
DQoNCj4gZHJhZnQtaWV0Zi1zYWx1ZC1hbGVydC1pbmZvLXVybnMtMDYsIEkgYW0gY2FsbGlu
ZyBhIHdvcmtpbmcgZ3JvdXAgbGFzdA0KDQo+IGNhbGwsIGVuZGluZyBUdWVzZGF5DQoNCj4g
OCBNYXkuDQoNCj4NCg0KPiBEYWxlDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIHRyYW5z
bWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlk
ZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0
ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxp
Y2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlv
bi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRo
ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2
ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBs
eSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg
c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0
aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBu
b3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K

--_000_BBF5DDFE515C3946BC18D733B20DAD2312359EXMB105ADSrimnet_
Content-Type: text/html; charset="utf-8"
content-transfer-encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89
InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu
OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj
aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov
L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9
IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt
ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRl
cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy
IDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu
VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWlu
IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv
c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k
b3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy
LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48YnI+DQpJIGhhdmUgbm90IHlldCBoYWQgYSBjaGFuY2UgdG8gZG8gYSBkZXRhaWxl
ZCByZXZpZXcgb2YgdGhlIGZ1bGwgZHJhZnQgYnV0IHRoaXMgaXMgdmVyeSBpbXBvcnRhbnQg
d29yayB0aGF0IGlzIGdvaW5nIHRvIGJlIGltcGxlbWVudGVkIGluIGV2ZXJ5IHNpbmdsZSBt
b2JpbGUgTFRFICg0RykgaGFuZHNldCB0aGF0IGRvZXMgVm9JUCBvdmVyIExURS4gVGhlcmVm
b3JlIHRoaXMgaXMgd29yayB0aGF0IHNob3VsZCBiZSBwcm9ncmVzc2VkIGFzIHJhcGlkbHkN
CiBhcyBwb3NzaWJsZSBhcyB0aGUgZGVwbG95bWVudHMgb2YgYW4gZW50aXJlIGluZHVzdHJ5
IGFyZSBkZXBlbmRlbnQgb24gaXQuPGJyPg0KPGJyPg0KQW5kcmV3PC9mb250Pjxicj4NCiZu
YnNwOzxicj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxmb250IHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij48Yj5Gcm9tPC9iPjogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0
bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjog
RnJpZGF5LCBNYXkgMDQsIDIwMTIgMDQ6MTcgQU08YnI+DQo8Yj5UbzwvYj46IHNhbHVkQGll
dGYub3JnICZsdDtzYWx1ZEBpZXRmLm9yZyZndDsgPGJyPg0KPGI+U3ViamVjdDwvYj46IFJl
OiBbc2FsdWRdIFdHTEMgZm9yIGRyYWZ0LWlldGYtc2FsdWQtYWxlcnQtaW5mby11cm5zLTA2
IGVuZGluZyBUdWVzZGF5IDggTWF5DQo8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgaGF2ZSByZWFkIHRoZSBk
cmFmdCwgYW5kIEkgc3VwcG9ydCBtb3ZpbmcgaXQgZm9yd2FyZC48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBB
cyBub2JvZHkgaGFzIGluZGljYXRlZCB0aGF0IHRoZXJlIGFyZSBhbnkgcmVtYWluaW5nIGlz
c3VlcyByZWdhcmRpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyBkcmFmdC1pZXRmLXNhbHVkLWFsZXJ0LWluZm8tdXJucy0wNiwgSSBhbSBjYWxs
aW5nIGEgd29ya2luZyBncm91cCBsYXN0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgY2FsbCwgZW5kaW5nIFR1ZXNkYXk8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgOCBNYXkuPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IERhbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu
dHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBt
YXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9y
LWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRl
IG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBi
eSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0
ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBw
bGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg
aW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0
cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmlu
dGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1
bC4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BBF5DDFE515C3946BC18D733B20DAD2312359EXMB105ADSrimnet_--

From laura.liess.dt@googlemail.com  Fri May  4 05:59:18 2012
Return-Path: <laura.liess.dt@googlemail.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DDF21F8675 for <salud@ietfa.amsl.com>; Fri,  4 May 2012 05:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6433kW7JtuA for <salud@ietfa.amsl.com>; Fri,  4 May 2012 05:59:16 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D521F85CC for <salud@ietf.org>; Fri,  4 May 2012 05:59:16 -0700 (PDT)
Received: by yenq7 with SMTP id q7so3264161yen.31 for <salud@ietf.org>; Fri, 04 May 2012 05:59:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=EILb+Ej82UY0prgZ3s7zMfvwM7suKz7Mra+ZKJTI0PQ=; b=hlcLkbWRbxEtOVwBWKtd3VPw6QlmfRWL5Umr/QhDI7vNN5wF5UcbCNoskzqiAzhByR NHatQPx0WE0gnjgimVda03ZhjNEAAsnTRwPoJaC1RwQxLLtYZMeAgHX/sk6BRLdI52+c fhcXgPzFM5xZFz4ycq27M990KqU/3t1gl2qProTlvoYowG23qQ9ujslCR8Sq8J6fq059 oIQ9ovmp7mTVbFOqrLI0+yOCufQtRf2PnpNTgtShgDS6i4UmcfdC8DG7FzbF63H0FwtB DyxJ2hqgQdzEcdwyRvw6dhO51A7f5yAMuUtpEX30M37O8ndgQJoq8T8upKxUSjcWlCsf lwjg==
MIME-Version: 1.0
Received: by 10.50.189.200 with SMTP id gk8mr2884068igc.8.1336136355633; Fri, 04 May 2012 05:59:15 -0700 (PDT)
Received: by 10.231.40.197 with HTTP; Fri, 4 May 2012 05:59:15 -0700 (PDT)
In-Reply-To: <201205041159.NAA05753@TR-Sys.de>
References: <201205041159.NAA05753@TR-Sys.de>
Date: Fri, 4 May 2012 14:59:15 +0200
Message-ID: <CACWXZj33te6PhT9_0XzORyZ6w83UL7LwHTivKkZwkt31wcY3rQ@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [salud] Fwd: draft-ietf-salud-alert-info-urns-06 : <private-name> issues
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 04 May 2012 12:59:18 -0000

Hi,

I forwarded Alfred's comments, as his original message to salud is
still stuck in the moderation queue.

Kind regards
Laura


---------- Forwarded message ----------
From: Alfred H=C3=8Enes <ah@tr-sys.de>
Date: 2012/5/4
Subject: draft-ietf-salud-alert-info-urns-06 : <private-name> issues
To: draft-ietf-salud-alert-info-urns@tools.ietf.org
Cc: salud@ietf.org


I've been asked to review draft-ietf-salud-alert-info-urns from
a URN perspective. =C2=A0To keep the message size shorter, I split my
comments into parts by the major concerns I have with the I-D.

My primary concerns regarding the chosen namespace are still
in off-list exploration stage, and so I start in this message with
the second topical area I found needing work: Alert URNs with
<private-name> components and registration requirements.


For easy reference, I quote the ABNF in Section 4 of the I-D:

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-URN =C2=A0 =C2=A0 =C2=A0 =3D "urn=
:alert:" alert-identifier
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-identifier=3D alert-category ":" =
alert-indication
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-category =C2=A0=3D name
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-indication=3D name *(":" name)
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name =3D standard-name / private-name
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0standard-name =3D label
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0private-name =3D label "." label *[ "."=
 label ]
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0label =3D let-dig [ *let-dig-hyp let-di=
g ]
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0let-dig-hyp =C2=A0 =C2=A0 =3D let-dig /=
 "-"
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0let-dig =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=
 ALPHA / DIGIT
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ALPHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =3D %x41-5A / %x61-7A =C2=A0 ; A-Z / a-z
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DIGIT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =3D %x30-39 ; 0-9
|
| =C2=A0 =C2=A0 Throughout this document, "<private-name>" is used as a syn=
tactic
| =C2=A0 =C2=A0 variable for any string conformant to the "private-name" AB=
NF
| =C2=A0 =C2=A0 above.

Editorial note:
=C2=A0The ABNF Standard, RFC 5234, actually *recommends* to enclose
=C2=A0ABNF rule names in angle brackets ("<...>") when used in prose text.
=C2=A0So the trailing clause is very redundant -- it carries some allusion
=C2=A0of doing something extraordinary while actually the recommended
=C2=A0style is bening used.
=C2=A0This visual markup is even more important in cases where rule names
=C2=A0are words in common use, with a broader meanng.
=C2=A0So I strongly recommend making use of these provisions in RFC 5234
=C2=A0and in particular also use "<name>" and "<label>" throughout the
=C2=A0draft text.

The semantical restrictions on <private-name> are spelled out later
in Section 4 ...

| =C2=A0 =C2=A0 The alert-indications are hierarchical identifiers. =C2=A0T=
he set of
| =C2=A0 =C2=A0 allowable characters is the same as that for domain names
| =C2=A0 =C2=A0 [RFC1123]. =C2=A0Labels are case-insensitive. =C2=A0Compari=
sons MUST be
| =C2=A0 =C2=A0 case-insensitive. =C2=A0Registered URNs SHOULD be transmitt=
ed as
| =C2=A0 =C2=A0 registered. =C2=A0A new name MUST NOT be registered if it i=
s equal by
| =C2=A0 =C2=A0 case-insensitive comparison to an already registered name.

.... and in Section 7.2 of the draft, which says (1st paragraph):

| =C2=A0The <private-name>" syntax is for proprietary extensions specific t=
o
| =C2=A0independent organizations. =C2=A0The "<private-name>" is used in th=
e form
| =C2=A0of a "reverse FQDN" of the entity that defines the extension,
| =C2=A0possibly followed by further components. =C2=A0Standard URNs will n=
ever
| =C2=A0contain a ".", so proprietary extensions need no further marker.
| =C2=A0This gives a way of assigning unique names without the need for a n=
ew
| =C2=A0registry. =C2=A0The namespace for each alert category is independen=
t.
| =C2=A0Those assigning new names must ensure they are in a position to
| =C2=A0assign names uniquely for the FQDN they choose.


Concern #1 :

=C2=A0 Defining syntax for domain name labels is a hornets' nest.
=C2=A0 Each time someone tries to specify precise rules, there is a storm
=C2=A0 of messages on the IETF main list. =C2=A0Recently, even attempts sta=
rted
=C2=A0 in ICANN to update the specification of domain name syntax from
=C2=A0 STD 13 and STD 3 has failed miserably.

Recommendation:

=C2=A0 Defer for <label> to the IDNAbis RFCs (cite RFC 5890) and use
=C2=A0 the terms LDH-label and A-label as defined there.

Editorial hint:
=C2=A0 Formatting the ABNF with columnar alignment of all "=3D" elements
=C2=A0 would improve the readability. =C2=A0There's enough horizontal space
=C2=A0 here to do that painlessly.


Concern #2 :

=C2=A0 URNs need to be stable and unique, cannot be de-registered,
=C2=A0 and MUST NOT be re-assigned.
=C2=A0 Bare (fully qualified) domain names do not have these properties;
=C2=A0 domain names are only delegated under commercial rules and subject
=C2=A0 to legal challenges and reassignment. =C2=A0(I have myself once suff=
ered
=C2=A0 from loss of a domain name, and later gained the reassignment of a
=C2=A0 domain name registered by a 3rd party that collided with a
=C2=A0 registered trade mark owned by my company.)

Recommendation:

=C2=A0 Other protocols in similar circumstances have observed that
=C2=A0 valid fully qualified domain names actually have a precisely
=C2=A0 defined valid owner at each instant in time, and so escaped to
=C2=A0 combining domain names for use in a persistent identifier system
=C2=A0 with a mandatory time stamp. =C2=A0Since domain name ownership chang=
es
=C2=A0 do not happen frequently and need significant time (due to
=C2=A0 registration / authority propagation delays and the persistence
=C2=A0 of cached DNS data until their TTL expires), it suffices to
=C2=A0 provide such time stamps at date granularity, e.g. with the
=C2=A0 semantics that the {FQDN,date} combination uniquely identifies
=C2=A0 the owner of the FQDN at 00:00 UTC of the specified date

=C2=A0 So if you want to retain the basic scheme, but make the assigned
=C2=A0 identifiers actually suitable for URNs, the reversed domain
=C2=A0 names should be followed by a date, for example:
=C2=A0 =C2=A0 =C2=A0 =C2=A0com.example.foo-bar-products.2012-05-03
=C2=A0 might become a valid <private-name> component for an Alert URN
=C2=A0 to be registered.


Concern #3 :

=C2=A0 The 2nd paragraph of Section 7.2 contains two examples that
=C2=A0 contradict the specification from the 1st paragraph (quoted above).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vvvv
| =C2=A0 urn:alert:service:call-waiting:abc.org.example.somecompany =C2=A0a=
nd
| =C2=A0 urn:alert:service:call-waiting:def.org.example.somecompany [...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^
=C2=A0 The company-specific labels within a <private-name> must not
=C2=A0 precede the reversed domain name.

Recommendation:

=C2=A0 Such <private-name> components could take the form of a subordinate
=C2=A0 domain name label:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vvvv
=C2=A0 =C2=A0urn:alert:service:call-waiting:org.example.somecompany.abc

=C2=A0 or be specified in a subordinate <name>, as already shown in the
=C2=A0 draft:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v
=C2=A0 =C2=A0urn:alert:service:call-waiting:org.example.somecompany:abc


Concern #4 :

=C2=A0 The registration rules for <alert-identifier>s, in particular for
=C2=A0 Alert URNs containing a <private-name> component, are not
=C2=A0 specified clearly and unambiguously in the draft.

=C2=A0 At various places, the draft uses vague phrases like
=C2=A0 the last paragraph of Section 7.1:

| =C2=A0The process for defining new Alert-Info URNs is described in
! =C2=A0Section 6.1. =C2=A0Adding new categories and adding alert-indicatio=
n
! =C2=A0values other than via the "private" mechanism described in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^
! =C2=A0Section 7.2 is standards action.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^

=C2=A0 ... and the last paragraph of Section 7.2:

| =C2=A0Adding new categories and adding alert-indication values via the
| =C2=A0"private" mechanism is not a standards action.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^

=C2=A0 Yet, Section 6.1 also doesn't give the specification needed:

| =C2=A0Alert URN identifiers are identified by labels managed by IANA,
| =C2=A0according to the processes outlined in [RFC5226] in a new registry
| =C2=A0called "Alert URN Labels". =C2=A0Thus, creating a new Alert-Info UR=
N
| =C2=A0identifier requires IANA action. =C2=A0The policy for adding a new =
alert
| =C2=A0category is 'Standards Action'. =C2=A0(This document defines the al=
ert
| =C2=A0categories 'service', 'source', 'priority', 'duration', 'delay' and
| =C2=A0'locale'. ) The policy for assigning labels to alert-indications an=
d
! =C2=A0the rules to combine them may differ for each alert-category and MU=
ST
! =C2=A0be defined by the document describing the corresponding alert
! =C2=A0category. =C2=A0[...]

=C2=A0 So, fine for <alert-category>s, but not for <alert-indication>s:
=C2=A0 none of the Sections 6.2.* contains such text.

Recommendation:

=C2=A0 Clearly specify which of the RFC 5226 registration policies shall
=C2=A0 apply to Alert URNs with <private-name> component (or define a
=C2=A0 custom IANA policy if you really feel the need to undergo such
=C2=A0 pain).

=C2=A0 Keep in mind that the persistence and uniqueness requirements
=C2=A0 for URNs need to be satisfied, so maybe "Specification Required"
=C2=A0 might be a candidate policy with minimal requirements.
=C2=A0 Other possibilities would be "Expert Review" -- which includes
=C2=A0 "Specification Required" but requires the IESG appointment of
=C2=A0 designated expert(s) -- or "RFC required".
=C2=A0 But in the former case, when the registration document is not
=C2=A0 readily available at a permanent, stable URI, you would need to
=C2=A0 require IANA to archive the registration document and link to that
=C2=A0 'escrow' copy from the publicly available Alert URN registry on
=C2=A0 the IANA web/ftp site -- but beware that past experience has shown
=C2=A0 that IANA did not like such escrow requirements very much.

=C2=A0 Either add _common_ text to section 6.1 that specifies the IANA
=C2=A0 policy for <alert-indication> assignment in all <alert-category>s
=C2=A0 specified in the draft, or actually do add such text to each
=C2=A0 Section 6.2.*, as promised in the current text of Section 6.1.


Concern #5 :

=C2=A0 The rules in Section 8.1 are not properly thought out, especially
=C2=A0 for the case of <private-name> components.

=C2=A0 In particular, the draft specifies:

! =C2=A0The implementation is free to ignore any or all parts of the receiv=
ed
! =C2=A0Alert-Info URNs. =C2=A0The exact way in which a UA renders a receiv=
ed
| =C2=A0combination of Alert-Info URNs is left as an implementation issue.
| =C2=A0However, the implementation MUST comply to following rules:
|
| =C2=A0 =C2=A0 a. =C2=A0Each alert-info URN has precedence over all URNs t=
hat follow
| =C2=A0 =C2=A0 it, and its interpretation is subordinate to all URNs that =
precede
| =C2=A0 =C2=A0 it.
|
| =C2=A0 =C2=A0 b. =C2=A0If the UA cannot implement the effect of a URN (be=
cause it
| =C2=A0 =C2=A0 does not recognize the URN or the URN's effect is precluded=
 by
! =C2=A0 =C2=A0 preceding URNs), the UA repeatedly removes either
!
! =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) the final name of the URN, or
!
! =C2=A0 =C2=A0 =C2=A0 =C2=A0(2) if the final name is a private-name with t=
hree or more
! =C2=A0 =C2=A0 =C2=A0 =C2=A0labels, the final label

=C2=A0 First, I strongly suspect that by removal of a component you
=C2=A0 also mean removal of the separator character that precedes the
=C2=A0 component being removed (a colon or period), but the draft does
=C2=A0 not say so precisely, and the separator characters (by the ABNF)
=C2=A0 are not part of the components being removed per these rules.

=C2=A0 Second, under the rules presently in the draft, removing a <name>
=C2=A0 is not guaranteed to lead to a valid (registered) Alert URN:

=C2=A0 o =C2=A0according to the ABNF in Section 4, the <alert-indication>
=C2=A0 =C2=A0 =C2=A0is not optional, so removal of the last remaining <name=
> of
=C2=A0 =C2=A0 =C2=A0an <alert-indication> (and the separator character ":")
=C2=A0 =C2=A0 =C2=A0would not yield a valid Alert URN;
=C2=A0 =C2=A0 =C2=A0(btw: the draft provides a "default" <alert-indication>=
 per
=C2=A0 =C2=A0 =C2=A0<alert-category>, which is to be assumed if no Alert UR=
N for
=C2=A0 =C2=A0 =C2=A0a particular <alert-category> is indicated, but that's =
not the
=C2=A0 =C2=A0 =C2=A0same as an "Alert URN" without an <alert-indication> co=
mponent;)

=C2=A0 o =C2=A0as far as I understand, the draft does not require to regist=
er
=C2=A0 =C2=A0 =C2=A0'truncated' versions of hierarchically subdivided
=C2=A0 =C2=A0 =C2=A0<alert-indication>s -- for instance, it can be imagined=
 that
=C2=A0 =C2=A0 =C2=A0for a particular <alert-category>, <alert-indication>s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abc:variant1 ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abc:variant2 , and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abc:variant3
=C2=A0 =C2=A0 =C2=A0get registered, but bare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0abc
=C2=A0 =C2=A0 =C2=A0is not registered as a valid <alert-indication>.

=C2=A0 Examples:
=C2=A0 - =C2=A0s6.2.1 does _not_ define "service:recall" (without an additi=
onal
=C2=A0 =C2=A0 =C2=A0<name> to qualify "service:recall";
=C2=A0 - =C2=A0s6.2.6 intentionally does _not_ define "locale:country" (wit=
hout
=C2=A0 =C2=A0 =C2=A0an additional <name> in the form of an ISO 3166-1 count=
ry code).

=C2=A0 Similarly, there is no requirement in the draft that partially
=C2=A0 truncated forms of "private" Alert URNs be registered and valid.

=C2=A0 Third, regarding sub-rule (2) above: browser implementers are
=C2=A0 struggling with dealing with recognizing "registry type" domains
=C2=A0 for the purpose of defining sensical scope boundary rules for
=C2=A0 HTTP state (cookies), but all these efforts are doomed due to the
=C2=A0 creative forces at work in domain registries.
=C2=A0 Attaching important semantics to the bare number of domain labels
=C2=A0 in an FQDN does not make sense. This will become even more critical
=C2=A0 with ICANN's new sponsored TLD program, where anybody (with enough
=C2=A0 $$$) can start registering an own TLD and sell sub-domains -- or
=C2=A0 use the TLD only company-internally. On the other hand, a URN
=C2=A0 sub-namespace also cannot be made to depend on some volatile list
=C2=A0 of "registry-like" domains in use on the Internet to distinguish
=C2=A0 "cut points" beyond which no organizational affiliation can be
=C2=A0 inferred.

=C2=A0 Further, in the DNS, there can be "empty non-terminals" :
=C2=A0 similarly as shown above for <alert-indication>s, in the DNS,
=C2=A0 subordinate domains/zones can be registered without the need to
=C2=A0 also register/populate "intermediate" domains -- for instance
=C2=A0 there might be the following, regularly delegated domains:
=C2=A0 =C2=A0 =C2=A0 jp.pacific.world-company.example.com
=C2=A0 =C2=A0 =C2=A0 kr.pacific.world-company.example.com
=C2=A0 =C2=A0 =C2=A0 de.emea.world-company.example.com
=C2=A0 =C2=A0 =C2=A0 it.emea.world-company.example.com
=C2=A0 =C2=A0 =C2=A0 il.emea.world-company.example.com
=C2=A0 =C2=A0 =C2=A0 eg.emea.world-company.example.com
=C2=A0 without the need to have delegated the domains:
=C2=A0 =C2=A0 =C2=A0 pacific.world-company.example.com
=C2=A0 =C2=A0 =C2=A0 emea.world-company.example.com
=C2=A0 from world-company.example.com -- any domain can contain
=C2=A0 delegations at any level of subordiante labels they seem fit
=C2=A0 to need.
=C2=A0 So by removing the "least significant" domain label, you might
=C2=A0 arrive at a domain name without an owner, which could not be
=C2=A0 used to construct a valid Alert URN for registration.

Recommendations:

=C2=A0 In concert with Concern #2 above, rule b.(2) does not make sense
=C2=A0 any more. =C2=A0I very strongly recommend to drop it entirely.

=C2=A0 The other corner cases explained above need to be considered and
=C2=A0 properly taken care of in the I-D.

=C2=A0 Given the definition of the Alert URNs in Section 4, specific
=C2=A0 semantics are only defined for actual, registers Alert URNs,
=C2=A0 not for arbitrarily truncated Alert URNs. =C2=A0Therefore, I believe
=C2=A0 that the sentence,

! =C2=A0The implementation is free to ignore any or all parts of the receiv=
ed
! =C2=A0Alert-Info URNs. =C2=A0[...]

=C2=A0 should perhaps better say:

! =C2=A0The implementation is free to ignore any or all of the received
! =C2=A0Alert-Info URNs. =C2=A0[...]

=C2=A0 If by that revised rule, all Alert URNs for a particular
=C2=A0 <alert-category> are dropped, according to other parts of the
=C2=A0 draft, the recipient has to assume the "default" Alert URN for
=C2=A0 that <alert-category>. =C2=A0From my point of view, that would just
=C2=A0 be fine and match the requirements. =C2=A0This seems to be confirmed
=C2=A0 by the additional text above item c. of the draft (not quoted
=C2=A0 above).

=C2=A0 So it eventually looks like the draft could easily drop the entire
=C2=A0 component stripping rules in favor of dropping unknown Alert URNs
=C2=A0 and letting the defaults step in.

=C2=A0 Further, the text in Section 9 seems to indicate that the actual
=C2=A0 intent is to always have a default for each 'dimension' (i.e.
=C2=A0 category) of alert information. =C2=A0If that's correct, it would
=C2=A0 IMHO be wise to request (in s6.1) that any new registration of an
=C2=A0 <alert-category> also specifies at least one <alert-information>
=C2=A0 to be used with that category and designates one of these as the
=C2=A0 default for that category.


Finally, a few editorial nits:

* =C2=A0Please clean up dangling hyphens (with spurious space), e.g.:
=C2=A0 "Alert -Info URNs" , "call- waiting:"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ^ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0^

* =C2=A0Please fix various typos (some of these recurring):
=C2=A0 - =C2=A0s/adidition/addition/
=C2=A0 - =C2=A0s/calback/callback/g
=C2=A0 - =C2=A0s/rinback/ringback/g
=C2=A0 (and maybe you better use "ring/ringback" without a single
=C2=A0 space on one side of the slash character)

* =C2=A0In the table in s6.2.3, the 3rd table column is partially
=C2=A0 misaligned by one character position for the 1st table entry row.

* =C2=A0In s9, I doubt that "requirements in section 7" is the proper
=C2=A0 pointer -- did you mean "... in section 2" ?

* =C2=A0In s 1.3, 1st para, s8.1, 3rd para, and s9.1, 5th para,
=C2=A0 please use the precise terminology (as anywhere else in the memo):
=C2=A0 =C2=A0 =C2=A0 s/Alert-Info header/Alert-Info header field/
=C2=A0 Similarly, in the last line of item c. in s8.1, pleas adjust:
=C2=A0 =C2=A0 =C2=A0 s/header "Priority: urgent"/header field "Priority: ur=
gent"/

* =C2=A0In s9.2.2, in one instance white space is missing after a dash:
=C2=A0 =C2=A0 =C2=A0 s/-internal high/- internal high/

* =C2=A0As a matter of taste: IMO the readability would be improved
=C2=A0 if in Section 9.2.* the presentation were a bit more compact,
=C2=A0 with less vertical white space.
=C2=A0 For instance, you might consider dropping the single blank line
=C2=A0 that precedes all item lines starting with "- "
=C2=A0 (using the =C2=A0<?rfc subcompact=3D"yes"?> =C2=A0PI and, where need=
ed,
=C2=A0 <vspace blankLines=3D'1' /> in xml2rfc).
=C2=A0 Ex.:

| =C2=A0Signal 4
|
| =C2=A0 =C2=A0 Meaning: low
|
| =C2=A0 =C2=A0 Locations:
! =C2=A0 =C2=A0 - source
! =C2=A0 =C2=A0 - priority:low



Kind regards,
=C2=A0Alfred H=C3=8Enes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: (+49)7156/9635-0, Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=A0ah@TR-Sys.de =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+------------------------+--------------------------------------------+

From laura.liess.dt@googlemail.com  Fri May  4 07:53:11 2012
Return-Path: <laura.liess.dt@googlemail.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4440D21F857D for <salud@ietfa.amsl.com>; Fri,  4 May 2012 07:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level: 
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGMIi0WprqY4 for <salud@ietfa.amsl.com>; Fri,  4 May 2012 07:53:10 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B521F85B5 for <salud@ietf.org>; Fri,  4 May 2012 07:53:09 -0700 (PDT)
Received: by yhq56 with SMTP id 56so3414980yhq.31 for <salud@ietf.org>; Fri, 04 May 2012 07:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=OYVOAvTWrKoEZbH5CgNPnIVp2I8f0usUIAOMc1CnhYY=; b=KojQRRcnfn2fc3DK5wfBkWfLDV+m8LZ23QS+/d0RcgYTRaRVvz5DOR6t8gA+opKewd gVL7+Fg2D+Icm24rsdbKrnsAHPB115j1HExxlrB1CR1FG57kyhwFsoJQFKaYtSuIaNU7 5KNPX4TloCyJEGmCOV4K0vhq+/4u2S+sOM4d7HPyGlbLuOzc++h/NER+S8gqc319D+Bz 2NHPdr7jLuHMrqQbbnZ402McmzA19XKRBxXOoz89oXXDPdR+tE6VXcsnAx8jS3Qeb46C RNjSMb0QJnvMtZTAWDWO0l36a2XjK95lolObrbbNsIJcPqE5YN7fe1JpqlNknf5A4gpj qYIw==
MIME-Version: 1.0
Received: by 10.50.158.227 with SMTP id wx3mr3226928igb.31.1336142751671; Fri, 04 May 2012 07:45:51 -0700 (PDT)
Received: by 10.231.40.197 with HTTP; Fri, 4 May 2012 07:45:51 -0700 (PDT)
In-Reply-To: <201205032021.WAA02119@TR-Sys.de>
References: <CD5674C3CD99574EBA7432465FC13C1B22726A0A81@DC-US1MBEX4.global.avaya.com> <201205032021.WAA02119@TR-Sys.de>
Date: Fri, 4 May 2012 16:45:51 +0200
Message-ID: <CACWXZj0s=v-q=pHJRsKTqcyZRt-+rnupo7_9NDque9KnOdU6cA@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: salud@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [salud] Fwd: draft-ietf-salud-alert-info-urns / high level concerns
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 04 May 2012 14:53:11 -0000

Hi,

Alfred's comments forwarded...

Thanks
Laura


---------- Forwarded message ----------
From: Alfred H=C3=8Enes <ah@tr-sys.de>
Date: 2012/5/3
Subject: Re: draft-ietf-salud-alert-info-urns / high level concerns
To: dworley@avaya.com, draft-ietf-salud-alert-info-urns@tools.ietf.org
Cc: Leslie Daigle <leslie@thinkingcat.com>


Dale,
at 26 April 2010, you wrote ...
>> From: ah@TR-Sys.de
>>
>> ...
> =C2=A0...
>
>> a) =C2=A0As soon as time avails, I'll take a closer look at the
>> =C2=A0 =C2=A0 (URN-specific parts of the) current I-D and provide feedba=
ck.
>
> That would be good. =C2=A0We are in WGLC ending 8 May.

I'm a bit late, but eventually I've been able now to start studying
draft-ietf-salud-alert-info-urns-06.

I copy Leslie Daigle (urn-nid IANA Expert).

Before proceding and going into details, I'd like to raise my primary
high-level concern and ask you to provide additional information.
(As you know, folks say that someone doing so could be an indication
that something's missing in the draft ...)
Please beware that I don't have the time to follow your WG discussions
and the primary focus of my review is the URN namespace registration
that the I-D intends to perform.

As it stands, the draft would most likely _not_ pass the urn-nid
Expert Review process (which the PROTO writeup template makes clear
needs to be undergone before the draft can be forwarded to the IESG),
because mandatory sections (per RFC 3406) are missing.
In particular, there are no Community Considerations and Namespace
Considerations sections in the I-D. =C2=A0The draft only contains short
topical paragraphs with such headlines in the registration template;
but RFC 3406 does not specify that -- it calls for solid Sections
in the registration document. =C2=A0The present paragraph for Community
Considerations might do the job, but the Namespace Considerations
are simply much too terse.

Among the questions to be asked and responded to in such section
would have been _which_ alternate namespaces have been considered and
_why_ no other existing namespace would fulfill the needs/requirements.

For instance, you want to let IANA manage the new URN namespace.
But IANA already manages a specific URN namespace for IETF protocol
parameters -- see RFC 2648 for URN:IETF and RFC 3553 for the
sub-namespace URN:IETF:PARAMS . =C2=A0Thus, it immediately came to my
mind upon reading the initial sections of the I-D that, e.g.,
urn:ietf:params:alert =C2=A0might likely be a proper home for the
intended usage.
If the draft contained the aforementioned sections (per RFC 3406),
it would have had to explain there why a new URN Namespace is needed
and the alert information cannot be placed into a sub-namespace of
URN:IETF:PARAMS (or maybe of URN:IETF, or any other potentially
suitable existing namespace).

Have such alternatives been considered?

Note that, if you'd switch to using URN:IETF:PARAMS, you would avoid
the urn-nid Expert Review process entirely and would not need the
RFC 3406 template, but only the much more simple template per
RFC 3553, Section 4, which IMHO would be very suitable in this case.


If you can show me that such considerations have taken place and
are documented, the arguments need to be put into the draft;
otherwise, I think this topic would need to be brought to your WG.

Please give me an indication so I can customize my review comments.



>
>> b) =C2=A0Did you consider the ongoing work of URNbis?
>
> No, it started work well after Salud was going.

Well, maybe looking into the rfc3406bis draft and the related
discussion might have helped to better understand RFC 3406
requirements for URN Namespace registration documents. =C2=A0 :-(

>
> Dale [chair of Salud]
>

Kind regards,
=C2=A0Alfred.
[co-chair of URNbis]

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes =C2=A0 | =C2=A0Alfred Hoenes =C2=A0 Dipl.-Math., Dip=
l.-Phys. =C2=A0|
| Gerlinger Strasse 12 =C2=A0 | =C2=A0Phone: (+49)7156/9635-0, Fax: -18 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |
| D-71254 =C2=A0Ditzingen =C2=A0 =C2=A0 | =C2=A0E-Mail: =C2=A0ah@TR-Sys.de =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+------------------------+--------------------------------------------+

From pkyzivat@alum.mit.edu  Fri May  4 08:00:40 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5621F8779 for <salud@ietfa.amsl.com>; Fri,  4 May 2012 08:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.383
X-Spam-Level: 
X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgXt6t8P0LmF for <salud@ietfa.amsl.com>; Fri,  4 May 2012 08:00:39 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 693AA21F877A for <salud@ietf.org>; Fri,  4 May 2012 08:00:39 -0700 (PDT)
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id 5qtu1j0071ZXKqc57r0XcN; Fri, 04 May 2012 15:00:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id 5r0e1j02s07duvL3hr0fJL; Fri, 04 May 2012 15:00:39 +0000
Message-ID: <4FA3EF16.9050400@alum.mit.edu>
Date: Fri, 04 May 2012 11:00:38 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: salud@ietf.org
References: <201205041159.NAA05753@TR-Sys.de>
In-Reply-To: <201205041159.NAA05753@TR-Sys.de>
Content-Type: text/plain; charset=hp-roman8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [salud] draft-ietf-salud-alert-info-urns-06 : <private-name> issues - Concern#5
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 04 May 2012 15:00:40 -0000


From pkyzivat@alum.mit.edu  Fri May  4 09:36:55 2012
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B58E21E8048 for <salud@ietfa.amsl.com>; Fri,  4 May 2012 09:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level: 
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYthEh-LFHVz for <salud@ietfa.amsl.com>; Fri,  4 May 2012 09:36:54 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id A44DE21E800F for <salud@ietf.org>; Fri,  4 May 2012 09:36:53 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id 5sMn1j0020cZkys5Asci4T; Fri, 04 May 2012 16:36:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id 5scr1j00i07duvL3WscrXk; Fri, 04 May 2012 16:36:52 +0000
Message-ID: <4FA405A4.8040001@alum.mit.edu>
Date: Fri, 04 May 2012 12:36:52 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: salud@ietf.org
References: <201205041159.NAA05753@TR-Sys.de> <4FA3EF16.9050400@alum.mit.edu>
In-Reply-To: <4FA3EF16.9050400@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [salud] draft-ietf-salud-alert-info-urns-06 : <private-name> issues - Concern#5
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 04 May 2012 16:36:55 -0000

Hmm. I had content in this message when I sent it, but it seems to have 
been lost. :-(

I'll send again when I can reconstruct it.

	Sorry,
	Paul

On 5/4/12 11:00 AM, Paul Kyzivat wrote:
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From dworley@avaya.com  Sun May  6 17:30:27 2012
Return-Path: <dworley@avaya.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1875621F8448 for <salud@ietfa.amsl.com>; Sun,  6 May 2012 17:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk4zg5AOx81C for <salud@ietfa.amsl.com>; Sun,  6 May 2012 17:30:26 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBAC21F845C for <salud@ietf.org>; Sun,  6 May 2012 17:30:26 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACMXp0+HCzI1/2dsb2JhbABEsm6BB4IMAQEBAQIBEig0EAsCAQgNCCEQMiAFAQEEARIIGodeAwYFnWCSLg2JU4oXhiVjBJwWiiqDBQ
X-IronPort-AV: E=Sophos;i="4.75,540,1330923600"; d="scan'208";a="346031757"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 May 2012 20:29:11 -0400
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 May 2012 20:13:13 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Sun, 6 May 2012 20:30:24 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Laura Liess <laura.liess.dt@googlemail.com>, "salud@ietf.org" <salud@ietf.org>
Date: Sun, 6 May 2012 20:28:18 -0400
Thread-Topic: [salud] Fwd: draft-ietf-salud-alert-info-urns-06 : <private-name>	issues
Thread-Index: Ac0p9cCAd/S2BHErTAGXl3vBTXMR/wB8ow+L
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0AAB@DC-US1MBEX4.global.avaya.com>
References: <201205041159.NAA05753@TR-Sys.de>, <CACWXZj33te6PhT9_0XzORyZ6w83UL7LwHTivKkZwkt31wcY3rQ@mail.gmail.com>
In-Reply-To: <CACWXZj33te6PhT9_0XzORyZ6w83UL7LwHTivKkZwkt31wcY3rQ@mail.gmail.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: Re: [salud] Fwd: draft-ietf-salud-alert-info-urns-06 : <private-name>	issues
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 07 May 2012 00:30:27 -0000

> From: Laura Liess [laura.liess.dt@googlemail.com]
>=20
> I forwarded Alfred's comments, as his original message to salud is
> still stuck in the moderation queue.

I am (supposed to be) the moderator of the salud mailing list, but I
have received no notification that Alfred's message has been held.
Unfortunately, I don't have any instructions for logging in as
moderator, so I have no other way to check.  I will have to inquire on
Monday.

Dale

From laura.liess.dt@googlemail.com  Mon May  7 03:53:10 2012
Return-Path: <laura.liess.dt@googlemail.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B7321F8599 for <salud@ietfa.amsl.com>; Mon,  7 May 2012 03:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCOGHnuPgz5A for <salud@ietfa.amsl.com>; Mon,  7 May 2012 03:53:07 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB98221F859E for <salud@ietf.org>; Mon,  7 May 2012 03:53:06 -0700 (PDT)
Received: by yhq56 with SMTP id 56so4840872yhq.31 for <salud@ietf.org>; Mon, 07 May 2012 03:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/QypiQhGtuyWKPeCUUrKM9IBSyy6A4uZkX2nKW+ll1U=; b=NaH2uGGJwHII5EpiohuSmUxpGENA/EJr10KtPUwn/Lyi0kdu2OhC02GqoibkP39i4L qs5yn8/kNZJWboB0MN0PkI3spqcqE5qPKZoaesdlHjKCDgUtDsVQAcIn7WidQvpVyeZg ip5UyGROPQGgjEZvxwvreoP1cjPQRBYZHsh5Iy+2Suxh7OtgjXLzcZ2VkjksdSZJsoSD CjGFwJvaQYFQyiOCnbD3gS2X85A18WV+87Ug9/0ccAgH+QXhrrViqecURiX1jgo9q5ah NPt+8NhoCmmYrnF04rhzzfhpIjjhIjxkafG2DY0EszIwL1Vsj2pGiOyZgRy7mPoRS8V/ C28Q==
MIME-Version: 1.0
Received: by 10.42.68.71 with SMTP id w7mr5783625ici.26.1336387595756; Mon, 07 May 2012 03:46:35 -0700 (PDT)
Received: by 10.231.40.197 with HTTP; Mon, 7 May 2012 03:46:35 -0700 (PDT)
In-Reply-To: <CACWXZj33te6PhT9_0XzORyZ6w83UL7LwHTivKkZwkt31wcY3rQ@mail.gmail.com>
References: <201205041159.NAA05753@TR-Sys.de> <CACWXZj33te6PhT9_0XzORyZ6w83UL7LwHTivKkZwkt31wcY3rQ@mail.gmail.com>
Date: Mon, 7 May 2012 12:46:35 +0200
Message-ID: <CACWXZj1OXyXNkohTxe=TY0S=kPq9Of6opqiYisihoCQ1faxv1A@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: ah@tr-sys.de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: salud@ietf.org
Subject: Re: [salud] draft-ietf-salud-alert-info-urns-06 : <private-name> issues
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 07 May 2012 10:53:10 -0000

Alfred,

Thank you for the very elaborate comments and for the recommendation
on how to solve the problems. We will come back to you with proposals
for the new text and, in cases where we need more guidance from you,
with additional questions.

Thanks a lot
Laura


2012/5/4 Laura Liess <laura.liess.dt@googlemail.com>:
> Hi,
>
> I forwarded Alfred's comments, as his original message to salud is
> still stuck in the moderation queue.
>
> Kind regards
> Laura
>
>
> ---------- Forwarded message ----------
> From: Alfred H=CEnes <ah@tr-sys.de>
> Date: 2012/5/4
> Subject: draft-ietf-salud-alert-info-urns-06 : <private-name> issues
> To: draft-ietf-salud-alert-info-urns@tools.ietf.org
> Cc: salud@ietf.org
>
>
> I've been asked to review draft-ietf-salud-alert-info-urns from
> a URN perspective. =A0To keep the message size shorter, I split my
> comments into parts by the major concerns I have with the I-D.
>
> My primary concerns regarding the chosen namespace are still
> in off-list exploration stage, and so I start in this message with
> the second topical area I found needing work: Alert URNs with
> <private-name> components and registration requirements.
>
>
> For easy reference, I quote the ABNF in Section 4 of the I-D:
>
> | =A0 =A0 =A0 =A0 =A0alert-URN =A0 =A0 =A0 =3D "urn:alert:" alert-identif=
ier
> | =A0 =A0 =A0 =A0 =A0alert-identifier=3D alert-category ":" alert-indicat=
ion
> | =A0 =A0 =A0 =A0 =A0alert-category =A0=3D name
> | =A0 =A0 =A0 =A0 =A0alert-indication=3D name *(":" name)
> | =A0 =A0 =A0 =A0 =A0name =3D standard-name / private-name
> | =A0 =A0 =A0 =A0 =A0standard-name =3D label
> | =A0 =A0 =A0 =A0 =A0private-name =3D label "." label *[ "." label ]
> | =A0 =A0 =A0 =A0 =A0label =3D let-dig [ *let-dig-hyp let-dig ]
> | =A0 =A0 =A0 =A0 =A0let-dig-hyp =A0 =A0 =3D let-dig / "-"
> | =A0 =A0 =A0 =A0 =A0let-dig =A0 =A0 =A0 =A0 =3D ALPHA / DIGIT
> | =A0 =A0 =A0 =A0 =A0ALPHA =A0 =A0 =A0 =A0 =A0 =3D %x41-5A / %x61-7A =A0 =
; A-Z / a-z
> | =A0 =A0 =A0 =A0 =A0DIGIT =A0 =A0 =A0 =A0 =A0 =3D %x30-39 ; 0-9
> |
> | =A0 =A0 Throughout this document, "<private-name>" is used as a syntact=
ic
> | =A0 =A0 variable for any string conformant to the "private-name" ABNF
> | =A0 =A0 above.
>
> Editorial note:
> =A0The ABNF Standard, RFC 5234, actually *recommends* to enclose
> =A0ABNF rule names in angle brackets ("<...>") when used in prose text.
> =A0So the trailing clause is very redundant -- it carries some allusion
> =A0of doing something extraordinary while actually the recommended
> =A0style is bening used.
> =A0This visual markup is even more important in cases where rule names
> =A0are words in common use, with a broader meanng.
> =A0So I strongly recommend making use of these provisions in RFC 5234
> =A0and in particular also use "<name>" and "<label>" throughout the
> =A0draft text.
>
> The semantical restrictions on <private-name> are spelled out later
> in Section 4 ...
>
> | =A0 =A0 The alert-indications are hierarchical identifiers. =A0The set =
of
> | =A0 =A0 allowable characters is the same as that for domain names
> | =A0 =A0 [RFC1123]. =A0Labels are case-insensitive. =A0Comparisons MUST =
be
> | =A0 =A0 case-insensitive. =A0Registered URNs SHOULD be transmitted as
> | =A0 =A0 registered. =A0A new name MUST NOT be registered if it is equal=
 by
> | =A0 =A0 case-insensitive comparison to an already registered name.
>
> .... and in Section 7.2 of the draft, which says (1st paragraph):
>
> | =A0The <private-name>" syntax is for proprietary extensions specific to
> | =A0independent organizations. =A0The "<private-name>" is used in the fo=
rm
> | =A0of a "reverse FQDN" of the entity that defines the extension,
> | =A0possibly followed by further components. =A0Standard URNs will never
> | =A0contain a ".", so proprietary extensions need no further marker.
> | =A0This gives a way of assigning unique names without the need for a ne=
w
> | =A0registry. =A0The namespace for each alert category is independent.
> | =A0Those assigning new names must ensure they are in a position to
> | =A0assign names uniquely for the FQDN they choose.
>
>
> Concern #1 :
>
> =A0 Defining syntax for domain name labels is a hornets' nest.
> =A0 Each time someone tries to specify precise rules, there is a storm
> =A0 of messages on the IETF main list. =A0Recently, even attempts started
> =A0 in ICANN to update the specification of domain name syntax from
> =A0 STD 13 and STD 3 has failed miserably.
>
> Recommendation:
>
> =A0 Defer for <label> to the IDNAbis RFCs (cite RFC 5890) and use
> =A0 the terms LDH-label and A-label as defined there.
>
> Editorial hint:
> =A0 Formatting the ABNF with columnar alignment of all "=3D" elements
> =A0 would improve the readability. =A0There's enough horizontal space
> =A0 here to do that painlessly.
>
>
> Concern #2 :
>
> =A0 URNs need to be stable and unique, cannot be de-registered,
> =A0 and MUST NOT be re-assigned.
> =A0 Bare (fully qualified) domain names do not have these properties;
> =A0 domain names are only delegated under commercial rules and subject
> =A0 to legal challenges and reassignment. =A0(I have myself once suffered
> =A0 from loss of a domain name, and later gained the reassignment of a
> =A0 domain name registered by a 3rd party that collided with a
> =A0 registered trade mark owned by my company.)
>
> Recommendation:
>
> =A0 Other protocols in similar circumstances have observed that
> =A0 valid fully qualified domain names actually have a precisely
> =A0 defined valid owner at each instant in time, and so escaped to
> =A0 combining domain names for use in a persistent identifier system
> =A0 with a mandatory time stamp. =A0Since domain name ownership changes
> =A0 do not happen frequently and need significant time (due to
> =A0 registration / authority propagation delays and the persistence
> =A0 of cached DNS data until their TTL expires), it suffices to
> =A0 provide such time stamps at date granularity, e.g. with the
> =A0 semantics that the {FQDN,date} combination uniquely identifies
> =A0 the owner of the FQDN at 00:00 UTC of the specified date
>
> =A0 So if you want to retain the basic scheme, but make the assigned
> =A0 identifiers actually suitable for URNs, the reversed domain
> =A0 names should be followed by a date, for example:
> =A0 =A0 =A0 =A0com.example.foo-bar-products.2012-05-03
> =A0 might become a valid <private-name> component for an Alert URN
> =A0 to be registered.
>
>
> Concern #3 :
>
> =A0 The 2nd paragraph of Section 7.2 contains two examples that
> =A0 contradict the specification from the 1st paragraph (quoted above).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vvvv
> | =A0 urn:alert:service:call-waiting:abc.org.example.somecompany =A0and
> | =A0 urn:alert:service:call-waiting:def.org.example.somecompany [...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^
> =A0 The company-specific labels within a <private-name> must not
> =A0 precede the reversed domain name.
>
> Recommendation:
>
> =A0 Such <private-name> components could take the form of a subordinate
> =A0 domain name label:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vvvv
> =A0 =A0urn:alert:service:call-waiting:org.example.somecompany.abc
>
> =A0 or be specified in a subordinate <name>, as already shown in the
> =A0 draft:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0v
> =A0 =A0urn:alert:service:call-waiting:org.example.somecompany:abc
>
>
> Concern #4 :
>
> =A0 The registration rules for <alert-identifier>s, in particular for
> =A0 Alert URNs containing a <private-name> component, are not
> =A0 specified clearly and unambiguously in the draft.
>
> =A0 At various places, the draft uses vague phrases like
> =A0 the last paragraph of Section 7.1:
>
> | =A0The process for defining new Alert-Info URNs is described in
> ! =A0Section 6.1. =A0Adding new categories and adding alert-indication
> ! =A0values other than via the "private" mechanism described in
> =A0 =A0 =A0 =A0 =A0^^^^^^^^^^
> ! =A0Section 7.2 is standards action.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^
>
> =A0 ... and the last paragraph of Section 7.2:
>
> | =A0Adding new categories and adding alert-indication values via the
> | =A0"private" mechanism is not a standards action.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^
>
> =A0 Yet, Section 6.1 also doesn't give the specification needed:
>
> | =A0Alert URN identifiers are identified by labels managed by IANA,
> | =A0according to the processes outlined in [RFC5226] in a new registry
> | =A0called "Alert URN Labels". =A0Thus, creating a new Alert-Info URN
> | =A0identifier requires IANA action. =A0The policy for adding a new aler=
t
> | =A0category is 'Standards Action'. =A0(This document defines the alert
> | =A0categories 'service', 'source', 'priority', 'duration', 'delay' and
> | =A0'locale'. ) The policy for assigning labels to alert-indications and
> ! =A0the rules to combine them may differ for each alert-category and MUS=
T
> ! =A0be defined by the document describing the corresponding alert
> ! =A0category. =A0[...]
>
> =A0 So, fine for <alert-category>s, but not for <alert-indication>s:
> =A0 none of the Sections 6.2.* contains such text.
>
> Recommendation:
>
> =A0 Clearly specify which of the RFC 5226 registration policies shall
> =A0 apply to Alert URNs with <private-name> component (or define a
> =A0 custom IANA policy if you really feel the need to undergo such
> =A0 pain).
>
> =A0 Keep in mind that the persistence and uniqueness requirements
> =A0 for URNs need to be satisfied, so maybe "Specification Required"
> =A0 might be a candidate policy with minimal requirements.
> =A0 Other possibilities would be "Expert Review" -- which includes
> =A0 "Specification Required" but requires the IESG appointment of
> =A0 designated expert(s) -- or "RFC required".
> =A0 But in the former case, when the registration document is not
> =A0 readily available at a permanent, stable URI, you would need to
> =A0 require IANA to archive the registration document and link to that
> =A0 'escrow' copy from the publicly available Alert URN registry on
> =A0 the IANA web/ftp site -- but beware that past experience has shown
> =A0 that IANA did not like such escrow requirements very much.
>
> =A0 Either add _common_ text to section 6.1 that specifies the IANA
> =A0 policy for <alert-indication> assignment in all <alert-category>s
> =A0 specified in the draft, or actually do add such text to each
> =A0 Section 6.2.*, as promised in the current text of Section 6.1.
>
>
> Concern #5 :
>
> =A0 The rules in Section 8.1 are not properly thought out, especially
> =A0 for the case of <private-name> components.
>
> =A0 In particular, the draft specifies:
>
> ! =A0The implementation is free to ignore any or all parts of the receive=
d
> ! =A0Alert-Info URNs. =A0The exact way in which a UA renders a received
> | =A0combination of Alert-Info URNs is left as an implementation issue.
> | =A0However, the implementation MUST comply to following rules:
> |
> | =A0 =A0 a. =A0Each alert-info URN has precedence over all URNs that fol=
low
> | =A0 =A0 it, and its interpretation is subordinate to all URNs that prec=
ede
> | =A0 =A0 it.
> |
> | =A0 =A0 b. =A0If the UA cannot implement the effect of a URN (because i=
t
> | =A0 =A0 does not recognize the URN or the URN's effect is precluded by
> ! =A0 =A0 preceding URNs), the UA repeatedly removes either
> !
> ! =A0 =A0 =A0 =A0(1) the final name of the URN, or
> !
> ! =A0 =A0 =A0 =A0(2) if the final name is a private-name with three or mo=
re
> ! =A0 =A0 =A0 =A0labels, the final label
>
> =A0 First, I strongly suspect that by removal of a component you
> =A0 also mean removal of the separator character that precedes the
> =A0 component being removed (a colon or period), but the draft does
> =A0 not say so precisely, and the separator characters (by the ABNF)
> =A0 are not part of the components being removed per these rules.
>
> =A0 Second, under the rules presently in the draft, removing a <name>
> =A0 is not guaranteed to lead to a valid (registered) Alert URN:
>
> =A0 o =A0according to the ABNF in Section 4, the <alert-indication>
> =A0 =A0 =A0is not optional, so removal of the last remaining <name> of
> =A0 =A0 =A0an <alert-indication> (and the separator character ":")
> =A0 =A0 =A0would not yield a valid Alert URN;
> =A0 =A0 =A0(btw: the draft provides a "default" <alert-indication> per
> =A0 =A0 =A0<alert-category>, which is to be assumed if no Alert URN for
> =A0 =A0 =A0a particular <alert-category> is indicated, but that's not the
> =A0 =A0 =A0same as an "Alert URN" without an <alert-indication> component=
;)
>
> =A0 o =A0as far as I understand, the draft does not require to register
> =A0 =A0 =A0'truncated' versions of hierarchically subdivided
> =A0 =A0 =A0<alert-indication>s -- for instance, it can be imagined that
> =A0 =A0 =A0for a particular <alert-category>, <alert-indication>s
> =A0 =A0 =A0 =A0 =A0 =A0abc:variant1 ,
> =A0 =A0 =A0 =A0 =A0 =A0abc:variant2 , and
> =A0 =A0 =A0 =A0 =A0 =A0abc:variant3
> =A0 =A0 =A0get registered, but bare
> =A0 =A0 =A0 =A0 =A0 =A0abc
> =A0 =A0 =A0is not registered as a valid <alert-indication>.
>
> =A0 Examples:
> =A0 - =A0s6.2.1 does _not_ define "service:recall" (without an additional
> =A0 =A0 =A0<name> to qualify "service:recall";
> =A0 - =A0s6.2.6 intentionally does _not_ define "locale:country" (without
> =A0 =A0 =A0an additional <name> in the form of an ISO 3166-1 country code=
).
>
> =A0 Similarly, there is no requirement in the draft that partially
> =A0 truncated forms of "private" Alert URNs be registered and valid.
>
> =A0 Third, regarding sub-rule (2) above: browser implementers are
> =A0 struggling with dealing with recognizing "registry type" domains
> =A0 for the purpose of defining sensical scope boundary rules for
> =A0 HTTP state (cookies), but all these efforts are doomed due to the
> =A0 creative forces at work in domain registries.
> =A0 Attaching important semantics to the bare number of domain labels
> =A0 in an FQDN does not make sense. This will become even more critical
> =A0 with ICANN's new sponsored TLD program, where anybody (with enough
> =A0 $$$) can start registering an own TLD and sell sub-domains -- or
> =A0 use the TLD only company-internally. On the other hand, a URN
> =A0 sub-namespace also cannot be made to depend on some volatile list
> =A0 of "registry-like" domains in use on the Internet to distinguish
> =A0 "cut points" beyond which no organizational affiliation can be
> =A0 inferred.
>
> =A0 Further, in the DNS, there can be "empty non-terminals" :
> =A0 similarly as shown above for <alert-indication>s, in the DNS,
> =A0 subordinate domains/zones can be registered without the need to
> =A0 also register/populate "intermediate" domains -- for instance
> =A0 there might be the following, regularly delegated domains:
> =A0 =A0 =A0 jp.pacific.world-company.example.com
> =A0 =A0 =A0 kr.pacific.world-company.example.com
> =A0 =A0 =A0 de.emea.world-company.example.com
> =A0 =A0 =A0 it.emea.world-company.example.com
> =A0 =A0 =A0 il.emea.world-company.example.com
> =A0 =A0 =A0 eg.emea.world-company.example.com
> =A0 without the need to have delegated the domains:
> =A0 =A0 =A0 pacific.world-company.example.com
> =A0 =A0 =A0 emea.world-company.example.com
> =A0 from world-company.example.com -- any domain can contain
> =A0 delegations at any level of subordiante labels they seem fit
> =A0 to need.
> =A0 So by removing the "least significant" domain label, you might
> =A0 arrive at a domain name without an owner, which could not be
> =A0 used to construct a valid Alert URN for registration.
>
> Recommendations:
>
> =A0 In concert with Concern #2 above, rule b.(2) does not make sense
> =A0 any more. =A0I very strongly recommend to drop it entirely.
>
> =A0 The other corner cases explained above need to be considered and
> =A0 properly taken care of in the I-D.
>
> =A0 Given the definition of the Alert URNs in Section 4, specific
> =A0 semantics are only defined for actual, registers Alert URNs,
> =A0 not for arbitrarily truncated Alert URNs. =A0Therefore, I believe
> =A0 that the sentence,
>
> ! =A0The implementation is free to ignore any or all parts of the receive=
d
> ! =A0Alert-Info URNs. =A0[...]
>
> =A0 should perhaps better say:
>
> ! =A0The implementation is free to ignore any or all of the received
> ! =A0Alert-Info URNs. =A0[...]
>
> =A0 If by that revised rule, all Alert URNs for a particular
> =A0 <alert-category> are dropped, according to other parts of the
> =A0 draft, the recipient has to assume the "default" Alert URN for
> =A0 that <alert-category>. =A0From my point of view, that would just
> =A0 be fine and match the requirements. =A0This seems to be confirmed
> =A0 by the additional text above item c. of the draft (not quoted
> =A0 above).
>
> =A0 So it eventually looks like the draft could easily drop the entire
> =A0 component stripping rules in favor of dropping unknown Alert URNs
> =A0 and letting the defaults step in.
>
> =A0 Further, the text in Section 9 seems to indicate that the actual
> =A0 intent is to always have a default for each 'dimension' (i.e.
> =A0 category) of alert information. =A0If that's correct, it would
> =A0 IMHO be wise to request (in s6.1) that any new registration of an
> =A0 <alert-category> also specifies at least one <alert-information>
> =A0 to be used with that category and designates one of these as the
> =A0 default for that category.
>
>
> Finally, a few editorial nits:
>
> * =A0Please clean up dangling hyphens (with spurious space), e.g.:
> =A0 "Alert -Info URNs" , "call- waiting:"
> =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^
>
> * =A0Please fix various typos (some of these recurring):
> =A0 - =A0s/adidition/addition/
> =A0 - =A0s/calback/callback/g
> =A0 - =A0s/rinback/ringback/g
> =A0 (and maybe you better use "ring/ringback" without a single
> =A0 space on one side of the slash character)
>
> * =A0In the table in s6.2.3, the 3rd table column is partially
> =A0 misaligned by one character position for the 1st table entry row.
>
> * =A0In s9, I doubt that "requirements in section 7" is the proper
> =A0 pointer -- did you mean "... in section 2" ?
>
> * =A0In s 1.3, 1st para, s8.1, 3rd para, and s9.1, 5th para,
> =A0 please use the precise terminology (as anywhere else in the memo):
> =A0 =A0 =A0 s/Alert-Info header/Alert-Info header field/
> =A0 Similarly, in the last line of item c. in s8.1, pleas adjust:
> =A0 =A0 =A0 s/header "Priority: urgent"/header field "Priority: urgent"/
>
> * =A0In s9.2.2, in one instance white space is missing after a dash:
> =A0 =A0 =A0 s/-internal high/- internal high/
>
> * =A0As a matter of taste: IMO the readability would be improved
> =A0 if in Section 9.2.* the presentation were a bit more compact,
> =A0 with less vertical white space.
> =A0 For instance, you might consider dropping the single blank line
> =A0 that precedes all item lines starting with "- "
> =A0 (using the =A0<?rfc subcompact=3D"yes"?> =A0PI and, where needed,
> =A0 <vspace blankLines=3D'1' /> in xml2rfc).
> =A0 Ex.:
>
> | =A0Signal 4
> |
> | =A0 =A0 Meaning: low
> |
> | =A0 =A0 Locations:
> ! =A0 =A0 - source
> ! =A0 =A0 - priority:low
>
>
>
> Kind regards,
> =A0Alfred H=CEnes.
>
> --
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes =A0 | =A0Alfred Hoenes =A0 Dipl.-Math., Dipl.-Phys=
. =A0|
> | Gerlinger Strasse 12 =A0 | =A0Phone: (+49)7156/9635-0, Fax: -18 =A0 =A0=
 =A0 =A0 |
> | D-71254 =A0Ditzingen =A0 =A0 | =A0E-Mail: =A0ah@TR-Sys.de =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> +------------------------+--------------------------------------------+

From dworley@avaya.com  Mon May  7 20:10:58 2012
Return-Path: <dworley@avaya.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5BD21F861B for <salud@ietfa.amsl.com>; Mon,  7 May 2012 20:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.474
X-Spam-Level: 
X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGQLj2mEAzoY for <salud@ietfa.amsl.com>; Mon,  7 May 2012 20:10:52 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2223C21F8616 for <salud@ietf.org>; Mon,  7 May 2012 20:10:49 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPKNqE/GmAcF/2dsb2JhbABEoGCSRYEHggwBAgEDEihRARUIIUIgBwQTCBqHbAuZR4QgnTKQJmMEnBaKKoMFgTwZ
X-IronPort-AV: E=Sophos;i="4.75,547,1330923600";  d="scan'208";a="8034508"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 May 2012 23:10:46 -0400
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 May 2012 23:07:34 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 7 May 2012 23:10:47 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "salud@ietf.org" <salud@ietf.org>
Date: Mon, 7 May 2012 23:10:05 -0400
Thread-Topic: Editorial suggestions for draft-ietf-salud-alert-info-urns-06
Thread-Index: AQHNLMgp7r750PsYGku9iTFj1xXWGA==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0AB5@DC-US1MBEX4.global.avaya.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: [salud] Editorial suggestions for draft-ietf-salud-alert-info-urns-06
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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, 08 May 2012 03:10:58 -0000

Some final editorial suggestions for the -06 draft:

- Abstract

   This document normatively updates [RFC3261], the Session Initiation
   Protocol (SIP).  It changes the usage of the SIP Alert-Info header
   field defined in the [RFC3261] by additionally allowing its use in
   all provisional responses to INVITE (except the 100 response).

This would be helped by changing the period into a colon:

   Protocol (SIP):  It changes the usage of the SIP Alert-Info header

That warns the reader that the second sentence explains exactly how
this document updates 3261.

- 1.1.  Motivation

   only works when the same vendor provides PBX and UA, as only then is

The last word should be "if".

- 4.  Namespace Registration Template

      The alert-indications are hierarchical identifiers.  The set of
      allowable characters is the same as that for domain names
      [RFC1123].  Labels are case-insensitive.  Comparisons MUST be
      case-insensitive.  Registered URNs SHOULD be transmitted as
      registered.  A new name MUST NOT be registered if it is equal by
      case-insensitive comparison to an already registered name.

The sentence "Labels are case-insensitive." is hard to understand
here.  It's completely correct, but the term "label" is only defined
below, in the ABNF.  One fix would be to move this paragraph to below
the ABNF, so the reader would know how "label" fits with the
indications.  But I think a better fix is to change "label" to
"letters".  That gives the same information, and allows us to verbally
describe the URNs before giving the ABNF.

The sentence "Registered URNs SHOULD be transmitted as registered." is
correct but we don't tell the reader that the important aspect is the
case of the letters.  Perhaps we could expand this to "Registered URNs
SHOULD be transmitted in the case that is registered."

   Validation mechanism:  Validation determines whether a given string
      is currently a validly-assigned URN [RFC3406].  Static validation
      is performed based on the currently registered Alert-Info URNs at
      IANA.

It might help to add to this paragraph the sentence
"Privately-assigned extension values can be distinguished by the
presence of a private-name.", as that is an aspect of validation, and
it is not directly stated elsewhere in the registration template.

- 5.2.3.  Alert-Info URN Indication Values for the alert-category
        'priority'

Do we want to add a <urn:alert:priority:emergency> so that the URN
priorities match the Priority values (non-urgent, normal, urgent,
emergency) in RFC 3261?  (If we make this change, section 6.2.3 needs
to be changed also.)

- 6.1.  New alert identifiers

      alert-category/      Reference    Description
      alert-identifier
      ---------------------------------------------------------------
      foo                  RFCxyz       Description of the 'foo'
                                        alert-category
      foo:bar              RFCabc       Description of the 'foo:bar'
                                        alert-identifier

I think the second "Description" should be "Description of the 'bar'
alert-identifier in the 'foo' alert-category" in order to match the
terminology in the ABNF and elsewhere.

- 7.2.  Extensions Rules for Independent Organizations

   The "<private-name>" syntax is for proprietary extensions specific to
   independent organizations.  The "<private-name>" is used in the form
   of a "reverse FQDN" of the entity that defines the extension,
   possibly followed by further components.

The second sentence could be made clearer:

   The "<private-name>" is a "reversed FQDN" of the entity that
   defines the extension, that is, the labels of a fully-qualified
   domain name that is owned by that entity, in reverse order,
   separated by periods.  (The domain name need not be the top domain
   name owned by the entity.)

In the example of the next paragraph, there is a typo in these URNs:

   urn:alert:service:call-waiting:abc.org.example.somecompany and
   urn:alert:service:call-waiting:def.org.example.somecompany (which are

The labels "abc" and "def" are incorrectly placed at the beginning of
the private-names, and should be:

   urn:alert:service:call-waiting:org.example.somecompany.abc and
   urn:alert:service:call-waiting:org.example.somecompany.def (which are

- 8.1.  Priority Rules

      c.  In case that after processing all the received URNs, the UA
      can generate more than one signal that are equally effective at
      expressing the URNs (under the preceding rules), one of those
      signals is selected.  When selecting from the set of equally
      effective signals, no signal should be chosen if a less-specific
      signal is also in the set.  (Specificity is to be judged based on
      the defined meanings of the signals to the user.)  (E.g., if each
      signal is considered to express certain alert-indications of
      certain alert-categories, one signal is less-specific than a
      second signal if the first signal's alert-indications are a subset
      or are prefixes of the second signal's alert-indications.)
      However, a more-specific signal may be chosen if the choice is
      based on information derived from the containing SIP message.
      E.g., a signal implying urn:alert-info:priority:high may be chosen
      if the SIP message contains the header "Priority: urgent".

We should ask the editorial staff if there is a way to split this
paragraph without confusion.  This might be a better way to organize
it:

      c.  In case that after processing all the received URNs, the UA
      can generate more than one signal that are equally effective at
      expressing the URNs (under the preceding rules), one of those
      signals is selected.  When selecting from the set of equally
      effective signals, no signal should be chosen if a less-specific
      signal is also in the set.  However, a more-specific signal may
      be chosen if the choice is based on information derived from the
      containing SIP message.  (E.g., a signal implying
      urn:alert-info:priority:high may be chosen if the SIP message
      contains the header "Priority: urgent".)

      Specificity is to be judged based on the defined meanings of the
      signals to the user.  (E.g., if each signal is considered to
      express certain alert-indications of certain alert-categories,
      one signal is less-specific than a second signal if the first
      signal's alert-indications are a subset or are prefixes of the
      second signal's alert-indications.)

- 9.2.  Examples of how the algorithm works

We should ask the editorial staff if there is a way to present these
many examples with less whitespace, since these 5 examples occupy 8
pages!

- 9.2.1.  Example 1

   Signals at source:internal:

      <urn:alert:source:internal>

   Signals at source:

      <urn:alert:priority:low>

      <urn:alert:priority:high>

   default

It would help to add some explanation of this list, and also,
"default" should be indented:

   Signals at source:internal:  (this is, first place)

      <urn:alert:source:internal>

   Signals at source:  (tied for second place)

      <urn:alert:priority:low>

      <urn:alert:priority:high>

      default

- 9.2.5.  Example 5

   Notice that we've used the "default" signal to cover "normal
   priority".  That is so the signal will cover situations where no
   priority URN is present, as well as the ones with
   <urn:alert:priority:normal>.  So we're deliberately failing to
   distinguish "priority:normal" from the default priority.

I think the last sentence should add:

   So we're deliberately failing to distinguish "priority:normal" from
   the default priority, which is the intention of the definition of
   priority:normal in section 5.2.

- 11.  Proxy Behaviour

This section gives a nice example:

   Following example shows both the network audio resource referenced by
   the HTTP URI and the URN indication for the call-waiting service
   transported by the Alert-Info header field in a 180 Ringing
   provisional response.

   SIP/2.0 180 Ringing
   Alert-Info: <http://www.example.com/sound/moo.wav>,
                <urn:alert:service:call-waiting>
   To: Bob <sip:bob@biloxi.example.com>;tag=3Da6c85cf
   From: Alice <sip:alice@atlanta.example.com>;tag=3D1928301774
   Call-ID: a84b4c76e66710
   Contact: <sip:bob@192.0.2.4>
   CSeq: 314159 INVITE
   Via: SIP/2.0/UDP server10.biloxi.example.com;
               branch=3Dz9hG4bK4b43c2ff8.1
   Content-Length: 0

but I don't think the example goes well in this section.  Perhaps move
it to its own section between sections 6 and 7?

Dale

From krisztian.kiss@nokia.com  Tue May  8 23:36:02 2012
Return-Path: <krisztian.kiss@nokia.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E621F85D2 for <salud@ietfa.amsl.com>; Tue,  8 May 2012 23:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyCfG-rlzsQj for <salud@ietfa.amsl.com>; Tue,  8 May 2012 23:36:01 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0E38A21F85D1 for <salud@ietf.org>; Tue,  8 May 2012 23:35:57 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q496ZnU3019158 for <salud@ietf.org>; Wed, 9 May 2012 09:35:54 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 9 May 2012 09:35:51 +0300
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.88]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Wed, 9 May 2012 08:35:51 +0200
From: <krisztian.kiss@nokia.com>
To: <salud@ietf.org>
Thread-Topic: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday 8 May
Thread-Index: Ac0p1qpFDtuyR/uMToyydo3im3M0qQD1HGog
Date: Wed, 9 May 2012 06:35:50 +0000
Message-ID: <FEDAA55BA0A1734FA74FA21A8B085E0FE1CA83@008-AM1MPN1-051.mgdnok.nokia.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C4435DC9C@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4435DC9C@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [99.92.92.93]
Content-Type: multipart/alternative; boundary="_000_FEDAA55BA0A1734FA74FA21A8B085E0FE1CA83008AM1MPN1051mgdn_"
MIME-Version: 1.0
X-OriginalArrivalTime: 09 May 2012 06:35:52.0045 (UTC) FILETIME=[FA97B1D0:01CD2DAD]
X-Nokia-AV: Clean
Subject: Re: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tuesday 8 May
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 09 May 2012 06:36:02 -0000

--_000_FEDAA55BA0A1734FA74FA21A8B085E0FE1CA83008AM1MPN1051mgdn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I read the -06 version and I also think it's ready to move forward.

One minor editorial in section 6.2.1:

OLD:

   service:recall:calback         RFC XXXX  Recall due to callback
   service:recall:hold            RFC XXXX  Recall due to call hold
   service:recall:transfer        RFC XXXX  Recall due to callback

NEW:

   service:recall:callback        RFC XXXX  Recall due to callback
   service:recall:hold            RFC XXXX  Recall due to call hold
   service:recall:transfer        RFC XXXX  Recall due to transfer


"rinback" -> "ringback" throughout section 6.


Cheers,
Krisztian


From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of e=
xt Christer Holmberg
Sent: Friday, May 04, 2012 02:17
To: salud@ietf.org
Subject: Re: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 ending Tu=
esday 8 May

Hi,

I have read the draft, and I support moving it forward.

Regards,

Christer

> As nobody has indicated that there are any remaining issues regarding
> draft-ietf-salud-alert-info-urns-06, I am calling a working group last
> call, ending Tuesday
> 8 May.
>
> Dale



--_000_FEDAA55BA0A1734FA74FA21A8B085E0FE1CA83008AM1MPN1051mgdn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi,</div>
<div>&nbsp;</div>
<div>I read the -06 version and I also think it&#8217;s ready to move forwa=
rd.</div>
<div>&nbsp;</div>
<div>One minor editorial in section 6.2.1:</div>
<div>&nbsp;</div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
OLD:</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;&nbsp; service:recall:calback&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; RFC XXXX&nbsp; Recall due to callback</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;&nbsp; service:recall:hold&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; RFC XXXX&nbsp; Recall due to call hold</span></font=
></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;&nbsp; service:recall:transfer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; RFC XXXX&nbsp; Recall due to callback</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
NEW:</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;&nbsp; service:recall:cal<font color=3D"red"><span style=3D"backgroun=
d-color:yellow;"><b>l</b></span></font>back&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; RFC XXXX&nbsp; Recall due to callback</span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;&nbsp; service:recall:hold&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; RFC XXXX&nbsp; Recall due to call hold</span></font=
></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;&nbsp; service:recall:transfer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; RFC XXXX&nbsp; Recall due to <font color=3D"red"><span style=3D"backgro=
und-color:yellow;">transfer</span></font></span></font></div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&nbsp;</span></font></div>
<div>&nbsp;</div>
<div><font face=3D"Courier New" size=3D"2"><span style=3D"font-size:10pt;">=
&quot;rinback&quot; -&gt; &quot;ringback&quot; <font face=3D"Calibri" size=
=3D"2"><span style=3D"font-size:11pt;">throughout section 6.</span></font><=
/span></font></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Cheers,<br>

Krisztian</div>
<div><font color=3D"#1F497D">&nbsp;</font></div>
<div><font color=3D"#1F497D">&nbsp;</font></div>
<div><font face=3D"Tahoma" size=3D"2"><span style=3D"font-size:10pt;"><b>Fr=
om:</b> salud-bounces@ietf.org [<a href=3D"mailto:salud-bounces@ietf.org">m=
ailto:salud-bounces@ietf.org</a>] <b>On Behalf Of </b>ext Christer Holmberg=
<br>

<b>Sent:</b> Friday, May 04, 2012 02:17<br>

<b>To:</b> salud@ietf.org<br>

<b>Subject:</b> Re: [salud] WGLC for draft-ietf-salud-alert-info-urns-06 en=
ding Tuesday 8 May</span></font></div>
<div>&nbsp;</div>
<div>Hi,</div>
<div>&nbsp;</div>
<div>I have read the draft, and I support moving it forward.</div>
<div>&nbsp;</div>
<div>Regards,</div>
<div>&nbsp;</div>
<div>Christer</div>
<div>&nbsp;</div>
<div>&gt; As nobody has indicated that there are any remaining issues regar=
ding </div>
<div>&gt; draft-ietf-salud-alert-info-urns-06, I am calling a working group=
 last </div>
<div>&gt; call, ending Tuesday</div>
<div>&gt; 8 May.</div>
<div>&gt;</div>
<div>&gt; Dale</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_FEDAA55BA0A1734FA74FA21A8B085E0FE1CA83008AM1MPN1051mgdn_--

From md3135@att.com  Wed May  9 06:07:51 2012
Return-Path: <md3135@att.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F049B21F858E for <salud@ietfa.amsl.com>; Wed,  9 May 2012 06:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUeT6hsKHUXk for <salud@ietfa.amsl.com>; Wed,  9 May 2012 06:07:51 -0700 (PDT)
Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 2530921F8532 for <salud@ietf.org>; Wed,  9 May 2012 06:07:44 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 02c6aaf4.2aaafec5d940.761537.00-579.2095682.nbfkord-smmo04.seg.att.com (envelope-from <md3135@att.com>);  Wed, 09 May 2012 13:07:44 +0000 (UTC)
X-MXL-Hash: 4faa6c2057719fd0-9f7c6506b5643d4298f3cd7c4121a129d8b39c4c
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 51c6aaf4.0.761477.00-348.2095522.nbfkord-smmo04.seg.att.com (envelope-from <md3135@att.com>);  Wed, 09 May 2012 13:07:33 +0000 (UTC)
X-MXL-Hash: 4faa6c15741825bb-1030a1d3a396d5261cc7d272680b94cc153cdf2d
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q49D7XdI016404; Wed, 9 May 2012 09:07:33 -0400
Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q49D7PJU016350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2012 09:07:26 -0400
Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint02.pst.cso.att.com (RSA Interceptor); Wed, 9 May 2012 09:07:04 -0400
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Wed, 9 May 2012 09:07:03 -0400
From: "DOLLY, MARTIN C" <md3135@att.com>
To: "salud@ietf.org" <salud@ietf.org>
Thread-Topic: WGLC comments
Thread-Index: Ac0t5JXiM9ZSrH1/Rbip9GqQhtvEzg==
Date: Wed, 9 May 2012 13:07:02 +0000
Message-ID: <E42CCDDA6722744CB241677169E83656C14461@MISOUT7MSGUSR9I.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.175.85.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <md3135@att.com>
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=1.0 c=1 a=KQj4zOcPdCkA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo]
X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=zQ]
X-AnalysisOut: [P7CpKOAAAA:8 a=VtUFBVA5wDuxlpD7VegA:9 a=UzGpsNeraC5-5Xelcb]
X-AnalysisOut: [IA:7 a=CjuIK1q_8ugA:10 a=qM39cor4HRgA:10 a=Hz7IrDYlS0cA:10]
Subject: [salud] WGLC comments
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 09 May 2012 13:07:52 -0000

Laura
All,

I reviewed the draft and think it is ready to move forward.
A couple comments/questions:
1.      REQ-10, "uncommon" is misspelled;
2.      I do not understand the use case for the following requirement, is =
this in Section 8.2? (add reference)
   REQ-21: The mechanism must provide a simple way to combine two
   alerting indications to produce an alerting indication that requests
   a combination of the intentions of the two alerting indications,
   where any contradictions or conflicts between the two alerting
   indications are resolved in favor of the intention of the first
   alerting indication.

3.      Why is the following not a MUST?, "Registered URNs SHOULD be transm=
itted as
      registered."

4.      RFC is need to make extensions, right? Adding new categories and ad=
ding alert-indication
   values other than via the "private" mechanism described in
   Section 7.2 is standards action.

Regards,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
md3135@att.com<mailto:md3135@att.com>
+1-609-903-3360




From dworley@avaya.com  Wed May  9 14:02:10 2012
Return-Path: <dworley@avaya.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0321F847A for <salud@ietfa.amsl.com>; Wed,  9 May 2012 14:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.295
X-Spam-Level: 
X-Spam-Status: No, score=-103.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFwrqilGwy1S for <salud@ietfa.amsl.com>; Wed,  9 May 2012 14:02:10 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 16CBA21F8472 for <salud@ietf.org>; Wed,  9 May 2012 14:02:09 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAKjaqk+HCzI1/2dsb2JhbABEsz+BB4IMAQEBAQIBEigxDgULAgEIDQghEDIlAQEEAQ0FCBqHZwWeVp0YkFJjBJwViimDBQ
X-IronPort-AV: E=Sophos;i="4.75,559,1330923600"; d="scan'208";a="305689180"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 May 2012 17:01:14 -0400
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 May 2012 16:44:16 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 9 May 2012 17:01:32 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "DOLLY, MARTIN C" <md3135@att.com>, "salud@ietf.org" <salud@ietf.org>
Date: Wed, 9 May 2012 17:01:31 -0400
Thread-Topic: WGLC comments
Thread-Index: Ac0t5JXiM9ZSrH1/Rbip9GqQhtvEzgAQKQZ2
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0AC7@DC-US1MBEX4.global.avaya.com>
References: <E42CCDDA6722744CB241677169E83656C14461@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <E42CCDDA6722744CB241677169E83656C14461@MISOUT7MSGUSR9I.ITServices.sbc.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: Re: [salud] WGLC comments
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 09 May 2012 21:02:11 -0000

[as individual]

> From: DOLLY, MARTIN C [md3135@att.com]
>=20
> 2.      I do not understand the use case for the following
>    requirement, is this in Section 8.2? (add reference)
>=20
>    REQ-21: The mechanism must provide a simple way to combine two
>    alerting indications to produce an alerting indication that requests
>    a combination of the intentions of the two alerting indications,
>    where any contradictions or conflicts between the two alerting
>    indications are resolved in favor of the intention of the first
>    alerting indication.

The idea is that if an INVITE is passing through a middlebox, the
middle box needs a way to modify the ring tone specification in known
ways without having to understand the incoming ring tone specification
in detail.

One example is if the middlebox wants to mandate that the ring tone
include the "external source" indication if at all possible.  In the
current draft, this is done by placing <urn:alert:source:external>
*before* the current Alert-Info arguments.  The processing is defined
that this means that the UAS must indicate "source:external" if
at all possible.

An alternative is if the middlebox wants to *suggest* that the ring
tone include the "external source" indication.  In the current draft,
this is done by placing <urn:alert:source:external> *after* the
current Alert-Info arguments.  The processing is defined that this
means that the UAS must indicate "source:external" if that is
possible, given the previous URNs and the capabilities of the UAS.

> 3.      Why is the following not a MUST?, "Registered URNs SHOULD be
>       transmitted as registered."

Given that comparisons MUST be case-insensitive, it seems overly
strong to use "MUST" here.

> 4.      RFC is need to make extensions, right? Adding new categories
>    and adding alert-indication
>    values other than via the "private" mechanism described in
>    Section 7.2 is standards action.

Yes, that's what the last paragraph of 7.1 and the first paragraph of
6.1 say.

At one point I favored that adding a new alert-category should be a
standards action, adding a new alert-identifier should be by expert
review, and adding a third-level identifier should be even more
relaxed.  But it's not clear that there are any use cases for more
relaxed extension rules.

Dale

From dworley@avaya.com  Wed May  9 14:43:36 2012
Return-Path: <dworley@avaya.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EBC21F848B for <salud@ietfa.amsl.com>; Wed,  9 May 2012 14:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.302
X-Spam-Level: 
X-Spam-Status: No, score=-103.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ6igxu7dhON for <salud@ietfa.amsl.com>; Wed,  9 May 2012 14:43:36 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1585021F8483 for <salud@ietf.org>; Wed,  9 May 2012 14:43:35 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANrjqk/GmAcF/2dsb2JhbAA+BrM+gQeCDAEBAQECARIoMQMQCwIBCA0EBAEBHxAyGwEBAwIDAQEEEwgah2cFnkSdGIsMJ4UfYwScFYopgwU
X-IronPort-AV: E=Sophos;i="4.75,559,1330923600"; d="scan'208";a="346672872"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 May 2012 17:42:17 -0400
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 May 2012 17:42:19 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 9 May 2012 17:43:34 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "salud@ietf.org" <salud@ietf.org>
Date: Wed, 9 May 2012 17:42:44 -0400
Thread-Topic: missing "replaces" metadata / Alert-Info URNs
Thread-Index: Ac0j47zvrokj/aDcQV6vcknX3emgBgKRYNkmAADaxsg=
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0ACD@DC-US1MBEX4.global.avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B22726A0A81@DC-US1MBEX4.global.avaya.com> from "Worley, Dale R" at Apr "26," 2012 "02:27:39" pm, <201204261933.VAA20805@TR-Sys.de>, <CD5674C3CD99574EBA7432465FC13C1B22726A0ACA@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0ACA@DC-US1MBEX4.global.avaya.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: [salud] FW: missing "replaces" metadata / Alert-Info URNs
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 09 May 2012 21:43:36 -0000

I forgot to send this to the Salud mailing list!

Dale

________________________________________
From: Worley, Dale R (Dale) [dworley@avaya.com]
Sent: Wednesday, May 09, 2012 5:18 PM
To: ah@TR-Sys.de
Cc: draft-ietf-salud-alert-info-urns@tools.ietf.org
Subject: RE: missing "replaces" metadata / Alert-Info URNs

[as chair]

> From: ah@TR-Sys.de [ah@TR-Sys.de]
>
> OTOH ... Since you want to register a URN Namespace, you'll have
> to undergo the expert review process (using the urn-nid list),
> as per RFC 3406 (and the rfc3406bis draft doesn't change that)
> before you can forward your draft to the IESG, and quickly browsing
> the urn-nid archives, I did not find evidence that this has been
> done so far.
>
> The usual timeline for WG documents [...]

We will see how we can make it work.  At first reading, RFC 3406
suggests that the request for review and NID assignment is made *by*
the publishing of an RFC.  But that seems inefficient...

> So maybe you will like to hurry up to present your I-D to the
> urn-nid@ietf.org (attach the template from the draft and give
> a pointer to the I-D).

It's clear that we need to make some improvements in the Namespace
Registration Template.  There are complex and conflicting requirements
that the Alert-Info URNs must satisfy, and these result in some of the
more unusual features of the proposed URN scheme.  We need to ensure
that these requirements are explained in a way that is clear to people
who have not been immersed in the problem for the past two years!

Dale