Re: [Ltru] rechartering to handle 639-6

"Doug Ewell" <doug@ewellic.org> Thu, 16 July 2009 04:08 UTC

Return-Path: <doug@ewellic.org>
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 44C673A6983 for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 21:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level:
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, STOX_REPLY_TYPE=0.001]
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 B8GZ4fc1g8fv for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 21:08:40 -0700 (PDT)
Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 6F1163A6BB0 for <ltru@ietf.org>; Wed, 15 Jul 2009 21:08:40 -0700 (PDT)
Received: (qmail 20012 invoked from network); 16 Jul 2009 04:00:30 -0000
Received: from unknown (67.166.27.148) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 16 Jul 2009 04:00:30 -0000
Message-ID: <2C301BED90C8444795F972900C5C6E24@DGBP7M81>
From: "Doug Ewell" <doug@ewellic.org>
To: "LTRU Working Group" <ltru@ietf.org>
References: <mailman.14390.1247692636.4936.ltru@ietf.org>
Date: Wed, 15 Jul 2009 22:00:28 -0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [Ltru] rechartering to handle 639-6
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: Thu, 16 Jul 2009 04:08:42 -0000

Mark Davis ? <mark at macchiato dot com> wrote:

> Most of the rest are associated with geographic designations. Rather 
> than have a hit&miss approach to those that seem important to the 
> designers of 639-6, we'd be better off having some variant convention 
> like the following.
>
>  - unlXXXXX is a UN/LOCODE minus the country designator (see for this
>  case, http://www.unece.org/cefact/locode/gb.htm)
>  - isoXXXXX is an ISO 3166-2 code (as regularized and stabilized by
>  CLDR). See for this case, http://en.wikipedia.org/wiki/ISO_3166-2:GB,
>
> So toss out all those that could be expressed in this way (using case 
> just to make the derivation clear):
>
> en-GB-unlHMA for Helmsdale
> en-GB-unlNCS for Newcastle
> en-GB-isoSCT for Scots
> en-GB-isoZET for Shetlandic
> ...

There's nothing wrong with suggesting alternatives to ISO 639-6, but 
let's steer clear of the completely unworkable ones.

UN/LOCODE makes no promises of stability, and has not been updated for 
16 months (the "2007" version having been released in March 2008). 
UN/LOCODE has also declined to respond when informed of duplicates or 
errors in their coding or in their data files (i.e. the "plain ASCII" 
file contains garbage for some entries, perhaps owing to their stated 
belief that CP437 is "the standard United States character set" and that 
it "conforms to [ISO 8859-1 and ISO 10646]").  I seriously question 
whether this standard is being active maintained.

ISO 3166-2 is well known to have two major flaws for our purposes: any 
or all of the code elements for a given country can be, and have been, 
changed completely at any time, and some of them have restrictions 
against free availability.  I understand that the core standards 
themselves do not have to be freely available, but the code lists must 
be.

Any proposal to assign variants on a systematic, formulaic basis -- not 
three or four, but dozens or hundreds or thousands -- ought to make us 
stop and wonder why we don't establish an extension for the purpose 
instead:

* not en-GB-unlHMA, but en-GB-u-HMA
* not en-GB-isoSCT, but en-GB-i-SCT
* not en-GB-6grdi, but en-GB-6-grdi

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ