<div dir="ltr"><font face="times new roman,serif">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.</font><div>
<font face="times new roman, serif"><br></font></div><div><font face="times new roman, serif">While we did allow for this in extremis, to allow for technical conflicts, this is not one of those. See <a href="http://tools.ietf.org/html/bcp47#page-1-36">http://tools.ietf.org/html/bcp47#page-1-36</a></font></div>
<div><font face="times new roman, serif"><br></font><div><font face="times new roman,serif"><br></font></div><div><pre class="" style="margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><font size="1"> 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.
</font></pre></div><div><br></div></div><div style><font face="times new roman, serif">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.</font></div>
</div><div class="gmail_extra"><br clear="all"><div><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div>
<div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><br></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<a href="https://plus.google.com/114199149796022210033" target="_blank">Mark</a></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div>
<br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 12:17 PM, Doug Ewell <span dir="ltr"><<a href="mailto:doug@ewellic.org" target="_blank">doug@ewellic.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've written to ISO 639-3/RA to ask, IF any change is to be made for<br>
Mapudungun to get rid of the "offensive" code element 'arn', that they<br>
simply retire the code element and replace it with another one.<br>
<br>
There is no problem for BCP 47 if the RA does this. Every year, ISO<br>
639-3 retires many code elements—sometimes dozens—and replaces them<br>
with others. Often this is because of a code element split, where the<br>
exact denotation has changed, but that doesn't factor into the BCP 47<br>
response. The BCP 47 response is simple: add the new subtag(s) and<br>
deprecate the old subtag, with an appropriate Preferred-Value or<br>
Comments field. Problem solved, for BCP 47 anyway. (Windows and other<br>
systems that already have 'arn' embedded probably will and should go on<br>
using it, just as Java still uses 'iw' for Hebrew instead of 'he'.)<br>
<br>
Proposed "solutions" such as macrolanguages, collection code elements,<br>
merging of other languages into Mapudungun under a new individual code<br>
element, or other "special cases" should NOT be considered unless that<br>
solution would have been adopted anyway, based on prevailing knowledge<br>
of the languages, and WITHOUT taking into account the sentiment to move<br>
away from 'arn'. There is no reason to cleverly "code around" the<br>
situation to avoid retiring 'arn', at least not any BCP 47 reason.<br>
Ethnologue says that Huilliche is "barely intelligible with" Mapudungun,<br>
which is about the worst basis for creating a macrolanguage that I can<br>
imagine.<br>
<br>
Unfortunately, the fact that we are talking about a code element in<br>
639-2 as well as in 639-3 means the final authority belongs to the JAC,<br>
which probably means we won't see a decision in the very near future.<br>
But this is the decision I support.<br>
<br>
--<br>
Doug Ewell | Thornton, CO, USA<br>
<a href="http://ewellic.org" target="_blank">http://ewellic.org</a> | @DougEwell <br>
<br>
_______________________________________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
</blockquote></div><br></div>