proposed ISO 639 change for "arn"

[Mark Davis ☕]

I object. A fundamental goal of BCP47 is stability. This runs the risk of
introducing the "iw" / "he" problem which has plagued us to this day.

While we did allow for this in extremis, to allow for technical conflicts,
this is not one of those. See http://tools.ietf.org/html/bcp47#page-1-36


   2.   Values in the fields 'Preferred-Value' and 'Deprecated' MAY be
        added, altered, or removed via the registration process.  These
        changes SHOULD be limited to changes necessary to mirror changes
        in one of the underlying standards (ISO 639, ISO 15924, ISO
        3166-1, or UN M.49) and typically alteration or removal of a
        'Preferred-Value' is limited specifically to region codes.


A major reason for the development of BCP47 was to guard against the
instability of underlying ISO standards. If iana goes down this path, I
think the result will be a new standard on top of BCP47 that guards against
instability in that! Nobody should want that.


Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**


On Wed, Jan 9, 2013 at 12:17 PM, Doug Ewell <doug at ewellic.org> wrote:

> I've written to ISO 639-3/RA to ask, IF any change is to be made for
> Mapudungun to get rid of the "offensive" code element 'arn', that they
> simply retire the code element and replace it with another one.
>
> There is no problem for BCP 47 if the RA does this. Every year, ISO
> 639-3 retires many code elements—sometimes dozens—and replaces them
> with others. Often this is because of a code element split, where the
> exact denotation has changed, but that doesn't factor into the BCP 47
> response. The BCP 47 response is simple: add the new subtag(s) and
> deprecate the old subtag, with an appropriate Preferred-Value or
> Comments field. Problem solved, for BCP 47 anyway. (Windows and other
> systems that already have 'arn' embedded probably will and should go on
> using it, just as Java still uses 'iw' for Hebrew instead of 'he'.)
>
> Proposed "solutions" such as macrolanguages, collection code elements,
> merging of other languages into Mapudungun under a new individual code
> element, or other "special cases" should NOT be considered unless that
> solution would have been adopted anyway, based on prevailing knowledge
> of the languages, and WITHOUT taking into account the sentiment to move
> away from 'arn'. There is no reason to cleverly "code around" the
> situation to avoid retiring 'arn', at least not any BCP 47 reason.
> Ethnologue says that Huilliche is "barely intelligible with" Mapudungun,
> which is about the worst basis for creating a macrolanguage that I can
> imagine.
>
> Unfortunately, the fact that we are talking about a code element in
> 639-2 as well as in 639-3 means the final authority belongs to the JAC,
> which probably means we won't see a decision in the very near future.
> But this is the decision I support.
>
> --
> Doug Ewell | Thornton, CO, USA
> http://ewellic.org | @DougEwell ­
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/ietf-languages/attachments/20130109/793bfbd0/attachment.html>