Re: [dispatch] New version for the Alert-Info URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt

<L.Liess@telekom.de> Fri, 06 November 2009 15:59 UTC

Return-Path: <L.Liess@telekom.de>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FECA3A6359 for <dispatch@core3.amsl.com>; Fri, 6 Nov 2009 07:59:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level:
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epT0Q4CJ4Zwy for <dispatch@core3.amsl.com>; Fri, 6 Nov 2009 07:59:20 -0800 (PST)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id F39AB3A68C5 for <dispatch@ietf.org>; Fri, 6 Nov 2009 07:59:19 -0800 (PST)
Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 06 Nov 2009 16:59:34 +0100
Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 16:59:33 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5EFA.21D94F5D"
Date: Fri, 06 Nov 2009 16:59:28 +0100
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00397C872@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <4AF36E29.8050108@nostrum.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] New version for the Alert-Info URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt
Thread-Index: Acpe66782QP3qwByRP+mu/xkzATangADlI1Q
References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4AF36E29.8050108@nostrum.com>
From: L.Liess@telekom.de
To: adam@nostrum.com
X-OriginalArrivalTime: 06 Nov 2009 15:59:33.0978 (UTC) FILETIME=[220FDBA0:01CA5EFA]
Cc: anwars@avaya.com, dispatch@ietf.org, R.Jesske@telekom.de
Subject: Re: [dispatch] New version for the Alert-Info URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2009 15:59:21 -0000

It's a good proposal. I fully agree. 
 
Laura




________________________________

	From: dispatch-bounces@ietf.org
[mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach
	Sent: Friday, November 06, 2009 1:31 AM
	To: Liess, Laura
	Cc: anwars@avaya.com; dispatch@ietf.org; Jesske, Roland
	Subject: Re: [dispatch] New version for the Alert-Info
URNsdraft: draft-liess-dispatch-alert-info-urns-00.txt
	
	
	On 10/19/09 9:38 PM, L.Liess@telekom.de wrote: 

		   - Alert-Info URNs Indications for country-specific
tones
		  


	While I think this is a good dimension to have, I question the
wisdom of replicating the entire ISO 3166-1 registry in an RFC and into
IANA, for a variety of reasons:
	
	

	1.	The initial registered list -- the one in the RFC --
will rapidly become out of date.
		
		
	2.	The IANA registry will require constant updating to
match the changes in ISO 3166-1. This either requires the IANA to keep
up with changes in that registry (which is a task well beyond what we
require of them at the moment) or it requires someone to send notes to
IANA to update the registry whenever a change is made. We don't really
have the structure necessary to ensure that someone will do that.
		
		
	3.	If IANA and ISO 3166-1 do become out of sync -- which
would almost necessarily happen from time to time -- you'll end up with
implementations selecting at random between them (which is not a recipe
for interoperability).
		
		
	4.	The selection of country codes is highly political and
rife with land mines -- some are forseeable (e.g. tw, fk), while others
aren't necessarily. You can try to side-step this -- like ICANN tries --
by claiming that we don't take codes outside of ISO 3166-1, and that we
must accept all codes in ISO 3166-1; however, that hasn't kept them out
of occasional hot water. 


	I would strongly suggest simply citing ISO 3166-1, not putting
any values in the IANA registry, and simply giving a couple of
representative (and politically uncontroversial) examples.
	
	/a