UTC Agenda Item: IDNA proposal

John C Klensin klensin at jck.com
Thu Nov 23 06:39:49 CET 2006

--On Thursday, 23 November, 2006 13:46 +0900 Yangwoo Ko
<newcat at icu.ac.kr> wrote:

>> However I still think that the "default" policy for scripts,
>> until some reliable word comes from a reasonable
>> representative, should be permissive, unless they are
>> specifically suspected to have problems...
> As you understand, it is fairly troublesome to make domain
> labels
> invalidated later. Thus, restrictive approach seems to be a lot
> better to me.

Sam, to add a bit to Yangwoo's comments, with which I agree,
there are two problems with "permissive and then restrict".  

The first is that many of the restrictions will inevitably be
applied after bad experiences.   One of the faster ways to kill
whatever utility is left in IDNs (see comment below) is to
create a reputation in which we are making a new restriction
every few weeks, based on the attacks, possibly
widely-publicized attacks, of the intervening period.
Especially since IDNA is client-based, reaction and upgrade time
to deploy restrictions is likely to be slow to reach even the
80% level, making things even worse.

The second is that the TLD part of this story -- whether in
ccTLDs or the for-profit gTLDs -- typically involves some rather
intricate business models in terms of, e.g.,
registrant-registrar-registry relationships to say nothing of
ICANN, governments, etc.  Restricting a name out of existence
that someone has paid money for, obtained in good faith, and
used and advertised to others is a bad business proposition.  It
has the potential for claims by the registrant for compensation
for all sorts of real or imagined injuries, especially if it is
not done as part of a single, well-justified, and sweeping

I don't think we want to go there and, in practical terms, I'd
suggest that doing so is nearly impossible.


More information about the Idna-update mailing list