Re: [Ltru] Last open item
"Phillips, Addison" <addison@amazon.com> Tue, 15 April 2008 18:00 UTC
Return-Path: <ltru-bounces@ietf.org>
X-Original-To: ltru-archive@megatron.ietf.org
Delivered-To: ietfarch-ltru-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71BF3A6F13; Tue, 15 Apr 2008 11:00:39 -0700 (PDT)
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179A53A6F13 for <ltru@core3.amsl.com>; Tue, 15 Apr 2008 11:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.392
X-Spam-Level:
X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Jr2nzfitTUM5 for <ltru@core3.amsl.com>; Tue, 15 Apr 2008 11:00:37 -0700 (PDT)
Received: from smtp-fw-0102.amazon.com (smtp-fw-0102.amazon.com [207.171.190.55]) by core3.amsl.com (Postfix) with ESMTP id 1C8983A6C60 for <ltru@ietf.org>; Tue, 15 Apr 2008 11:00:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,661,1199664000"; d="scan'208";a="299131854"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25]) by smtp-border-fw-out-0102.sea3.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2008 18:01:10 +0000
Received: from ex-hub-4103.ant.amazon.com (ex-hub-4103.sea5.amazon.com [10.248.163.24]) by smtp-in-1104.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id m3FI18gD005152 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 15 Apr 2008 18:01:09 GMT
Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.27]) by ex-hub-4103.ant.amazon.com ([10.248.163.24]) with mapi; Tue, 15 Apr 2008 11:01:05 -0700
From: "Phillips, Addison" <addison@amazon.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>, LTRU Working Group <ltru@ietf.org>
Date: Tue, 15 Apr 2008 11:01:04 -0700
Thread-Topic: [Ltru] Last open item
Thread-Index: AcifIdLPGiA5ORhAQWOsGb8tomlhmwAAKHkg
Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA011FFFE9C2@EX-SEA5-D.ant.amazon.com>
References: <30b660a20804101252p37e22884g6dfbec6dd17e5ea1@mail.gmail.com> <006101c89daa$323fc3e0$6801a8c0@oemcomputer> <30b660a20804140815w5d56933auefbdccdcbdfe034b@mail.gmail.com> <001e01c89e4b$897c0000$6801a8c0@oemcomputer> <20080414193212.GI28132@mercury.ccil.org> <002601c89e94$80c98ce0$6801a8c0@oemcomputer> <20080415021154.GK19045@mercury.ccil.org> <001001c89ea2$29a61560$6801a8c0@oemcomputer> <20080415170448.GJ28132@mercury.ccil.org> <002601c89f17$aff089a0$6801a8c0@oemcomputer>
In-Reply-To: <002601c89f17$aff089a0$6801a8c0@oemcomputer>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Ltru] Last open item
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org
"Canonical" != "valid" We are not proposing to ever make a tag invalid. We are proposing to allow the canonical form of the tag to change reflecting changes in the world. There is even a warning in 4647 about being overly aggressive in canonicalizing tags. Addison Addison Phillips Globalization Architect -- Lab126 (Amazon) Chair -- W3C Internationalization Core WG Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of > Randy Presuhn > Sent: mardi 15 avril 2008 09:42 > To: LTRU Working Group > Subject: Re: [Ltru] Last open item > > Hi - > > As a technical contributor... > > > From: "John Cowan" <cowan@ccil.org> > > To: "Randy Presuhn" <randy_presuhn@mindspring.com> > > Cc: "LTRU Working Group" <ltru@ietf.org> > > Sent: Tuesday, April 15, 2008 11:04 AM > > Subject: Re: [Ltru] Last open item > ... > > Stability in the preferred value isn't the sort of stability that we > > can either expect or preserve, particularly in ISO 3166 code elements. > > What we can and do stabilize is the meaning of subtags: if a source > > standard attempts to assign a code element to a different meaning > than > > it once had, we provide a replacement subtag instead of reusing that > > code element. > > > > Countries will go on changing their names, and 3166/MA (in accordance > > with its mandate) will change their codes accordingly; > > Strongly agree, but.... > > > in order not to > > get out of sync with the rest of the code-using world, we need to > track > > those changes insofar as possible. > ... > > Strongly disagree. > > One of the motivations for the formation of this working group was to > provide > a way to insulate language tags from what was perceived as excessive > instability > in some of the code sources. As I see it, stability, particularly the > stability of > the canonical form of a language tag, is dramatically more important > than > staying in sync with other uses of codes coming from the standards we > used > to initially populate our registry. After all, if we're just going to > blindly track > the ISO code du jour for every little piece of dirt, there's really > little point > to even bothering to put these things in our registry. If consistency > with > other uses of those source specifications trumps stability as a > consideration, > then we should throw out our current procedures and registry, just say > "see > ISO registry mumble for these codes", and limit our registry and > procedures > exclusively to codes for things that ISO hasn't coded. > > Otherwise, we will find ourselves in the situation that a tag found to > be OK > be a validating processor will suddenly become not OK. That's simply > not acceptable. > > Randy > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www.ietf.org/mailman/listinfo/ltru
- [Ltru] Last open item Mark Davis
- Re: [Ltru] Last open item Mark Davis
- Re: [Ltru] Last open item Martin Duerst
- Re: [Ltru] Last open item John Cowan
- Re: [Ltru] Last open item Doug Ewell
- Re: [Ltru] Last open item Doug Ewell
- Re: [Ltru] Last open item Randy Presuhn
- Re: [Ltru] Last open item Mark Davis
- Re: [Ltru] Last open item John Cowan
- Re: [Ltru] Last open item Randy Presuhn
- Re: [Ltru] Last open item John Cowan
- Re: [Ltru] Last open item Randy Presuhn
- Re: [Ltru] Last open item John Cowan
- Re: [Ltru] Last open item Doug Ewell
- Re: [Ltru] Last open item Randy Presuhn
- Re: [Ltru] Last open item Phillips, Addison
- Re: [Ltru] Last open item John Cowan
- Re: [Ltru] Last open item John Cowan
- Re: [Ltru] Last open item Randy Presuhn
- Re: [Ltru] Last open item Mark Davis
- Re: [Ltru] Last open item Phillips, Addison
- Re: [Ltru] Last open item Randy Presuhn
- Re: [Ltru] Last open item John Cowan
- Re: [Ltru] Last open item Stephane Bortzmeyer
- Re: [Ltru] Last open item Peter Constable
- Re: [Ltru] Last open item Randy Presuhn
- Re: [Ltru] Last open item Phillips, Addison