Appendix A -- Minimal MIME-Conformance

   The mechanisms described in this document are open-ended.  It is
   definitely not expected that all implementations will support all of
   the Content-Types described, nor that they will all share the same
   extensions.  In order to promote interoperability, however, it is
   useful to define the concept of "MIME-conformance" to define a
   certain level of implementation that allows the useful interworking
   of messages with content that differs from US ASCII text.  In this
   section, we specify the requirements for such conformance.

   A mail user agent that is MIME-conformant MUST:

      1.  Always generate a "MIME-Version: 1.0" header field.

      2.  Recognize the Content-Transfer-Encoding header field, and
      decode all received data encoded with either the quoted-printable
      or base64 implementations.  Encode any data sent that is not in
      seven-bit mail-ready representation using one of these
      transformations and include the appropriate Content-Transfer-
      Encoding header field, unless the underlying transport mechanism
      supports non-seven-bit data, as SMTP does not.

      3.  Recognize and interpret the Content-Type header field, and
      avoid showing users raw data with a Content-Type field other than
      text.  Be able to send at least text/plain messages, with the
      character set specified as a parameter if it is not US-ASCII.

      4.  Explicitly handle the following Content-Type values, to at
      least the following extents:

      Text:

            -- Recognize and display "text" mail
                 with the character set "US-ASCII."

            -- Recognize other character sets at
                 least to the extent of being able
                 to inform the user about what
                 character set the message uses.

            -- Recognize the "ISO-8859-*" character
                 sets to the extent of being able to
                 display those characters that are
                 common to ISO-8859-* and US-ASCII,
                 namely all characters represented
                 by octet values 0-127.




Borenstein & Freed                                             [Page 60]


RFC 1521                          MIME                    September 1993


            -- For unrecognized subtypes, show or
                 offer to show the user the "raw"
                 version of the data after
                 conversion of the content from
                 canonical form to local form.

       Message:

            -- Recognize and display at least the
                 primary (822) encapsulation.

       Multipart:

            -- Recognize the primary (mixed)
                 subtype.  Display all relevant
                 information on the message level
                 and the body part header level and
                 then display or offer to display
                 each of the body parts individually.

            -- Recognize the "alternative" subtype,
                 and avoid showing the user
                 redundant parts of
                 multipart/alternative mail.

            -- Treat any unrecognized subtypes as if
                 they were "mixed".

       Application:

            -- Offer the ability to remove either of
                 the two types of Content-Transfer-
                 Encoding defined in this document
                 and put the resulting information
                 in a user file.

      5.  Upon encountering any unrecognized Content- Type, an
      implementation must treat it as if it had a Content-Type of
      "application/octet-stream" with no parameter sub-arguments.  How
      such data are handled is up to an implementation, but likely
      options for handling such unrecognized data include offering the
      user to write it into a file (decoded from its mail transport
      format) or offering the user to name a program to which the
      decoded data should be passed as input.  Unrecognized predefined
      types, which in a MIME-conformant mailer might still include
      audio, image, or video, should also be treated in this way.

   A user agent that meets the above conditions is said to be MIME-



Borenstein & Freed                                             [Page 61]


RFC 1521                          MIME                    September 1993


   conformant.  The meaning of this phrase is that it is assumed to be
   "safe" to send virtually any kind of properly-marked data to users of
   such mail systems, because such systems will at least be able to
   treat the data as undifferentiated binary, and will not simply splash
   it onto the screen of unsuspecting users.  There is another sense in
   which it is always "safe" to send data in a format that is MIME-
   conformant, which is that such data will not break or be broken by
   any known systems that are conformant with RFC 821 and RFC 822.  User
   agents that are MIME-conformant have the additional guarantee that
   the user will not be shown data that were never intended to be viewed
   as text.

