Re: 2822upd-04 body content restrictions

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