[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Debunking the ACE myth
-----BEGIN PGP SIGNED MESSAGE-----
"Adam M. Costello" wrote:
> "D. J. Bernstein" <djb@cr.yp.to> wrote:
>
> > > I don't see how this is an ACE failure.
> >
> > You don't see that it's a failure? Or you don't see that the
> > procedure succeeds if the ACE IDN is replaced by a normal domain name?
>
> Of course it's a failure, but it's not an ACE failure, it's an IDN
> failure. The exact same failure would happen for any IDN in this
> scenario regardless of whether ACE existed or not.
No - it works for just-send-UTF8 (which I assume is Dan's point [*]),
and it also works for ACE + UTF-8 proposals in which either an ACE or a
UTF-8 name can be passed to the resolver (including IDN-8). IDN-8 pays
great attention to fixing some other types of cut and paste failure as
well; I consider any proposal where cut and paste doesn't work properly
to be seriously deficient.
[*] I don't agree with Dan that just-send-UTF-8 is an acceptable solution,
but I do certainly agree that ACE-only proposals are not.
> But there are other scenarios (like replying to a message, which is
> even more common than cutting and pasting addresses) where ACE will not
> fail, and any other encoding might (often would, given the popularity of
> sendmail and BIND).
IDN-8 will work with sendmail and BIND. (I'll describe the details in
another post; please bear with me on that.)
> It's undeniable that ACE is more backward-compatible, and fails in fewer
> instances, than any 8-bit encoding.
Encodings don't succeed or fail; proposals do. So, which ACE proposal?
It isn't true in general that proposals using ACE as the primary encoding
fail in fewer instances than proposals where UTF-8 is preferred. IDNA, for
example, fails in some cases where IDN-8 works, including the example
given by Dan, and including any other situation where a UTF-8 name leaks
to an application using ACE. (Note that UTF-8 will be a very commonly used
character encoding - probably *the* most common - regardless of which
proposal is adopted, so it is impossible to completely prevent such leakage.)
If you count displaying an ACE name to a human user as a failure (which
I do, although it is less serious than a lookup failure), then ACE-only
proposals fail in many more cases.
- --
David Hopwood <david.hopwood@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBO1ZWYjkCAxeYt5gVAQF6Hgf+O/z/PThOO8UIDqtdf/kuTtTOhDk+nw6e
GyRKSy0YSSQ6yx7t5W0xFhw93ikeR2Yk5/GaQpr95h2wmfgzgWv7nmuGpkh3vRuJ
mqezObIQZraFXzfhJpsHt70JrMnZDYwoHO8lGkmN896cTMyl20KX5Dh5YOw+Cdjb
qPMyzfAwYOgiibWqVrRpaVhG80XNO1rZw41grJPcseZPtlhMQdh3Kxhc5cLmUpcY
+MMb401ZYwwn1L/yfW/JDGhOUwnyhxKIxQ4KI+lZR8qNwMb2Ecowfq/KKkiXeU/d
eduBwvZ+KDjGdEnwFCLJq77DeQMt+CpOS1JuzWTBsU+h/j8EWs/z3A==
=dPBw
-----END PGP SIGNATURE-----