<div dir="ltr"><div class="gmail_extra"><div class="gmail_default" style="font-family:"times new roman",serif">​> simply ignoring ISO XXX as out of scope for BCP 47</div><div class="gmail_default" style="font-family:"times new roman",serif"><br></div><div class="gmail_default" style="font-family:"times new roman",serif">Recharting is not attractive at all. Best — if they go they way they are going — would be to ignore as out of scope. If and when relevant features and data materialize, an extension would be feasible.</div><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="margin:0px;background-color:transparent"><div></div></div><div style="margin:0px;background-color:transparent">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 Sat, Aug 27, 2016 at 9:01 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Peter Constable wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Follow-up on this topic:<br>
<br>
L2/16-242<br>
Ballot results for TC37/SC2 New Work Item Proposal: Identification and<br>
description of language varieties<br>
</blockquote>
<br>
Yeah, saw that.<br>
<br>
It's still not clear to me how supporters intend to work this into BCP 47, or to what extent they understand the language identification options already available. Comments about benefits to the linguistics community seem sensible -- those folks can always use more detail -- but some NBs wrote that this granularity is critically important to tagging of software and IT resources. I would not have guessed that, especially for varieties like stuttering or "motherese" or "individual speaker."<br>
<br>
There is a perception that BCP 47 encourages (not just "permits") excessively long and detailed language tags. It's known that some specifications that reference BCP 47, such as other RFCs, feel it necessary to add extra "health warnings" about keeping tags short, even restricting them to primary language subtags only, ignoring Section 4.1 of RFC 5646 which already advises against using unnecessary subtags. The notion of applying this NWIP to BCP 47 seems to go in the opposite direction.<br>
<br>
If this is issued as a standard, naturally there would have to be some sort of registry for values like "business speak" or "Two-word-stage," and some way of handling the really open-ended values like "John Doe." Shoehorning the speaker's name into extension subtags isn't as straightforward as it might seem: what if the speaker's last name is "Constable" and thus longer than 8 letters? What if there's more than one Peter Constable out there?<br>
<br>
We would always have the option of rechartering the LTRU WG to create a new BCP 47 spec (replacing 5646) to support ISO XXX inherently, creating a new extension spec per Section 3.7, or simply ignoring ISO XXX as out of scope for BCP 47.<br>
<br>
--<br>
Doug Ewell | Thornton, CO, US | <a href="http://ewellic.org" rel="noreferrer" target="_blank">ewellic.org</a> <br><div class=""><div class="h5">
______________________________<wbr>_________________<br>
Ietf-languages mailing list<br>
<a href="mailto:Ietf-languages@alvestrand.no" target="_blank">Ietf-languages@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages" rel="noreferrer" target="_blank">http://www.alvestrand.no/mailm<wbr>an/listinfo/ietf-languages</a><br>
</div></div></blockquote></div><br></div></div>