unrecognized subtype.

   As stated in the definition of the Content-Transfer-Encoding field,
   no encoding other than "7bit", "8bit", or "binary" is permitted for
   entities of type "multipart".  The multipart delimiters and header
   fields are always represented as 7-bit ASCII in any case (though the
   header fields may encode non-ASCII header text as per [RFC-1522]),
   and data within the body parts can be encoded on a part-by-part
   basis, with Content-Transfer-Encoding fields for each appropriate
   body part.

   Mail gateways, relays, and other mail handling agents are commonly
   known to alter the top-level header of an RFC 822 message.  In
   particular, they frequently add, remove, or reorder header fields.
   Such alterations are explicitly forbidden for the body part headers
   embedded in the bodies of messages of type "multipart."

7.2.1.     Multipart:  The common syntax

   All subtypes of "multipart" share a common syntax, defined in this
   section.  A simple example of a multipart message also appears in
   this section.  An example of a more complex multipart message is




 
RFC 1521                          MIME                    September 1993


   given in Appendix C.

   The Content-Type field for multipart entities requires one parameter,
   "boundary", which is used to specify the encapsulation boundary.  The
   encapsulation boundary is defined as a line consisting entirely of
   two hyphen characters ("-", decimal code 45) followed by the boundary
   parameter value from the Content-Type header field.

      NOTE: The hyphens are for rough compatibility with the earlier RFC
      934 method of message encapsulation, and for ease of searching for
      the boundaries in some implementations. However, it should be
      noted that multipart messages are NOT completely compatible with
      RFC 934 encapsulations; in particular, they do not obey RFC 934
      quoting conventions for embedded lines that begin with hyphens.
      This mechanism was chosen over the RFC 934 mechanism because the
      latter causes lines to grow with each level of quoting.  The
      combination of this growth with the fact that SMTP implementations
      sometimes wrap long lines made the RFC 934 mechanism unsuitable
      for use in the event that deeply-nested multipart structuring is
      ever desired.

   WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
   type field is such that it is often necessary to enclose the
   boundaries in quotes on the Content-type line.  This is not always
   necessary, but never hurts.  Implementors should be sure to study the
   grammar carefully in order to avoid producing illegal Content-type
   fields. Thus, a typical multipart Content-Type header field might
   look like this:

                 Content-Type: multipart/mixed;
                      boundary=gc0p4Jq0M2Yt08jU534c0p

   But the following is illegal:

                 Content-Type: multipart/mixed;
                      boundary=gc0p4Jq0M:2Yt08jU534c0p

   (because of the colon) and must instead be represented as

                 Content-Type: multipart/mixed;
                      boundary="gc0p4Jq0M:2Yt08jU534c0p"

   This indicates that the entity consists of several parts, each itself
   with a structure that is syntactically identical to an RFC 822
   message, except that the header area might be completely empty, and
   that the parts are each preceded by the line

                 --gc0p4Jq0M:2Yt08jU534c0p




 
RFC 1521                          MIME                    September 1993


   Note that the encapsulation boundary must occur at the beginning of a
   line, i.e., following a CRLF, and that the initial CRLF is considered
   to be attached to the encapsulation boundary rather than part of the
   preceding part.  The boundary must be followed immediately either by
   another CRLF and the header fields for the next part, or by two
   CRLFs, in which case there are no header fields for the next part
   (and it is therefore assumed to be of Content-Type text/plain).

      NOTE: The CRLF preceding the encapsulation line is conceptually
      attached to the boundary so that it is possible to have a part
      that does not end with a CRLF (line break). Body parts that must
      be considered to end with line breaks, therefore, must have two
      CRLFs preceding the encapsulation line, the first of which is part
      of the preceding body part, and the second of which is part of the