baking into the protocol

[Gervase Markham]

John C Klensin wrote:
> That conclusion has two corollaries that I think we need to
> understand.  The first is that trying to build a "no mixed
> scripts in a label" rule into the protocol is probably an idea
> that isn't going anywhere (and shouldn't).  The second is that
> any rule in application software that treats mixed-script labels
> as inherently dangerous should be extremely localized, probably
> examining the user's preferred languages or scripts and the
> particular combinations of scripts being mixed, lest one
> generate warnings about many safe situations and thereby cause
> users to discount warning information that really is important.

I would again ask: what proportion of domain-name-handling software 
today has a good awareness of a user's preferred languages or scripts?

Even if I let you have "the browser" (and I'd argue that in many cases 
it doesn't have a good idea), there are loads of other applications 
handling domain names. Updating them all so that they need to be 
configured with a list of languages for each different person which uses 
them, and making users worldwide do that configuration whenever they sit 
down at a new application installation, seems to me to be a 
disproportionate solution given that we can achieve the same effect 
through 200 lines of code and some registry policy.

An arbitrary domain name containing any mixture of scripts is entirely 
safe as long as no other domain name confusable with it can be 
registered by someone else. Script mixing is not the issue; 
confusability is.

For example, payp<cyrillic-a>l.com is safe (albeit a bit pointless) as 
long as it's owned by paypal.com (as I believe it now is).

If we have the ability to programmatically decide if a given domain name 
is potentially confusable with another one, as I think we do (the 
Unicode consortium has a very useful character list for this purpose, 
which we could adopt and perhaps augment), then applying that algorithm 
to every registration at registration time would result in the desired 
safety from spoofing.

I've already covered recently the "but what about sub-sub domains?" 
objection to this, but to recap: as long as the individual components of 
a domain name are clear (and they should be, as the process we are going 
through should blacklist the characters confusable with . and /) then 
the above plan suffices. I don't care if one user of everson.com spoofs 
another one; but the administrator for the everson.com DNS should.

Gerv