<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">I suspect the reason was simply unfamiliarity with BCP47, since that is the standard way to represent languages (and locales).</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><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">Mark</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></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jul 12, 2016 at 8:29 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">Today on the IETF "Daily Dose" page, I noticed a draft for Matroska<br>
(draft-lhomme-cellar-matroska-00), a proposed new multimedia container<br>
format based on Extensible Binary Meta Language (EBML), also in draft<br>
form. Both are individual submissions, associated with the cellar WG.<br>
<br>
In this 220-page draft, I found the following:<br>
<br>
> 6.2.1.  Language Codes<br>
><br>
> Language codes can be either the 3 letters bibliographic ISO-639-2<br>
> [13] form (like "fre" for french), or such a language code followed<br>
> by a dash and a country code for specialities in languages (like<br>
> "fre-ca" for Canadian French).  Country codes are the same as used<br>
> for internet domains [14].<br>
<br>
I wonder if there was some particular reason for choosing this hybrid<br>
approach instead of simply referencing BCP 47 and applying constraints<br>
as desired (e.g. "no variants or extlangs"). Among other benefits, using<br>
BCP 47 would provide access to many more languages (more than 8000<br>
instead of 485), avoid the GB/UK problem, and promote the objective of<br>
IETF specifications referencing other IETF specifications.<br>
<br>
What makes this all a bit strange is that EBML itself, written by two of<br>
the three authors of Matroska, does specify the use of RFC 5646 for<br>
<documentation> sub-elements.<br>
<br>
--<br>
Doug Ewell | Thornton, CO, US | <a href="http://ewellic.org" rel="noreferrer" target="_blank">ewellic.org</a><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" rel="noreferrer" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
</blockquote></div><br></div>