[idn] =?UTF-8?B?UkU6IFtpZG5dIFJlOiBBbiBpZG4gcHJvdG9jb2wgZm9yIGNvbnNp?==?UTF-8?B?ZGVyYXRpb24gaW4gbWFraW5nIHRoZSByZXEgdWlyZW1lbnRz?=

[=?UTF-8?B?S2FybHNzb24gS2VudCAtIGtla2E=?= <keka@im.se>]

> -----Original Message-----
> From: Carl S. Gutekunst [mailto:carl.gutekunst@eng.sun.com]
...
> > > 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.

Maybe we don't mean the same thing by "overcome".  I don't mean
'magically work', I mean: 'After some software updates it will work
(not be rejected) more and more often, until it works always.  In
the meantime use fallbacks when needed'.  The fallback I'm thinking
about here is to use (parallel, not reencoded ones) ASCII domain
(and user) names in the e-mail addresses (and to use MIME-headers
where applicable otherwise, rather than "raw" UTF-8).

After all, at least I, and many here (who wish to be able to read
messages in Swedish), have had to do upgrades to e-mail (client)
software about twice a year (less often for the server software),
just to get it to work better (i.e. overcome bugs).  New supplier,
new bugs, new stair of bug reports and upgrades.


It would mean that one need to keep track of fallback addresses for 
some time, and probably use only the fallback addresses initially,
until the 'proper' addresses gradually start working.

Some email clients may help with that, and find a substitute target
address in ASCII by asking the DNS for a main name (in ASCII) from
the given UTF-8 (but non-ASCII) name if (for now hypothetical)
ESMTP/UTF8HEADERS is not available. (But maybe I'm exposing my
naïvité on how email works...)

And again, I don't worry much about servers (MTAs) that would 'fall
over and die' because of '8-bit' in headers.  Those would be too
vulnarable to attack to be in continued use anyway.


> A very significant percentage of the Internet E-mail plumbing 
...
> How do you propose to replace all of that?

Not all at once obviously.  But ESMTP (with as yet only two extensions)
has replaced SMTP.  Assuming that an ESMTP/UTF8HEADERS extension
is drafted and approved, that extension could (and would, I hope)
be implemented and gradually deployed.


> 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.

But those "internationalised" addresses will have completely defied
their purpose, and will continue to leak out in their reencoded form
forever since their (re)encoding is one with (forever!) very narrow
application. UTF-8 (and UTF-16) on the other hand, will be very
close to ubiquitous *within* foreseeable time.


		Kind regards
		/kent k

PS
I'll send this message in UTF-8; which implies that it gets the
(UTF-8, or in this case ASCII really) subject line reencoded in BASE64.