Browser IDN display policy: opinions sought

[Andrew Sullivan]

On Mon, Dec 12, 2011 at 11:15:55AM +0000, Gervase Markham wrote:
> 
> The publicsuffix.org 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
matters.

> > 
> > 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
automated.

Best,
A
-- 
Andrew Sullivan
ajs at anvilwalrusden.com