The last thing I want is to create a state where a MIME mail reader
doesn't know what to do with BINARY, because it might have been
translated from ascii to ebcdic (or vice versa), or it might have
been preserved.
A gateway that translates out of ascii must record that fact in the
headers, either by changing the character set notation, [...]
Not necessarily. Just because the transport character set has changed,
does not imply that the character set of an encoded body part has changed.
or by removing the
MIME info altogether if it is in fact not producing valid MIME messages on
the other side.
That seems reasonable. But a present-day ascii<->ebcdic gateway does
produce valid MIME messages on the other side, UNLESS the message
contains BINARY c-t-e's.
(If you read MIME strictly, this isn't true, because MIME refers to CRLFs
and other things which assume an ASCII world. On the other hand, there are
very few UAs which strictly conform to MIME in this respect, because of the
need to be compatible with pre-existing mailbox formats.)
It is not correct to assume that BINARY is at least as safe as 7bit/8bit
for the transfer of text files with long lines.
Unfortunately, it is EXPLICITLY ILLEGAL to send text with long lines under
a CTE of 7bit or 8bit. (I remember you saying you thought maybe it
shouldn't be, but it currently is.)
Understood. When I look at what happens if we start using BINARY for this
purpose, I conclude that we need to change MIME to allow 7bit/8bit to be
used with long lines. It's far easier to make the change to MIME than it
is to upgrade the email infrastructure to handle BINARY. The latter is
also desirable, of course, but it will take a long time.
Keith