With existing software, users often encounter failures when they try to
use non-ASCII characters. Example: a user types an alpha, and it shows
up as an empty box, rather than an alpha, on another user's screen.
To make non-ASCII characters work, we're going to have to change some
software. There are many strategies for doing this, and they have
different costs. For example:
* We can support UTF-8 everywhere. This means changing quite a bit
of code in pine, sendmail, etc., and doing a massive upgrade.
* We can use GoofyCode in various places. This means changing even
more code in pine, sendmail, etc.; changing code in many programs
that already work with UTF-8; and doing a far more massive upgrade.
A different strategy is to run in terror from the prospect of a massive
upgrade---to pretend that non-ASCII support is merely an option. This is
the strategy that the GoofyCode proponents are talking about when they
claim that GoofyCode doesn't demand any upgrades. Of course, this
strategy also fails to make non-ASCII characters work.
Notice that Crispin is complaining about, e.g., the ``implications in
GUI programs and screen editors'' of the fact that ``one screen space''
is sometimes encoded as more than ``one byte.'' This is true for UTF-8,
GoofyCode, and all other Unicode encodings. Crispin simply doesn't want
to support non-ASCII characters!
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago