[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Debunking the ACE myth
- To: idn@ops.ietf.org
- Subject: Re: [idn] Debunking the ACE myth
- From: "D. J. Bernstein" <djb@cr.yp.to>
- Date: 19 Jul 2001 03:33:41 -0000
- Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise.
- Mail-Followup-To: idn@ops.ietf.org
Adam M. Costello writes:
> The exact same failure would happen for any IDN in this scenario
Right! That's the whole point. IDNs, including ACE IDNs, aren't safe to
deploy until the software upgrade is complete.
The ACE myth is that ACE IDNs are safe. In fact, people who try using
ACE IDNs in the short term will encounter failures. You keep complaining
about this aspect of UTF-8 IDNs; but it's true for ACE IDNs too.
(By the way, all the programs I have in mind already handle UTF-8 IDNs.
But I agree that there are other programs that need upgrades.)
> It's undeniable that ACE is more backward-compatible, and fails in fewer
> instances, than any 8-bit encoding.
Actually, that claim requires a careful analysis.
What you're neglecting to take into account is that ACE is substantially
more expensive to deploy than UTF-8. See http://cr.yp.to/proto/idn.html.
ACE requires many more programs to be changed.
I agree that short-term deployment of ACE IDNs would break _fewer_
existing procedures than short-term deployment of UTF-8 IDNs. But those
procedures will be broken for _longer_ with ACE.
You were claiming before that ACE wouldn't cause any failures. ``Nothing
will actually break,'' you said. So you could ignore the question of how
long the ACE upgrade would take; zero times anything is zero. However,
without the ACE myth, the analysis is substantially more difficult.
---Dan