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

[Mark Davis <[e-mail]>]

I agree with Doug that we'd want to tread very carefully with regards to
adding ISO 639-6. The rollout over a couple of years of the changes that we
are currently making will teach us a lot.

Mark


On Wed, Mar 11, 2009 at 18:02, Doug Ewell <[e-mail]> wrote:

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