Re: [Ltru] rechartering to handle 639-6

Mark Davis ⌛ <mark@macchiato.com> Thu, 16 July 2009 04:47 UTC

Return-Path: <mark.edward.davis@gmail.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 AC8D23A6A5D for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 21:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.53
X-Spam-Level:
X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3]
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 FcWpFp4jWNiE for <ltru@core3.amsl.com>; Wed, 15 Jul 2009 21:47:38 -0700 (PDT)
Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id F15423A6983 for <ltru@ietf.org>; Wed, 15 Jul 2009 21:47:37 -0700 (PDT)
Received: by yxe34 with SMTP id 34so5096077yxe.29 for <ltru@ietf.org>; Wed, 15 Jul 2009 21:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=wjCxRmb8XE+BM2nb2BznHxOs/moWFV/ss1c+1AjvD4Q=; b=c3spAXRM4r0m2a9LSfzL/SLW25MeKMtyWUuzIwtN5UzuXkcvZiCclgBlOMDsg+Wc+w +8R1Eir9pNSU4GZeSxZAeGwVCUuHuwqO+5TywiJ9ErNZJCn7n7VobH7qaPRv6JXbFIj9 9Lo+jYAhiAjaD5G0sOKDcqrshU/EA6qsHwRvI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=vYelLJkO0Zv5cesJAGw/p95vOewFHsenuG3jcdDcapR0fYNJqpALqouv55+aI+4hgM R+PSLKicPcnY+msLXfkV3LW24AxrU7+xA5ZlvhIsUXPfXoC9yUL1pEJB9RBymKD4edOa ejfhZ+ECVrMm7KwgNL4i6FIDJvR25zxXUSUss=
MIME-Version: 1.0
Sender: mark.edward.davis@gmail.com
Received: by 10.100.127.2 with SMTP id z2mr11177678anc.75.1247718091843; Wed, 15 Jul 2009 21:21:31 -0700 (PDT)
In-Reply-To: <2C301BED90C8444795F972900C5C6E24@DGBP7M81>
References: <mailman.14390.1247692636.4936.ltru@ietf.org> <2C301BED90C8444795F972900C5C6E24@DGBP7M81>
Date: Wed, 15 Jul 2009 21:21:31 -0700
X-Google-Sender-Auth: a713216493e29106
Message-ID: <30b660a20907152121m1843e197v166c8474d21b9627@mail.gmail.com>
From: =?UTF-8?B?TWFyayBEYXZpcyDijJs=?= <mark@macchiato.com>
To: Doug Ewell <doug@ewellic.org>
Content-Type: multipart/alternative; boundary=0016e64078c8a4eb0e046ecb01ad
Cc: LTRU Working Group <ltru@ietf.org>
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:47:39 -0000

I'm only saying that for associations with regions, both of those are as
better than -6. And I would far rather see something like that than new
atomic codes in primary position - for variants that just doesn't work. You
are right about the stability issue: that's why I remarked about CLDR -
since we impose stability. So I'm making no proposal; just comparing
hypotheticals.

Mark


On Wed, Jul 15, 2009 at 21:00, Doug Ewell <doug@ewellic.org> wrote:

> 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  ˆ
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>