> -----Original Message-----
> From: ned.freed@innosoft.com [mailto:ned.freed@innosoft.com]
...
> Upgrading software to fix a bug or two is one thing, having to upgrade
> software so it works at all is quite another.
Ned,
I consider occational or systematic non-decode of QP or BASE64
in e-mail to be a bug of the nature "does not work". (We probably
mean different things by "works", you and I.)
...
> As an example of a possible fallback strategy, suppose we add
> a new fallback
> record to the DNS that translates a UTF-8 name to an
> equivalent ASCII name. An
> MTA that receives a UTF8HEADER message could then, if it had
> to, translate the
> 8bit domain names to a fallback names. This is not
> appreciably worse than
> 8bitMIME in terms of implementation complexity. But it
> absolutely does require
> support in the IDN proposal to make it work. And the addition
> of a new record
> type is likely to take a while to deploy. But eventually, should
> UTF8HEADER-capable software come to dominate, the fallback
> records could be dispensed with.
Except possibly for details, I'd be happy to go along with a
fallback scheme of some kind, as long as the longterm goal
(but the sooner the better) that domain names (and 'mailbox'
names) are in a commonly available plain text encoding that
is globally viable. By this I exclude things like BASE64,
QP, UTF-7, UTF-5, and anything that reencodes non-ASCII into
ASCII. The only contenters are UTF-8, UTF-16, and SCSU.
But the latter has uniqueness problems, and isn't as accepted
as the two first ones, and is in addition stateful.
Permanently targeting a reencoding into ASCII (like CIDNUC
or UTF-5) is completely unacceptable from my point of view.
If that is the end result of this WG, I would consider this
WG to have failed and only come up with a problematic cludge
that defies the intent of internationalisation.
> Now compare this with the 7bit proposals. In such cases user
> gratification is immediate;
No, it is not. Instead the user problems are immediate *and
permanent*. These proposals defy the intent of internationalisation.
> you can register international domain names right
> off
No, but you can register gibberish right off, gibberish that
will initially not be decoded, gibberish that will for a long
time not be decoded, gibberish that will forever sometimes be
non-decoded, gibberish that will continue forever to pose
user problems. Perhaps not "protocol problems"; but I am more
concerned with the users and actual internationalisation.
> and have
> them work and people can upgrade their display software (or
> not) any time
> they want. But the underlying mechanisms are ugly now and
> stay that way
> forever.
>
> Again, I'm not advocating either 7bit or 8bit DNS entries.
> Personally, I'm
> neutral on the subject. But what I'm hearing is "just use
> UTF-8",
From me you are hearing: "Target UTF-8 (or UTF-16BE), and please
use some fallback stragegy during a transition period". I'm
not being at all specific about how long that transition period
might be. It might be permanent if the fallback strategy works
well, and that UTF-8 (or UTF-16BE) works for most, if not all,
'end users'.
I may be fumbling about what that fallback strategy
might be, but I would not consider that I'm fumbling about what
the target is from an end user's point of view. I know, most end
users will not know about UTF-anything, but it is important that
no reencodation (like CIDNUC or UTF-5) ever surfaces. The CIDNUC
proposal leaks reencoded names like a bottomless bucket, and is
therefore unacceptable, as I see it.
Parallel (not reencoded, but selected by a human) domain names
are fine during the (semi-permanant) transition. If they can be
mapped back to the parallel but internationalised name at the
other end (concerning e-mail) that would be an added bonus.
Kind regards
/kent k