<div dir="ltr">I think it is time to start a serious campaign to move to the IDNA2008 standard for the simple reason that it decouples dependence on a fixed and now very old version of UNICODE. Opinions about backward compatibility vary. I am more sanguine about accepting incompatibility with past choices than others - the non-letter characters may be cute but their cost is too high and utility too low, as I see it. <div>
<br></div><div>As the TLD space expands and IDNs become more popular, canonical representations and decoupling from versions of UNICODE are essential for stability, uniformity and interoperability.  It will only get more messy with time if we don't get going on this objective.</div>
<div><br></div><div>vint </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 7:02 AM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</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 22/08/13 11:37, Anne van Kesteren wrote:<br>
>> Shame for them. The writing has been on the wall here for long enough<br>
>> that they should not be at all surprised when this stops working.<br>
><br>
> I don't think that's at all true. I doubt anyone realizes this. I<br>
> certainly didn't until I put long hours into investigating the IDNA<br>
> situation.<br>
<br>
</div>It's not been possible to register names like ☺☺☺.com for some time now;<br>
that's a big clue. The fact that Firefox (and other browsers, AFAIAA)<br>
refuses to render such names as Unicode is another one. (Are your<br>
friends really using <a href="http://xn--74h.example.com/" target="_blank">http://xn--74h.example.com/</a> ?)<br>
<br>
Those two things, plus the difficulty of typing such names, means that<br>
their use is going to be pretty limited. (Even the guy who is trying to<br>
flog <a href="http://xn--19g.com/" target="_blank">http://xn--19g.com/</a> , and is doing so on the basis of the fact that<br>
this particular one is actually easy to type on some computers, has not<br>
in the past few years managed to find a "Macintosh company with a<br>
vision" to take it off his hands.)<br>
<div class="im"><br>
> Furthermore, we generally preserve compatibility on the web so URLs<br>
> and documents remain working.<br>
> <a href="http://www.w3.org/Provider/Style/URI.html" target="_blank">http://www.w3.org/Provider/Style/URI.html</a> It's one of the more<br>
> important parts of this platform.<br>
<br>
</div>(The domain name system is about more than just the web.)<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>
So what is the justification for removal of non-letter characters?<br>
Reduction of attack surface. When characters are divided into scripts,<br>
we can enforce no-script-mixing rules to keep the number of possible<br>
spoofs, lookalikes and substitutions tractable for humans to reason<br>
about in the case of a particular TLD and its allowed characters. If we<br>
allowed 3,254 extra random glyphs in every TLD, this would not be so.<br>
<br>
Gerv<br>
</blockquote></div><br></div>