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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 06 November 2009 14:59 UTC

Return-Path: <pkyzivat@cisco.com>
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 24E903A68EF for <dispatch@core3.amsl.com>; Fri, 6 Nov 2009 06:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Level:
X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 gU8aFOVnG0UF for <dispatch@core3.amsl.com>; Fri, 6 Nov 2009 06:59:47 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 523933A68F2 for <dispatch@ietf.org>; Fri, 6 Nov 2009 06:59:39 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAILI80qrR7Ht/2dsb2JhbADFZJd9hD0E
X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208";a="221936089"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2009 15:00:03 +0000
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6F00M1003404; Fri, 6 Nov 2009 15:00:02 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 10:00:02 -0500
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 10:00:01 -0500
Message-ID: <4AF439F2.1050305@cisco.com>
Date: Fri, 06 Nov 2009 10:00:02 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
References: <40FB0FFB97588246A1BEFB05759DC8A0038854EC@S4DE9JSAANI.ost.t-com.de> <4AF36E29.8050108@nostrum.com>
In-Reply-To: <4AF36E29.8050108@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2009 15:00:01.0791 (UTC) FILETIME=[D0DF60F0:01CA5EF1]
Cc: anwars@avaya.com, dispatch@ietf.org, R.Jesske@telekom.de, L.Liess@telekom.de
Subject: Re: [dispatch] New version for the Alert-Info URNs draft: 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 14:59:48 -0000

I agree. It would be even better is there were already an URN 
designating country code. Then it could simply be referenced.
But there doesn't seem to be one right now.

Perhaps this doc could define one, and cite ISO 3166-1 for the 
definition of the values it can contain. It could then be used anywhere 
one wants to reference a country by URN, not just in Alert-Info.

	Thanks,
	Paul

Adam Roach wrote:
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch