Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever

["D. J. Bernstein" <djb@cr.yp.to>]

John Stracke writes:
> For that matter, a well-designed application will not even make it 
> possible to enter anything but ASCII in an input field (whatever) for a 
> domain name.

That's incredibly bad design.

You're violating the basic principles of information hiding articulated
by Parnas in the early 1970s. Instead of isolating the name-existence
decision in one place (the DNS server's database), you're spreading the
decision across a huge number of programs on a huge number of machines.
Changing a decision becomes extremely expensive.

We're seeing the economic consequences of this in BIND's res library.
That library is the most widely used UNIX DNS-lookup mechanism, and is
one of the largest sources of UTF-8 failures; see http://pi.cr.yp.to. It
has to be fixed on a huge number of machines.

(Note that this cost, together with the other costs of making UTF-8 IDNs
work, is only a tiny fraction of the costs of making IDNA work.)

If you think that the 8-bit problems in res are an example of people
agreeing with your design ideas, you're mistaken. The change was made in
a panic in 1996, when CERT announced that several programs had security
flaws based on careless use of DNS PTR results. Of course, anyone who
thinks about the problem for a moment can see that unusual DNS A _input_
has no relevance to the security issue, but people in a security-related
panic often don't stop to think about the damage they're causing.

> Basic rule of usability: making user mistakes impossible is 
> better than catching them after the fact.

You obviously aren't achieving that goal. You're catching typos if and
only if they involve non-ASCII characters. What about ASCII typos? What
is the basis for your assertion that the no-such-name message should, as
a matter of UI design, be different between these two situations?

Even worse, what about ASCII typos that produce valid domain names?

Basic rule of usability: Have the computer copy the data so that the
user doesn't have an opportunity to make a mistake. Saves time, too.

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