The following diagram may be helpful:
2002 2003 2004 2005 2006
+----------+----------+----------+----------+----------+
ACE A|**********|**********|********* |******** |****** |
B| | | | | |
C|XXXXXXX |XXXXXXXXXX|XXXXXXXX |XXXXXX |XXXX |
+----------+----------+----------+----------+----------+
UTF-8 A|****** |*** |* | | |
B|XXX |XX | | | |
C|XXXX |XXX |X | | |
+----------+----------+----------+----------+----------+
The X's represent mail reply failures: row B for built-in replies, row C
for copy-and-paste. The *'s in row A represent annoying IDN displays.
All the numbers are guesses; we need further analysis.
The ACE myth is that there are no X's in the ACE boxes. What's true is
that there are no X's in row B in the ACE boxes.
Adam M. Costello writes:
> But you agree that ACE will
> break fewer things in the beginning than an 8-bit encoding
Fewer procedures, yes---fewer lines in the above picture---but this
doesn't necessarily mean that the _number_ of failures will be smaller,
even if you look only at the 2002 box. Count the X's!
What you're neglecting to take into account this time is that UTF-8
support is already far past ``the beginning.'' That's why the rows of
X's for UTF-8 are relatively short.
Many programs can send mail to UTF-8 addresses, for example. They'll
work fine in the copy-and-paste situation I described, if we use UTF-8
IDNs rather than ACE IDNs.
---Dan
