At 3:32 PM -0700 7/25/97, Jamie Zawinski wrote:
For what it's worth, Netscape is one of those MUAs that can't cope with
"Content-Transfer-Encoding: binary". Our MIME parser is line-oriented,
and treats unencoded CR, LF, and CRLF synonymously. It would be a lot
of work to make it able to handle binary MIME parts.
This applies to both MIME and S/MIME objects; if an encrypted or
opaque-signed S/MIME message has unencoded binary data inside it,
that message won't be decoded properly.
Well, then your implementation isn't conformant anyhow. From the first
paragraph of Section 3.1.2, which is talking about inside parts:
"When generating any of the secured MIME entities below, except the
signing using the multipart/signed format, no transfer encoding at all
is required. S/MIME implementations MUST be able to deal with binary
MIME objects. If no Content-Transfer-Encoding header is present, the
transfer encoding should be considered binary."
I believe that the debate here is about outside parts, and whether the use
of application/mime allows an outside part to be binary. It sounds like I
should add a sentence to 3.4.2.4 saying that application/mime messages
should already be in 7bit format, but if it isn't, it needs a c-t-e of
base64 or quoted-printable.
--Paul E. Hoffman, Director
--Internet Mail Consortium