In general, mail-sending software must always use the "lowest common
   denominator" character set possible.  For example, if a body contains
   only US-ASCII characters, it must be marked as being in the US-ASCII
   character set, not ISO-8859-1, which, like all the ISO-8859 family of
   character sets, is a superset of US-ASCII.  More generally, if a
   widely-used character set is a subset of another character set, and a
   body contains only characters in the widely-used subset, it must be
   labeled as being in that subset.  This will increase the chances that
   the recipient will be able to view the mail correctly.




 
RFC 1521                          MIME                    September 1993


7.1.2.     The Text/plain subtype

   The primary subtype of text is "plain".  This indicates plain
   (unformatted) text.  The default Content-Type for Internet mail,
   "text/plain; charset=us-ascii", describes existing Internet practice.
   That is, it is the type of body defined by RFC 822.

   No other text subtype is defined by this document.

   The formal grammar for the content-type header field for text is as
   follows:

   text-type := "text" "/" text-subtype [";" "charset" "=" charset]

   text-subtype := "plain" / extension-token

   charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"
          / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"
          / "iso-8859-8" / "iso-8859-9" / extension-token
                    ; case insensitive

7.2.  The Multipart Content-Type

   In the case of multiple part entities, in which one or more different
   sets of data are combined in a single body, a "multipart" Content-
   Type field must appear in the entity's header. The body must then
   contain one or more "body parts," each preceded by an encapsulation
   boundary, and the last one followed by a closing boundary.  Each part
   starts with an encapsulation boundary, and then contains a body part
   consisting of header area, a blank line, and a body area.  Thus a
   body part is similar to an RFC 822 message in syntax, but different
   in meaning.

   A body part is NOT to be interpreted as actually being an RFC 822
   message.  To begin with, NO header fields are actually required in
   body parts.  A body part that starts with a blank line, therefore, is
   allowed and is a body part for which all default values are to be
   assumed.  In such a case, the absence of a Content-Type header field
   implies that the corresponding body is plain US-ASCII text.  The only
   header fields that have defined meaning for body parts are those the
   names of which begin with "Content-".  All other header fields are
   generally to be ignored in body parts.  Although they should
   generally be retained in mail processing, they may be discarded by
   gateways if necessary.  Such other fields are permitted to appear in
   body parts but must not be depended on.  "X-" fields may be created
   for experimental or private purposes, with the recognition that the
   information they contain may be lost at some gateways.





 
RFC 1521                          MIME                    September 1993


      NOTE: The distinction between an RFC 822 message and a body part
      is subtle, but important. A gateway between Internet and X.400
      mail, for example, must be able to tell the difference between a
      body part that contains an image and a body part that contains an
      encapsulated message, the body of which is an image.  In order to
      represent the latter, the body part must have "Content-Type:
      message", and its body (after the blank line) must be the
      encapsulated message, with its own "Content-Type: image" header
      field.  The use of similar syntax facilitates the conversion of
      messages to body parts, and vice versa, but the distinction
      between the two must be understood by implementors.  (For the
      special case in which all parts actually are messages, a "digest"
      subtype is also defined.)

   As stated previously, each body part is preceded by an encapsulation
   boundary.  The encapsulation boundary MUST NOT appear inside any of
   the encapsulated parts.  Thus, it is crucial that the composing agent
   be able to choose and specify the unique boundary that will separate
   the parts.

   All present and future subtypes of the "multipart" type must use an
   identical syntax.  Subtypes may differ in their semantics, and may
   impose additional restrictions on syntax, but must conform to the
   required syntax for the multipart type.  This requirement ensures
   that all conformant user agents will at least be able to recognize
   and separate the parts of any multipart entity, even of an