Bruce Lilly wrote:
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.
This makes me uneasy for several reasons:
1. it bucks the trend at liberalizing body content (e.g. 8BITMIME
and BINARY SMTP extensions).
IMO 2822upd is about message/rfc822 with transmission as SMTP DATA
in mind. It's not about an UTF8SMTP message/global, it's also not
about BINARYMIME BDAT, NNTP message/news, or (arguably) SMTP SEND.
It's possible to transfom BINARYMIME BDAT into message/rfc822 DATA,
and then the 2822upd rules for bare CR and bare LF apply.
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.
2822upd is mostly MIME-agnostic, extensions (the "E" in MIME) need
to say where and under which conditions they derive from the basic
format. Or as 2822upd 1.1 puts it:
| Those mechanisms are outside of the scope of this specification.
2822upd-04 section 4.1 reads in part:
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
A perfectly fine definition of "bare LF" and "bare CR" cases which
could make it without being confused with CRLF. And RFC 3030 has
it clear that BINARYMIME is unsuited for line oriented SMTP DATA.
0x00-0x7f (with no CRLF restriction), but not 0x80-0xff.
Where have you found the US-ASCII restriction ? Excluding half of
the octets would be odd for the purpose of a *binary* transport.