RE: [idn] Re: An idn protocol for consideration in making the requirements

["Carl S. Gutekunst" <carl.gutekunst@eng.sun.com>]

> And for e-mail those things were really temporary measures anyway, given 
> ESMPT and 8bit.

ESMTP and 8BITMIME only apply to the body of a message. This discussion
pertains entirely to message headers, where there is no support for 8-bit at
all, other than that of RFC2047.

> I'd much rather have some temporary problems with UTF-8 than have
> permanent problems with something that reencodes non-ASCII into ASCII.

Being one who implements Q-P to 8bit "upgrading" on all my mail servers, I
symphathize. But these would be pretty darn big temporary problems.

I conducted some experiments with raw 8-bit data in message header fields a
year or so ago in response to requests from customers in Japan and China.
There were (and are) some native Japanese and Chinese language E-mail clients
that quite happily stuff unencoded Shift-JIS, EUC JIS, Big 5, et al into the
Subject and the phrase fields (but not the route-addr) of addresses.

The results were similar to what we saw with Just-Send-8 a decade ago. As long
as the entire end-to-end path had been carefully managed to specifically
handle these messages, they would be received and displayed correctly. But if
any SMTP relay or client wasn't party to the bilateral agreement, all kinds of
damage happened, including RFC2047 conversions, nonsensical character set
conversions, seemingly random mangling, 8-bit truncation, and non-deliveries.
(And I'm *not* including untagged charset mismatches, which would not be an
issue if we used UTF-8 exclusively.)

> In a transition phase (or permanently, if desired) I see no
> real problem in having two or more names for the same domain,
> one of which had to be in ASCII.  People could then say "...if this
> domain/e-mail address does not work, try this one instead...".

So what you are proposing is exposing transitional end users to ugly addresses
that aren't replyable, forcing them to cut and paste a replyable address from
somewhere else. The alternative is to expose transitional end users to ugly
addresses, but the "reply" button still works just fine.

<csg>