MIME "8bit" have serious interoperabilitty problem, then.
Not at all. "C-T-E: 8bit" simply states "this message body contains
short lines of 0-255". I don't think there's any ambiguity in RFC-1521:
a conformant UA receiving such a message will handle it correctly.
Before sending a message, you (or your UA) must decide which C-T-E to
use, based on the contents of the message, and the transports available.
If there is a transport available which can handle short lines of
0-255, then it may be appropriate to use "8bit". (Conforming RFC-1652
implementations are an example of such a transport.)
It may be the case that you only have transports available which handle
1-255. If so, you should not use "8bit" if the message body contains
NUL characters. (There is no such Internet standard transport.)
If a transport claims to be RFC-1652 conformant, but can only handle
1-255, it is broken. It *may* be the case that this breakage mode
is (or will be) extremely common, in which case it *may* be wise for
a careful UA never to use "8bit" when the message body contains NUL
characters.
We don't yet know whether this, or any other, particular mode of
RFC-1652 non-conformance will be common. If it is, then a future
version of MIME might provide a way to work around it, just as the
current MIME provides ways to work around known problems with existing
transports.
The interoperability problem, if there is one, is not with MIME, nor
with ESMTP, but with software which does not conform to the standards.
It's completely unreasonable to try to retroactively change the "8BIT"
content-transfer-encoding to mean something different than was originally
intended.
Then, I propose to remove "8bit" CTE, because of the original brain-dead
intention.
I wasn't around at the time, but I believe the main intent of "8bit"
was to provide an easier upgrade-to-MIME path for those people who were
already using 8bit characters sets and "just-sending-8". For these
people, the point is moot: the NUL character is not significant in the
character sets, so it doesn't make any difference whether the transport
can handle it or not.
In practice, it seems unlikely that anything which is not 8bit text will
fulfill the requirement of short lines, so I think that in the real
world it will continue to be moot.
Tim.