At 5:17 PM 10/28/94, Keith Moore wrote:
But an ascii to ebcdic gateway is not necessarily a MIME to non-MIME
gateway.
Didn't say it was.
It might instead be a MIME-aware gateway from an environment
capable of supporting binary c-t-e's, to one that is not capable of
supporting binary c-t-e's. In such a case the thing to do would be
to convert binary to base64.
Sure.
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, or by removing the
MIME info altogether if it is in fact not producing valid MIME messages on
the other side.
I do not see any uncertainty.
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.)
So the legal choices currently are to encode in qp or base64, or to
"encode" in "binary". For MIME systems, qp or base64 are clearly superior,
and that's what the user should choose. For non-MIME systems, binary may
be the only thing that works.
The sames sort of user who pages Rick Troth at 2am because they didn't get
ASCII changed to EBCDIC is likely to page somebody else at 2am because they
don't know why their data was "corrupted" with "equals signs".
--
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."