Bruce Lilly wrote:
The MIME RFCs work harmoniously with RFC 822 as every MIME message
is a valid RFC 822 message and every component of MIME header fields
is a valid component of an RFC 822 field
Peter already answered that, and at the time RFC 2045 was published
they knew perfectly well that binary doesn't fly with ordinary SMTP:
| Such data cannot be transmitted over some transfer protocols. For
| example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
| data with lines no longer than 1000 characters including any
| trailing CRLF line separator.
RFC 821/822 and 2821/2822 came as tandems, if all goes well that
will be also the case for 2821bis/2822upd, despite of a premature
2821bis Last Call. Theories about appealing premature Last Calls
(as discussed on the general list) not withstanding.
An ordinary message/rfc822 without MIME magic is by definition in
RFC 2045 US-ASCII (header and body) text/plain (body). MIME gives
us the means to transform anything into this basic pattern, where
MIME-agnostic 7bit software won't know what hit them. And 2822upd
specifies what the "basic pattern" precisely is. MIME only has a
normative 822 reference for this job, and 2822upd will be the new
STD 11 in about two years - if all goes well. (And after that it
makes sense to promote MIME to STD, using 4234bis ABNF, the works)
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.
Please read the original, where the specific ABNF and the reference
to the section where is is located can be found.
"Where" as in "what original" - there's no "7f" or "80" in RFC 3030.
Frank