John C Klensin klensin at
Fri Mar 7 17:07:20 CET 2008

--On Friday, 07 March, 2008 14:59 +0000 Gervase Markham
<gerv at> wrote:

> John C Klensin wrote:
>> Partially because the prohibition in 3490 on display of
>> punycode didn't work (some browser vendors now view display
>> of punycode in varying circumstances as a feature) 
> "A feature" is a bit strong; "the least worst thing to do" is
> probably better.

Understood.  I meant "feature" only in the sense that, had you
not had even the "display punycode" option, we all would have
been in worse trouble.

> When displaying the decoded version would
> lead to risk to the user, and displaying nothing is not an
> option, the punycode version at least has the significant
> advantages that it's a) always readable and b) unique to that
> domain.


> Ideally, Firefox would never display punycode in normal
> browsing, because all registries would have homograph policies
> and would have registered for the whitelist. I admit it does
> continue to surprise me that various large GTLDs have not
> attempted to register. But I guess that's their business
> decision.

And, of course, the other problem here is that your approach to
registering TLDs and their policies is another "best available
option" (not much different from "least worst").   We know that,
in the vast majority of cases, the TLD operators have very
little control over what happens at the third level and below.
They could try to assert and maintain that control contractually
but, with a small (and I think shrinking) number of exceptions,
they don't.   So that technique, to some extent, rewards the bad
guys who register in "good" domains and punishes second and
third level registries who are careful about their registrations
but part of TLDs who refuse to adopt clear policy positions.

We should also be clear that there are no specific anti-spoofing
provisions in the new proposals.  The problem is just too
intractable to be dealt with globally and as a matter of
protocol, but must remain largely a matter for responsible
registration policies.

The proposals do, however, provide some better handles than are
present in IDNA2003.  One of them is precisely the elimination
of the mapping rules as part of the protocol.  Permitting
compatibility characters _in domain names_ significantly widens
the possible "opportunities" for deliberate confusion.   It may
also be possible to use the "contextual rule" model to eliminate
some cases that would otherwise be problematic.   And, since
both of those principles are enforced at lookup time, we provide
a better mechanism for identifying obviously-dangerous cases,
better guidance about how to handle them, and a basis for
refusing to look them up at all without having to violate the


More information about the Idna-update mailing list