<div dir="ltr"><div class="gmail_default" style="font-family:'times new roman',serif">I think this conversation is devolving a bit. There were many controversial topics and a huge number of exchanges during the course of the development of IDNA2008. Dredging them up and repeating them here will not do anyone any good, and the flood of emails just cause listeners to tune out.</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">So I'd like to bump up a level, and get back to the real questions, which is how to move the clients (browsers, search engines, etc.) forward.</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">There are three major options for clients:</div><div class="gmail_default" style="font-family:'times new roman',serif">
<ol><li>Move immediately to IDNA2008.</li><li>Stay on IDNA2003.<br></li><li>Move to TR46+IDNA2008 as a transition to IDNA2008.</li></ol><div>Recent history has shown that the major clients are reluctant to do #1 because of compatibility concerns. I don't think anyone really wants #2, because it has an archaic Unicode version, but people are sticking with that if they see #1 as the only other choice.</div>
<div><br></div><div>That effectively leaves #3. And certainly major players like IE have shown that it can be deployed effectively.</div></div><div class="gmail_default" style="font-family:'times new roman',serif">
<br></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 Thu, Aug 22, 2013 at 1:11 PM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@annevk.nl" target="_blank">annevk@annevk.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Aug 22, 2013 at 12:02 PM, Gervase Markham <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>> wrote:<br>
> It's not been possible to register names like ☺☺☺.com for some time now;<br>
> that's a big clue.<br>
<br>
</div>I don't think it is. There's sites out that rely on underscore working<br>
in subdomains. You cannot register a domain name with an underscore.<br>
<div class="im"><br>
<br>
> (Are your friends really using <a href="http://xn--74h.example.com/" target="_blank">http://xn--74h.example.com/</a> ?)<br>
<br>
</div>Yeah (with "example" replaced). Renders fine in Safari, too.<br>
<div class="im"><br>
<br>
> IIRC, we must have broken a load of URLs when we decided that %-encoding<br>
> in URLs should always be interpreted as UTF-8 (in RFC 3986), whereas<br>
> beforehand it depended on the charset of the page or form producing the<br>
> link. Why did we do that? Because the new way was better for the future,<br>
> and some breakage was acceptable to attain that goal.<br>
<br>
</div>Actually, I don't think we did. And the reason for that is that the<br>
non-ASCII usage was primarily in the query string. And as it happens,<br>
we still use the character encoding to go from code points to<br>
percent-escaped byte code points there. The IETF STD doesn't admit to<br>
this, which is part of the reason why we have<br>
<a href="http://url.spec.whatwg.org/" target="_blank">http://url.spec.whatwg.org/</a> now.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
<a href="http://annevankesteren.nl/" target="_blank">http://annevankesteren.nl/</a><br>
</font></span></blockquote></div><br></div>