Paul Robinson writes:
> You tell him that although it's gobbledygook to people without greek
> alphabet support, it will still work. It's not convenient, but it WILL
> work. Guaranteed.

False. IDNA does _not_ work. IDNA causes interoperability failures. Mail
will bounce, for example, in situations where ASCII domain names would
have worked fine. IDNA coauthor Adam Costello has admitted this.

> And that maybe replacing the DNS resolver on all the machines out
> there to be able to do lookups with PunyCode might be a TAD more 
> realistic than trying to get EVERYTHING, EVERYWHERE to be good with
> 8-bit?

Here you are assuming that the only problem is the DNS resolver---that
the conversion between the local character encoding and the IDNA
character encoding can be handled entirely by the DNS resolver.

That assumption is false. Consider, for example, an MTA configured to
accept mail for pi.cr.yp.to, with a Greek pi. The MTA compares the
incoming domain name to pi.cr.yp.to. That doesn't involve the resolver.

People who say that IDN is purely a DNS issue are confused.

> Making every piece of software and display device that might ever have
> to deal with IDNs capable of handling UTF-8?

Here you're being simultaneously inconsistent and shortsighted. Fixing
bad displays is part of the cost of IDNs. In the context of UTF-8, you
agree with me that this is a cost; in the context of IDNA, you ignore
the cost completely.

In fact, the cost of fixing UTF-8 displays is much _smaller_ than the
cost of fixing IDNA displays. UTF-8 has been around for many years, has
built up incredible momentum (as illustrated by RFC 2277), and already
works in a huge number of programs.

The extra programs hurt by IDNA aren't just UTF-8-aware clients. Fixing
the IDNA display failures also means changing web servers, mail servers,
DNS servers, etc., so that the sysadmin can put a properly displayed IDN
into his server configuration files. Think about the above pi.cr.yp.to
example again.

> The solutions you do offer will take at least 4 years IMHO to be
> effective

Let's suppose 4 years is right, and let's compare the results to IDNA
after 4 years.

IDNC3 requires 8-bit fixes to some widely deployed programs, certainly.
But IDNA needs _much larger_ changes in _many more_ programs. So, after
the same 4 years, only a fraction of the IDNA work will be done. IDNA
will still have an incredible number of display failures, plus the
interoperability failures and all the other IDNA problems.

Even worse, IDNA doesn't do _anything_ to fix the other half of the
email problem. Do you seriously believe that Chinese users will be
satisfied with email addresses where the domain part can contain Chinese
characters but the box part is still required to be ASCII? It's obvious
how to fix this with UTF-8; how, pray tell, do we fix it with IDNA?

I presume that you're not one of the 7-bit-forever crackpots. How do you
propose migrating from IDNA to UTF-8? This is much more costly than
moving directly to UTF-8, because it needs a compatibility period during
which everyone supports two different encodings of the same character.
Doesn't it bother you that the IDNA documents don't discuss this at all?

What makes your position particularly shameful is the fact that people
proposed requiring 8-bit transparency _eleven years ago_. If it hadn't
been for Paul Vixie et al. making your ``it'll take years!'' argument
back then, we would have had 8-bit transparency today. Do you want to be
facing the same stupid bugs in another eleven years?

> Until then, he has to get a 'normal' domain to see himself over.

Correct. Your example Greek user has an ASCII domain name that's always
displayed with an ASCII d instead of the truly desirable Greek delta. 

Now, please explain why the same user should prefer a domain name that's
_occasionally_ displayed with the desired delta but _usually_ displayed
as incomprehensible gobbledygook.

Your answer, of course, will be something like this: ``The gobbledygook
is a temporary problem. In twenty years, after the massive IDNA upgrade
is complete, everyone will see a delta!''

In short, you're looking at the long-term IDNA benefits (never mind the
interoperability failures and all the other problems) but refusing to
look at the long-term UTF-8 benefits. Inconsistent once again.

> Something should be done, but your document make you look like a
> typical whiner - you point out all the problems, but offer no
> solutions to some of the problems you raise.

False. http://cr.yp.to/proto/idnc3.html explains how IDNC3 offers
solutions to every one of the IDNA problems that it points out:

   * interoperability failures;
   * inconsistent displays of the same name;
   * unnecessary implementation and deployment costs;
   * multiple semantically similar names;
   * identical displays of different names; and
   * typing failures.

Each solution is listed right next to the problem, so I can't imagine
how you missed this.

> What you are proposing IS introducing an interoperability failure,

False. Every step in http://cr.yp.to/proto/idnc3.html preserves
interoperability.

> How are you proposing to display alpha-ol.com on a VT100?

There are several options. One option is to work around the hardware
limitations in software, displaying something like

          |
   /\/ /\ |   /^ /\ /\ /\
   \/\ \/ | * \_ \/ | | |

Another, much more popular, option is to move your email reading, web
browsing, etc. from your 1970s-vintage VT100 to a graphics terminal.
Have you considered the VT340, for example? Or an IBM PC, model 5150?

> a good 20% of sites out there will just have to shut down ops permanently

Get a grip, Paul.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago