Browser IDN display policy: opinions sought
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Tue Dec 13 05:52:11 CET 2011
On 2011/12/13 8:50, Andrew Sullivan wrote:
> On Mon, Dec 12, 2011 at 04:54:27PM +0000, Gervase Markham wrote:
>> It is the sole survivor of a large number of alternative proposals
>> that were considered and rejected. Unlike most of the other rejected
>> proposals, it does not need any modifications to the DNS protocol, or
>> distribution of "language" codes for labels, nor does it require
>> multiple DNS lookups, large character tables in the browser, or
>> real-time access to WHOIS information.
> The only reason the latter two of these are true is because the root
> zone is small. If it grows to several thousands of labels a
> significant number of which are IDNs, the last two advantages turn out
> to be fatal flaws, because there's no practical way to make the
> decision that you need to make on heuristic grounds. I'm not trying
> to dismiss those factors; I think those are indeed advantages to the
> existing solution. But as you see in this thread, there are
> disadvantages that also pile up; and I think that pile gets bigger as
> the root zone expands.
Even without significant growth in the root zone, "large character
tables in the browser" is actually very relative.
http://www.unicode.org/Public/UNIDATA/Scripts.txt is about 120kB, but
most of it is spaces and comments, and it separates out characters by
character class. Removing character class and taking into account gaps
and stuff that's not allowed in IDNs anyway, the table can be
More information about the Idna-update