Browser IDN display policy: opinions sought

Andrew Sullivan ajs at
Mon Dec 12 16:23:02 CET 2011

On Mon, Dec 12, 2011 at 11:15:55AM +0000, Gervase Markham wrote:
> The list and the IDN TLD whitelist are two separate
> entities and used for different purposes (although I happen to be
> involved in them both). Let's not get them mixed up :-)

They work on the same principle, however: the policies of some group
other than that group that makes the delegation from the root is what

> > 
> > I think that the right approach would be A _if_ you could get the
> > advantages of B automatically somehow.
> And ponies! ;-)

Well, it's bound to sound that way if you don't take seriously the
idea that there might be a way to figure these things out.

Suppose that zone operators (not just the root or TLDs, but any random
zone you liked) had a mechanism by which you could look up their
policies for, say, code point inclusion.  That is, I'm RegyCo, and I
run .example.  I put an SRV or URI or something record at .example
that points you to a policy document that tells you what code point
ranges are permitted together in a single label in my zone, and also
(for that matter) what code points I will register _at all_.  Now you
are in a position to decide whether you think my policy is sensible;
and you are also in a position to decide whether any given label
actually meets my own stated policies.  Finally, since this forms the
basis for a filter in your software, you have the ability to set a
default for your users that makes sense, but also a way for people who
want it to get the benefits of the most permissive settings available
under approach A.  Finally, it wouldn't involve a massive scaling
problem facing the whitelist in the case the root zone increases
dramatically in size, since most of the work (all?) could be

Andrew Sullivan
ajs at

More information about the Idna-update mailing list