[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Debunking the ACE myth



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