Re: [Ltru] rechartering to handle 639-6

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  ˆ