It appears that Sam Varshavchik <mrsam(_at_)courier-mta(_dot_)com> said:
So, what is the answer to the same question, for BINARYMIME? This is mostly
conjecture, but I'd say that email implementations tend to fall into two
broad categories.
CHUNKING and BINARYMIME were in RFC 1830.
RFC 2045 says:
Mail transport for unencoded 8bit data is defined in RFC 1652. As of
the initial publication of this document, there are no standardized
Internet mail transports for which it is legitimate to include
unencoded binary data in mail bodies. Thus there are no
circumstances in which the "binary" Content-Transfer-Encoding is
actually valid in Internet mail. ...
I get the impression that BINARYMIME was a placeholder they threw in
with the hope that some other kind of framing would come along.
Nope. MIME was carefully designed to support both 8bit and binary format. We
briefly considered defining the necessary transport - and in hindsight not doing
so was an error - but back when RFC 1521 and 1522 came out the situation
surrounding 8BITMIME was unclear, so we didn't pursue it. Then other
things got in the way, and it only happened because the voicemail
people wanted to avoid the overhead of base64.
The
advantage of BDAT over DATA for 8BITMIME is pretty modest, and can
even be negative for the implementations that send small 8K BDAT
chunks.
Acutally, the advantages can be quite significant client-side, depending
on your implementation.
The fact that nothing like quoted-unprintable has ever gotten any traction
tells me that even the overhead of base64 vs 8BITMIME isn't something people
care about.
On this we agree. We thought the need to avoid the overhead in voicemail
messages would be sufficient to get BINARYMIME deployed. We were wrong.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp