[Top] [All Lists]

Re: Comment on the draft MIME Part 1 document

1993-04-28 03:56:01
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

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.