Browser IDN display policy: opinions sought

Eric Brunner-Williams ebw at
Tue Dec 13 18:09:04 CET 2011

On 12/13/11 10:49 AM, Andrew Sullivan wrote:
> In the area of spam control, despite all the nasty side effects,
> consulting several different abuse lists (which we might like to think
> of as "reputation services") gets you more information to base your
> decisions on.  ...

Circa 2002 there was wide spread filtering of one 2000 round new gTLD
due to the difference between its stated purpose and policy, and its
actual registration policy, as the latter made the namespace
accessible to unsollicited commercial emailers. The reputation effect
persisted for several years (and may still persist).

The point being that examples of autonomous mechanism behavior tending
towards apparent, even actual coherency of policy, exist for
namespaces, not just domain names, addresses, and address block

> ... I don't see why a similar approach might not work for
> IDN display, _provided that_ zones have a way of stating what it is
> they're trying to do.  Such a mechanism (and calling this hand-wavy
> sketch of an idea a "proposal" is giving it too much credit) would be
> extremely imperfect and it would mean that new names always started at
> a disadvantage.  But it would at least give us something to build on.

The obverse would be the claim that non-global semantics can not
exist, and that state may not accumulate.

We've sort of been down this path before with gedanken experiments
about encoding discovery, the query-and-response problem, however,
here the problem is display, for which out-of-protocol mechanisms are

Since we're hand-waving, waving in the general direction of REPUTE
and/or DOMAINREP may necessary to access accumulated state, but may be
insufficient to determine a locally likely display property of some
non-ASCII label.

Two beads and change,

More information about the Idna-update mailing list