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

Peter Constable <petercon at microsoft dot com> wrote:

> 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).

We're talking about two separate issues here:

1. Whether the RFC 4646 decision to reserve 4-letter language subtags 
"for future use," widely assumed to be ISO 639-6, was a good one, and 
specifically whether ISO 639-6-based subtags would add sufficient value 
to BCP 47.

2. Whether a future decision on creating 4-letter language subtags, for 
whatever reason, should be influenced by the existence of one or more 
derivative applications that are non-conformant to BCP 47.

Regarding issue 1, I'm reserving judgment until all of the 639-6 data 
becomes publicly available, and until LTRU and/or ietf-languages have 
had a chance to look at it and start discussing it.  I also agree with 
Martin that some working experience with the 7,500 language subtags 
available in the 4646bis era would be helpful.  As you can tell, I do 
have opinions about how they should be added *if* they are to be added.

Regarding issue 2, I'm very much against letting this be a contributing 
factor.

>> 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"?

I mean I'm opposed to adding thousands of variant subtags, either in 
mass *or* one by one, using a formulaic process such as prepending '6' 
to thousands of ISO 639-6 code elements.  Variants are supposed to be 
proposed, discussed, and approved (or rejected) on a case-by-case basis. 
They are not supposed to be a means of shoehorning in another external 
standard.  That is what the other two solutions -- 4-letter language 
subtags and extensions -- are for.

> If so, I agree.

--
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  ˆ