Re: [idn] WG last call summary

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

Randy Bush writes:
> could you give one *simple* *concrete* example of the failure mode you
> fear?

I assume that by ``failure mode'' you're referring specifically to
interoperability problems. Here's another example.

The ezmlm-list program takes a local mailing-list name on its command
line and sends the subscriber list to stdout. People use this program in
two ways:

   (1) Displaying the results on the screen, for human consumption. For
       example, the ezmlm-list output is often piped to the standard
       ``less'' pager: ezmlm-list ~/sos | less

   (2) Feeding the results to another program. For example, people have
       shell scripts along the lines of

          #!/bin/sh
          ezmlm-list ~/sos | ( while read sub
          do
            echo ... | qmail-inject -- "$sub"
          done )
       
       to send personalized email to all the subscribers.

Under the IDNA deployment plan, names in the IDNA character encoding
will start showing up in subscription lists immediately. Those names
will be displayed as gobbledygook. The ezmlm-list author will be forced
to have ezmlm-list convert addresses to the local character encoding.

However, if ezmlm-list converts from the IDNA character encoding to the
local character encoding, then the script shown above will break. Mail
will bounce. That's an interoperability disaster.

What is the ezmlm-list author supposed to do? How do we make IDNA work
without encountering this failure?

``Disable the conversion by resetting LANG inside the shell script,''
you say? Yes, we could change the shell script to eliminate the problem.
But that isn't under the control of the ezmlm-list author, and the IDNA
deployment plan doesn't wait for it.

Deliberately screwing up a user's email, and then telling him how to fix
the problem, is not interoperability. It's sabotage.

``Upgrade qmail-inject to support IDNA,'' you say? Yes, I could change
qmail-inject to convert addresses to the IDNA character encoding, and
that would make the script work if the local character set is Unicode
(encoded as UTF-8, presumably). But the IDNA deployment plan doesn't
wait for that either.

There is, of course, no safe order of package upgrades if IDNA is
deployed immediately. For example, addresses are copied from web
browsers to mail programs, and from mail programs back to web browsers.

It's possible to eliminate the interoperability failures by upgrading
_everything_, or by ugprading _nothing_. The problem is the transition.

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