Re: [Ltru] ISO 639-6 (was: Geocoordinates)

Peter Constable <petercon@microsoft.com> Wed, 11 March 2009 15:06 UTC

Return-Path: <petercon@microsoft.com>
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 EF1EF3A6877 for <ltru@core3.amsl.com>; Wed, 11 Mar 2009 08:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.099
X-Spam-Level:
X-Spam-Status: No, score=-12.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8]
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 o80GeVqj8IVA for <ltru@core3.amsl.com>; Wed, 11 Mar 2009 08:06:42 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 271F13A6B23 for <ltru@ietf.org>; Wed, 11 Mar 2009 08:06:42 -0700 (PDT)
Received: from tk5-expfs-c106.redmond.corp.microsoft.com (157.54.69.40) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 11 Mar 2009 08:07:18 -0700
Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.46]) by tk5-expfs-c106.redmond.corp.microsoft.com ([157.54.69.40]) with mapi; Wed, 11 Mar 2009 08:07:18 -0700
From: Peter Constable <petercon@microsoft.com>
To: Doug Ewell <doug@ewellic.org>, LTRU Working Group <ltru@ietf.org>
Date: Wed, 11 Mar 2009 08:07:16 -0700
Thread-Topic: [Ltru] ISO 639-6 (was: Geocoordinates)
Thread-Index: Acmh/0eU89V3xSoXTAeJ+iYXIZJ2iwAWnBzg
Message-ID: <DDB6DE6E9D27DD478AE6D1BBBB83579566E654C907@NA-EXMSG-C117.redmond.corp.microsoft.com>
References: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81>
In-Reply-To: <3FF1C2BC1E164A1D99E5BA5B6CA09C46@DGBP7M81>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Ltru] ISO 639-6 (was: Geocoordinates)
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/mail-archive/web/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>
X-List-Received-Date: Wed, 11 Mar 2009 15:06:43 -0000

From: ltru-bounces@ietf.org [mailto:ltru-bounces@ietf.org] On Behalf Of Doug Ewell

> *If* we are to support these code elements, I think this is the right 
> place to do so.  The 4-letter language subtag was reserved in BCP 47 for 
> exactly this purpose, and if anyone, such as (ahem) Peter, sees a 
> conflict with this due to their "derivative use of the language tag 
> syntax," I'm sorry to say it, but that is a problem of their own making.

Just because we reserved something for some future possibility -- a decision taken without any consideration whatsoever of the merits of that possibility -- that doesn't mean that that possibility does have merits. For my part, I have always doubted the merits. On that basis, and assuming that nothing was likely to come of that possibility, I chose to pursue a derivative use in a particular application context. If it turns out that a future version of BCP47 does make use of those currently-reserved alpha-4 subtags, then indeed the problem will be mine (and I'm sure I'll survive). But I can tell you up front that I will most likely push back on a revision to make use of the reserved alpha-4 subtags not only because it's inconvenient for my derivative application but also because I remain very skeptical that there will be benefits (let alone ROI, considering the costs).



> I continue to be strongly opposed to adding hundreds or even thousands 
> of variant subtags, using the same mechanism we currently use to 
> register variants one by one.

Do you mean, "opposed to adding ... thousands of variant subtags _in mass_, and prefer to continue ... register[ing] variants one by one"?

If so, I agree.



Peter