Re: [idn] Transparent vs. ACE representations (was We are

["Eric A. Hall" <ehall@ehsco.com>]

quibbling about WHAT?)
Date: Thu, 9 Aug 2001 09:04:29 -0500
Organization: EHS Company
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> >Suppose for the sake of argument that the message had contained
> >characters outside the US-ASCII repertoire (in a domain name or
> >elsewhere).
>
> If the text switches from one character set to another, then no, it is
> unlikely the processing software will handle that well.

Exactly. Text that contains UTF-8 IDNs is likely to be stored as an
UTF-8 body part. Conversely, text that contains ACE IDNs (which must be
transliterated) is not likely to be stored as an ACE body part since ACE
is not suitable for MIME.

> The real point is that you appear to be assuming a much more
simplified
> and  consistent processing environment for characters, across
> applications, than  actually exists.

Conversely, you appear to be assuming that everybody will want to write
ACE-exception-handling code that scans through body parts, tries to find
a string that looks like ACE, transliterate it, and redisplay the body
part. Give me a break.

Think about this: nobody will be able to explain how ACE works over
email. Everytime you give an example, the software transliterates it. Oh
so now we need exception handling for the exception handling.

ACE is needed for backwards compatibility. That is totally separate from
whether or not it is useful or usable or good for future usage models.
You shouldn't get them confused.