Re: [idn]=?UTF-8?B?UkU6IFtpZG5dIFJFOiBbaWRuXSBSZTogQW4gaWRuIHByb3RvY29s?==?UTF-8?B?IGZvciBjb25zaWRlcmF0aW9uIGluIG1ha2luZyB0aGUgcmVxIHVpcmVtZW50?==?UTF-8?B?cw==?=

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

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

An occasional non-decode of a header string doesn't lose mail. What you
originally proposed will.

Terminology aside, I see these outcomes as totally different. And I suspect
that the vast majority of users do as well. And the IETF process most certainly
sees these outcomes as different -- one is an implementation problem and not a
standards problem at all, the other is an interoperability problem that our
process forbids on the standards track.

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

That's your opinion, and of course you are entitled to it. But speaking as
someone who's been doing this stuff for a long time, I caution you against
saying things like this or that is totally unacceptable where the underlying
basis of that opinion is apparently that you find the result aesthetically
unpleasant. This is especially true this early in the game. Aesthetic
unpleasantness is sometimes a necessary evil, and by taking an absolutist
position early on that such solutions aren't viable may not be the best thing
strategically.

Please note (again) that I don't yet have an opinion as to which way this
should go. I good and bad sides to both types of proposals. The only things I
find unacceptable at this point are ones that cause major interoperability
problems and hence are forbidden by our process. (To say nothing of the
eventual outcome on the network at large, which history has shown isn't good
when the installed base has to change completely.)  I see no point in spending
lots of time developing something that is unlikely to reach consensus and has
no chance of making it past the IESG.

Now, on the aesthetic level I don't like UTF-5 or anything similar at all. And
I doubt if Paul or anyone else who has proposed such solutions does either. But
I'm prepared to accept, however reluctantly, an outcome where such solutions
turn out to be the best from an operational/implementation/interoperability
standpoint.

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

That's what I'm hearing now, not what I heard before. But let me be blunt: Your
continually repeating that this or that is unacceptable to you isn't
accomplishing anything. What you need to be doing is working on a proposal that
you do find acceptable and which addresses interoperability and backwards
compatibility concerns.

You seem to think that this fallback strategy is just going to magically
appear as long as you keep objecting to the proposals you don't like.
Sorry, the process doesn't work that way.

				Ned