Browser IDN display policy: opinions sought
Andrew Sullivan
ajs at anvilwalrusden.com
Mon Dec 12 16:23:02 CET 2011
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
More information about the Idna-update
mailing list