Multipart:

            -- Recognize the 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.

            -- Recognize the "multipart/digest" subtype,
            specifically using "message/rfc822" rather than
            "text/plain" as the default media type for body parts
            inside "multipart/digest" entities.

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








 
RFC 2049                    MIME Conformance               November 1996


          Message:

            -- Recognize and display at least the RFC822 message
            encapsulation (message/rfc822) in such a way as to
            preserve any recursive structure, that is, displaying
            or offering to display the encapsulated data in
            accordance with its media type.

            -- Treat any unrecognized subtypes as if they were
            "application/octet-stream".

    (7)   Upon encountering any unrecognized Content-Type field,
          an implementation must treat it as if it had a media
          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.

    (8)   Conformant user agents are required, if they provide
          non-standard support for non-MIME messages employing
          character sets other than US-ASCII, to do so on
          received messages only. Conforming user agents must not
          send non-MIME messages containing anything other than
          US-ASCII text.

          In particular, the use of non-US-ASCII text in mail
          messages without a MIME-Version field is strongly
          discouraged as it impedes interoperability when sending
          messages between regions with different localization
          conventions. Conforming user agents MUST include proper
          MIME labelling when sending anything other than plain
          text in the US-ASCII character set.

          In addition, non-MIME user agents should be upgraded if
          at all possible to include appropriate MIME header
          information in the messages they send even if nothing
          else in MIME is supported.  This upgrade will have
          little, if any, effect on non-MIME recipients and will
          aid MIME in correctly displaying such messages.  It
          also provides a smooth transition path to eventual
          adoption of other MIME capabilities.

    (9)   Conforming user agents must ensure that any string of
          non-white-space printable US-ASCII characters within a
          "*text" or "*ctext" that begins with "=?" and ends with




 
RFC 2049                    MIME Conformance               November 1996


          "?=" be a valid encoded-word.  ("begins" means: At the
          start of the field-body or immediately following
          linear-white-space; "ends" means: At the end of the
          field-body or immediately preceding linear-white-
          space.) In addition, any "word" within a "phrase" that
          begins with "=?" and ends with "?=" must be a valid
          encoded-word.

    (10)  Conforming user agents must be able to distinguish
          encoded-words from "text", "ctext", or "word"s,
          according to the rules in section 4, anytime they
          appear in appropriate places in message headers.  It
          must support both the "B" and "Q" encodings for any
          character set which it supports.  The program must be