Date: 21 Oct 1996 21:10:00 +0200
From: kai@khms.westfalen.de (Kai Henningsen)
To: drums@cs.utk.edu
Message-ID: <6JGUvZWUcsB@khms.westfalen.de>
In-Reply-To: <3520.845775153@dale.uninett.no>
Subject: Re: About that 8-bit discussion.....
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.

klensin@mail1.reston.mci.net (John C Klensin)  wrote on 21.10.96 in <SIMEON.9610210335.D@white-box.mail1.reston.mci.net>:

> I believe that inserting this language, or anything vaguely
> equivalent to it, will be taken by substantially everyone who
> believes that "'just send 8bit' almost always works anyway" and/or
> who find the concept of having to downgrade to convert to Q-B or
> Base64 to be not worth the trouble as legitimizing the "just
> send 8" philosophy.  What you would see is "well, I sent
> things over an 8bit clean channel (almost everything is these
> days) and the RFC says that a conforming recipient should
> accept it, and receivers are supposed to be robust about what they
> accept anyway, so, if the message gets trashed, it is the
> receiver's fault and it is out of conformance".
>
> I don't believe that tuning language will help with that,
> either.

Well, it's a reasonable expectation to begin with, that's the trouble.

After all, the reason why it doesn't work that way amounts to "well, we  
made a stupid[1] mistake in the beginning, and now we can't fix it because  
too many programs implemented that mistake".

Personally, I can see no justification not to try to correct that mistake.

IMNSHO, the question is not whether we try to get SMTP 8-bit-clean, but  
only how we do it.

What is the "far future" goal? I think it is approximately as follows:

* just-send-8 will work
* there will be a convention on how to interpret non-ASCII chars in  
headers


So, how to get there from here?

IMHO, as follows:

* Require any 821bis-compatible MTA to be 8 bit clean. That is, either  
pass it on unchanged, or MIME it (probably with qp), or bounce it; *never*  
simply delete the 8th bit.

* Explain that there are *a lot* MTAs around that are compatible to 821,  
not 821bis; that 821 is broken for anything outside 7 bit; that MIME is  
the way to get around that while they are still around; and that absent  
MIME, it won't be clear how to interpret those chars anyway.

* Further, say that a future version of this standard will require passing  
it on unchanged, once this is feasible, and once there is a global  
agreement on how to interpret those chars.

Yes, this needs a lot of text.

MfG Kai


[1] Yes, it *was* a stupid mistake. Even when the Internet was still young  
and called the Arpanet, there was absolutely no reason to keep a protocol  
built on top of TCP to 7 bits and reserve a parity bit.