[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> > But these would be pretty darn big temporary problems.
> 
> Most likely overcomable.

"Most likely" ? Don't speculate. Tell me how it could be done without using
some kind of ASCII encoding.

A very significant percentage of the Internet E-mail plumbing that is deployed
today will not pass an 8-bit route-addr without alterering it. I'm tempted to
say it's the majority of the plumbing. Indeed, if an MTA does *not* alter it,
it is violating the current standards. This is exactly what I confirmed by
observation for these Chinese and Japanese sites, never mind my intuition on
the subject.

How do you propose to replace all of that?

With an encoding scheme, none of the transport software has to change at all.
If I want to see the new I18n'd addresses, I need only change my client. If I
don't really care to see the new addresses, that's OK; they'll look funny, but
at least I can use them, save them in my address book, etc.

With raw UTF-8, I still have to change my client. *And* I also have to
convince my management chain to replace the three MTAs that lie between my
server and the public Internet.

> ...but the address one would reply to would be incomprehensible
> giberrish to that user (and anyone else not having that very
> narrow application field converter).  Then at least I would be
> very careful NOT to send that e-mail at all...

An address that started out as UTF-8 and was altered by a relaying MTA will be
incomprehensible gibberish. A UTF-8 address that the recipient's client cannot
display or input will also be incomprehensible gibberish. The difference is
that the encoded address will still work. The other two will not.

Here's a useful experiment: Send yourself a message that has UTF-8 raw in the
route-addr, and has a single text part that is in Latin 1. First, figure out
how to convince your MTA to allow that. (Not hard for some MTAs, damn hard for
others. I used Sendmail 8.9.2.) Now, try to read that message using your favorite client. Examine the results.

Netscape Communicator 4.7 running on Solaris 8 will seg fault.

<csg>