Browser IDN display policy: opinions sought

Andrew Sullivan ajs at anvilwalrusden.com
Tue Dec 13 00:50:04 CET 2011


On Mon, Dec 12, 2011 at 04:54:27PM +0000, Gervase Markham wrote:
> If I am to do such a check (and presumably to fail if the domain doesn't
> meet it), what about when a policy changes to be more strict? How do you
> deal with grandfathering?

Yes, we're going to have a problem with this.  But note that nothing
says that this policy needs be the one you actually register with;
it's just the way that you state, "I permit these things together."
But this is admittedly sort of hand-wavy right now.  It is entirely
possible that this is a fatal problem; but you already have that fatal
problem today, so I don't see how this is any worse than a problem you
have now.

> What about performance? I would need to look up the rules for the zone
> "foo.com" every time I accessed bar.foo.com, for lots of values of foo.
> This doesn't sound like it would improve performance.

I was sort of imaginging that these policies (1) would be cacheable,
so that you wouldn't actually need to do things in real time all the
time, and (2) would fail soft, so that you fall back to A-label form
until you've managed to fetch the relevant policy (at which time you
can check the label against the policy and update the display as
necessary).

> If there are going to be rules, by far the best place to enforce them is
> once at domain registration time, not in real time in performance
> critical code millions of times a day at access time.

Right.  But you're talking about different kinds of rules: (1) how do
I display this? and (2) what is permitted for registration?  You want
(1) to be linked to (2) some how, and I agree.  But I cannot see how
either shipping static lists around or else relying on
language-guessing of intended domains actually addresses the user
problems we're attempting to talk about.

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

Best,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


More information about the Idna-update mailing list