Re: [idn] Debunking the ACE myth

[Keith Moore <moore@cs.utk.edu>]

> > > Give me one example where it fails. Just one.
> > 
> > I'll give two.
> 
> You gave me two application failures, not protocol failures.

delivering to a file is a protocol.  not all protocols involve
direct interaction between the producer and the consumer.
 
> > 1. an email message gets delivered to a flat file which is read by
> > a user agent.  the process that delivers the message has no idea
> > whether the user agent can support native IDNs or not, and this
> > is subject to change at any time.
> 
> You're assuming that the headers won't have to signify content, and that
> the SMTP folk won't consider this in protocol design. Considering the
> store-and-forward nature of mail, this is absurd.

Considering the store-and-forward nature of mail, it's absurd to think
that you can use message headers for interactive feature negotiation.

> > 2. an HTML document is saved in a flat file on a disk.  the process
> > that saves the file has no idea whether every browser that will ever
> > be asked to read that file can properly support IDNs.
> 
> Compliant HTML has a version tag.

Version tags don't help if the browser doesn't understand the version.
(we realized that MIME-Version was essentially useless only after
RFC 1341 made it mandatory.  by the time we realized this, it was
too late to deprecate it - too many UAs refused to recognize MIME without it.)

> > on-the-fly format conversion adds it own set of problems.
> 
> Such as?

It introduces errors that are difficult to trace and to fix.
It adds complexity (for example into MTAs) that shouldn't be
modifying their payloads.  It forces intermediaries to be aware
of their payloads' formats when those formats should be transparent.

Keith