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 ˆ
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.