2822upd-04 section 2.3 reads in part:
o CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
I, OTOH, think this is exactly what 2822bis should say. (As a side note, I'm
quite unhappy with 2821bis's handling of bare CR and LF, in particular the rule
that they MUST NOT be treated as line terminators under any circumstances flies
in the face of considerable operational experience and sometimes puts
intermediaries in an impossible position, but I put up with it because it does
reflect the consensus DRUMS reached.)
This makes me uneasy for several reasons:
1. it bucks the trend at liberalizing body content (e.g. 8BITMIME and BINARY
SMTP extensions).
That's just a matter of layering/timing. MIME extends these specifications
to allow stuff that used to be prohibited.
I note in passing that only binary MIME gets you to a place where bare CR and
LF are allowed without encoding. The extension 8bitMIME makes to 2822 is
allowing 8bit.
2. it (together with the disclaimer that appears further down the page)
implies that MIME messages do not conform to the IMF specification,
which is counter to the intent of MIME.
8bitMIME and binary MIME messages don't conform and it is pointless to pretend
otherwise.
3. the use of RFC 2119 terms implies that MIME messages used with extended
SMTP transport cannot interoperate; that impugns a great deal of careful
work to ensure that ESMTP negotiation and MIME are backward-compatible.
I'm not sure I fully understand what you're saying but I'm pretty sure I
disagree.
The way these specifications are layered on top of one another is a complex
compromise that attempts to balance the need for backwards compatibility and
not declaring old implemenations to be invalid with the need to be able to move
forward with stuff thqt wasn't envisioned when the antecedants to these
specifications where first created. It is ugly in places? You bet! And there's
no doubt this makes some people uncomfortable.
But validation of the approach lies in the results it has produced. MIME is now
widely deployed - although I have no proof, my sense is that the majority of
email handling software in use today supports it. Contrast this with previous
attempts at multimedia mail, none of which deployed to any significant degree
even though the network was smaller and simpler at the time and hence more
amenable to change. And while there's no way to be sure to what extent MIME's
focus on backwards compatibility helped in getting it deployed, there is
anecdotal evidence that it was an important factor.
Moreover, the actual confusion this approach has caused (and please remember
that when people have questions about MIME my email address in RFC 2045 is the
only one that still works) seems to have been pretty minimal. I'm all for
solving problems, but I don't think think there's a real problem here.
Ned