The new version looks fine. Just a few remaining questions:
NOTE: In certain transport domains, RFC 822 restrictions such as the
+++++++
This may perhaps be confused with the domain name system. Why
not use "protocol" or "mechanism"?
one that limits body-parts to printable ASCII characters may not be in
++++++++++
This may also be misinterpreted. RFC 822 doesn't talk about
"body-parts" but the "body" of a message (section 3.1; the term
is avoided in the ABNF syntax). In addition, MIME doesn't
intend to allow octets > 127 in the header portion of
encapsulated messages (Message/*) or bodyparts (Multipart/*).
It may be better to replace "body-parts" here by "message
bodies" and to add a sentence about where in the message body
the RFC 822 restrictions are retained.
force. (That is, the transport domains may resemble standard Internet
mail transport, but without certain restrictions.) The relaxation of
these restrictions should be construed as locally extending the
definition of body-part, for example to include octets outside of the
+++++++++
If we are talking about the ABNF definitions here, not only
"body-part" but also "discard-text" are extended.
ASCII range, as long as these extensions are supported by the transport
and adequately documented in the Content-Transfer-Encoding header field.
The proposed NOTE uses very cautious language: "RFC 822
restrictions SUCH AS", "extending the definition of body-part,
FOR EXAMPLE to include octets outside of the ASCII range".
Is this really necessary? _RFC 822_ seems to put no other
restriction on the message body than that octets must not
be > 127. I can think of three other restrictions, none of
which is part of RFC 822:
1) Lines may contain a maximum of 1000 octets. (This is an SMTP
requirement.)
2) The character "." is doubled when starting a line. (An SMTP
encoding issue, invisible at the RFC 822 level.)
3) NUL characters can't be included. (An aspect of certain
popular implementations, e.g. sendmail, which contradicts
explicit requirements of both RFC 821, p. 21, 41, and
RFC 822, p. 5, 10, 17.)
Two additional editorial suggestions:
-- In Appendix D, put the definitions of "qp-iffy" and
"discard-text" in proper alphabetical order.
-- In Appendix D, either insert a reference to the NOTE on
relaxing RFC 822 restrictions on bodies or duplicate it.