John C Klensin klensin at jck.com
Fri Mar 20 17:44:01 CET 2009


"Usual flak" notwithstanding, I think there are several
important corollaries to the reminders in your note.

First, roughly the same comments apply to lookup applications
that apply to registries.   There are many of them and will be
more in the future.  Although there are occasional exceptions,
in general nothing compels them to conform to any IETF (or
other) Standard other than the desire to interoperate with
others.   A client-side protocol like IDNA is particularly
problematic because it is often harder to tell whether the
standard is being followed or not than it is to make that
determination with a specification like SMTP or HTTP where more
of the protocol is exposed "on the wire".

For either lookup or registration activities, if local
considerations, perceptions of security requirements, or a
desire for a better user experience lead people to ignore some
of the provisions of a standard, they will probably do so.  If
the standard says to do one thing and a local regulator with
police authority says to do something else, some will try to
reeducate the regulators but, ultimately, the regulator is going
to win.

On the lookup side, we've seen many illustrations of this type
of situation.   IDNA2003 requires that native character forms of
strings be displayed to users if possible.   While the criteria
they use differs, most contemporary browsers ignore that
provision in favor of displaying the A-label forms if the
content of a domain name or local configurations convince them
that it is unwise to display the native character form for the

The possibility for local choices goes well beyond IDNA.
Nothing other than a desire for interoperability prevents an
application from basing its primary name lookup operations on
something other than the DNS, or on a DNS that uses one or more
alternate roots, or on DNS lookup or resolution algorithms that
are not quite conforming (e.g., by doing case matching
differently or assuming a non-ASCII base character set and
non-conforming handling of octets with the high bit set).  We
have seen all of those things in the alleged service of IDNs (as
well as for other reasons).

What we need to do is to make the best sets of design decisions
we can, explain them, and the reasons for them, well enough that
those making decisions will understand our reasoning and
conclusions, and then hope (and assume) that most of the
registries (zone administrators) and implementers will do the
right thing.  

There is really nothing else we can do.  If the Protocol Police
are called, they don't come.   If we approve IDNA2008 and all of
the browser vendors and search engines decide that absolute
backward compatibility with IDNA2003 is more important, than
IDNA2008 will be irrelevant.   Conversely, if pressures from
those who need the new characters or features of IDNA2008
prevail and those who don't support see the risk of losing
market share, then we will see a transition (just as we saw a
transition to IDNA2003, with all of the incompatibilities it
implied with both the non-standard RACE encoding and with
collections of alternate representation conventions.


--On Friday, March 20, 2009 10:55 -0500 Ebw
<ebw at abenaki.wabanaki.net> wrote:

> At the risk of drawing the usual flak ...
> "legislate" and some other word choices ("regulate" is
> another) are   misleading, as the relationship between gTLD
> registries and ICANN is   contractual, and the relationship
> between ccTLD registries is non-  contractual, though in some
> cases letters or memorada exist, and the   relationship
> between ICANN and second level and subordinate registries   is
> undefined.

More information about the Idna-update mailing list