Basic IDN assumptions (was: Re: The Future of IDNA)

John C Klensin klensin at
Fri Mar 20 06:37:19 CET 2009


I think your line of argument here both unrealistic and is very
seriously wrong but, before trying to address the "wrong" part,
I want to try to look at a few separate, and separable, issues,
for which I'm going to try to use separate subject lines. The
first of these is part of "unrealistic"....

--On Thursday, March 19, 2009 11:12 -0700 Erik van der Poel
<erikv at> wrote:

> We are at a critical point in time between the history and
> future of IDNA. I believe we have allowed ourselves to be
> distracted by a couple of topics, as follows.
> DNS extensions. A number of ideas have been discussed about DNS
> responses that would allow IDN display preferences and IDNA
> version transition.

First of all, in order to have any hope of making progress on
IDNA (for any definition of "progress" you like other than
mediating on the issues for several years and hoping reality
changes), it is necessary to take some small number of things as
given -- axioms for designing a practical IDN system if you want
to look at it that way.  They include (I hope this is a complete
list, but can't prove it):

(1) Unicode is the base reference character set and it is what
it is.  If you want to go around the world looking for folks who
don't like some detail of Unicode's design decisions, you won't
have far to go before finding the first one, or the second, or
the hundredth.   An undertaking like Unicode involves many
tradeoffs, second-guessing is easy, and there is always some
particular situation in which a different decision might have
been better (even if it would have been obviously worse for
global use and all of the other cases).  I've got my list of
things I wish they would have done differently and a separate
list of decisions that I believe were wise on balance but that
are inconvenient for IDNs.  I rather imagine that there are
decisions that Ken, Mark and/or others who have been involved
for years would make differently if the requirements of
stability and forward compatibility permitted "do overs".   But,
even if one doesn't like it at all, barring going back to
stateful encodings and code page switching, it is the only game
in town; there are no alternate proposals.

(2) The DNS is the DNS.  It works in particular ways and some of
those ways impose constraints on possible extension models and
the like.  It does not represent the best of distributed
database technology by today's standards; you won't have to look
far to find someone to tell you that it did not represent the
best of fast-response distributed database technology in 1983
(although, given all of the constraints, you would find people
who would dispute that).  To make things a little worse, it was
designed as a system for associating identifiers with network
resources.  It was certainly well-known significantly before the
DNS came along that hierarchical systems designed for
vocabulary-like applications by ordinary users (as distinct from
trained specialists) needed the sort of things you've probably
seen in thesaurus systems, e.g., "see instead" and "see also"
links, arrangements that have rather different properties from
DNS CNAMEs and DNAMEs.  The DNS design didn't (and doesn't) have
those features because they weren't design goals... and one
cannot retrofit them without redesigning the whole system.

One of the things that comes with the DNS is a collection of
historical design and implementation decisions that result in
very slow deployment of new features that have to be understood
by both clients (stub and full-service resolvers) and servers to
be really useful.  Some of the latter is a DNS-specific problem,
some of it is just a component of an observation that it is
often very difficult to deploy a new application or feature on
the Internet if it replaces something that works even moderately
well (or even "almost works").  Completely new applications that
fill a need that no one previously knew they had deploy quickly,
so do new applications or features for which there is a wide
perception of a compelling need.  But "improvements" have
usually been a hard sell and/or very slow deployment process.

Again, you wouldn't have to look very far among those who
understand the DNS (and especially among those who are really
expert) to find people with lists of things that they wish had
been done differently.  But as with alternatives to Unicode,
there are no proposals for alternatives and no obvious way to
get there if there were (replacing the DNS would probably be
easier than replacing Unicode, but don't think in terms of less
than a decade).

(3)  Whatever one does with IDNA, it can't be protocol specific,
optimized to work with the web and less satisfactory, or relying
on different mechanisms, for other applications.

It seems to me that several of the comments in your note violate
one or more of the above assumptions.  I haven't responded very
much to similar comments in earlier notes because I just don't
know how to do so.  I'd like an opportunity to redesign the
world without the sort of constraints implied by the above.  But
this is pretty much an engineering problem in which those
preconditions are design constraints... at least if one believes
the other design constraint, which is the need to get something
out there that can be deployed and to do so in a reasonable
amount of time.

Some specific details in the notes that follow.


More information about the Idna-update mailing list