>> I see no reason to not extend the de-facto 8-bit-transparency we
>> already mostly have for body text to header text as well.

> There are two very good reasons -- MIME & ESMTP.

Neither of these is a reason to _not_ support 8-bit transparency for
those who prefer it to MIME-style uglification.  With MIME-aware UAs on
either end, it doesn't matter whether the MTA channel is 8-bit-clean or
not.  And I can't see what ESMTP has to do with it, except that it
provides a way for servers to advertise that they are in fact
8-bit-clean.  (Unfortunately the relatively widespread presence of
servers that are 8-bit-clean at least for data but do not advertise
this in any way means there is no effective way for clients to tell
whether a server is clean or not.)

> Nobody need ever do 8-bit SMTP and hope for some "out-of-band
> agreement on the char set."

Need, no, true.  One can always just uuencode the whole bleedin' thing.
None of this is reason to not support a fully 8-bit-clean channel.

> We have every reason to tromp out the ill-advised 8-bit transparency
> (and boy do I mean transparency) afforded by older SMTP servers.

We do?  I haven't seen any yet.  A clean MTA will support all three
paradigms: old ASCII-only messages, direct-8-bit messages, and
MIME-uglified messages (presumably sent only between consenting UAs).
Destroying the transparency will lose the second of these with no
compensating benefit I can see.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D