Re: [idn] Why IDNA breaks copy-and-paste

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

In July 2001, when this failure pattern was pointed out, Costello
admitted that ``getting an IDN for my domain'' would cause failures with
IDNA during his proposed (multi-year) software upgrade. He admitted that
his previous ``nothing will actually break'' comment was ``overstated.''

He claimed that IDNA ``fails in fewer instances'' than other proposals.
So what? IDNA indisputably fails in more instances than the status quo.

Now, several months later, many IDNA proponents once again seem to
believe that they can deploy IDNA right now without breaking anything.
But that belief doesn't stand up to an examination of the facts.

Kent Karlsson writes:
> For "copy and paste" involving a terminal emulator, the
> "application" of interest is the terminal emulator itself.  

This ``application,'' like a browser looking at the output of a web-mail
server, doesn't know where the domain names are, so it can't convert
those names to PunyCode for copy-and-paste.

Bottom line: If the user sees (glyphs for) non-ASCII characters, then
other programs will receive non-ASCII characters (in the local character
encoding). Many of those programs won't know anything about IDNA, so
their domain-name lookups will fail.

How are we supposed to avoid these failures? What are software authors
supposed to do? Why do the IDNA proponents keep dodging this fundamental
question?

> Now, converting from a stream of characters to a stream of
> glyphs is in general a non-trivial step.

Irrelevant. Copy-and-paste grabs characters, not glyphs. You are putting
a huge amount of effort into attacking a stupid copy-and-paste design
that no sane programmer would use.

The current X release has full UTF-8 support; you simply set a UTF-8
locale such as LANG=en_US.UTF-8. Copy-and-paste handles full Unicode.

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