rfc2049.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          N. Freed
Request for Comments: 2049                                     Innosoft
Obsoletes: 1521, 1522, 1590                               N. Borenstein
Category: Standards Track                                 First Virtual
                                                          November 1996


                 Multipurpose Internet Mail Extensions
                           (MIME) Part Five:
                   Conformance Criteria and Examples

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   STD 11, RFC 822, defines a message representation protocol specifying
   considerable detail about US-ASCII message headers, and leaves the
   message content, or message body, as flat US-ASCII text.  This set of
   documents, collectively called the Multipurpose Internet Mail
   Extensions, or MIME, redefines the format of messages to allow for

    (1)   textual message bodies in character sets other than
          US-ASCII,

    (2)   an extensible set of different formats for non-textual
          message bodies,

    (3)   multi-part message bodies, and

    (4)   textual header information in character sets other than
          US-ASCII.

   These documents are based on earlier work documented in RFC 934, STD
   11, and RFC 1049, but extends and revises them.  Because RFC 822 said
   so little about message bodies, these documents are largely
   orthogonal to (rather than a revision of) RFC 822.

   The initial document in this set, RFC 2045, specifies the various
   headers used to describe the structure of MIME messages. The second
   document defines the general structure of the MIME media typing
   system and defines an initial set of media types.  The third
   document, RFC 2047, describes extensions to RFC 822 to allow non-US-



Freed & Borenstein          Standards Track                     [Page 1]

RFC 2049                    MIME Conformance               November 1996


   ASCII text data in Internet mail header fields. The fourth document,
   RFC 2048, specifies various IANA registration procedures for MIME-
   related facilities. This fifth and final document describes MIME
   conformance criteria as well as providing some illustrative examples
   of MIME message formats, acknowledgements, and the bibliography.

   These documents are revisions of RFCs 1521, 1522, and 1590, which
   themselves were revisions of RFCs 1341 and 1342.  Appendix B of this
   document describes differences and changes from previous versions.

Table of Contents

   1. Introduction ..........................................    2
   2. MIME Conformance ......................................    2
   3. Guidelines for Sending Email Data .....................    6
   4. Canonical Encoding Model ..............................    9
   5. Summary ...............................................   12
   6. Security Considerations ...............................   12
   7. Authors' Addresses ....................................   12
   8. Acknowledgements ......................................   13
   A. A Complex Multipart Example ...........................   15
   B. Changes from RFC 1521, 1522, and 1590 .................   16
   C. References ............................................   20

1.  Introduction

   The first and second documents in this set define MIME header fields
   and the initial set of MIME media types.  The third document
   describes extensions to RFC822 formats to allow for character sets
   other than US-ASCII.  This document describes what portions  of MIME
   must be supported by a conformant MIME implementation. It also
   describes various pitfalls of contemporary messaging systems as well
   as the canonical encoding model MIME is based on.

2.  MIME Conformance

   The mechanisms described in these documents are open-ended.  It is
   definitely not expected that all implementations will support all
   available media types, 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.







Freed & Borenstein          Standards Track                     [Page 2]

RFC 2049                    MIME Conformance               November 1996


   A mail user agent that is MIME-conformant MUST:

    (1)   Always generate a "MIME-Version: 1.0" header field in
          any message it creates.

    (2)   Recognize the Content-Transfer-Encoding header field
          and decode all received data encoded by either quoted-
          printable or base64 implementations.  The identity
          transformations 7bit, 8bit, and binary must also be
          recognized.

          Any non-7bit data that is sent without encoding must be
          properly labelled with a content-transfer-encoding of
          8bit or binary, as appropriate.  If the underlying
          transport does not support 8bit or binary (as SMTP
          [RFC-821] does not), the sender is required to both
          encode and label data using an appropriate Content-
          Transfer-Encoding such as quoted-printable or base64.

    (3)   Must treat any unrecognized Content-Transfer-Encoding
          as if it had a Content-Type of "application/octet-
          stream", regardless of whether or not the actual
          Content-Type is recognized.

    (4)   Recognize and interpret the Content-Type header field,
          and avoid showing users raw data with a Content-Type
          field other than text.  Implementations  must be able
          to send at least text/plain messages, with the
          character set specified with the charset parameter if
          it is not US-ASCII.

    (5)   Ignore any content type parameters whose names they do
          not recognize.

    (6)   Explicitly handle the following media 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.






Freed & Borenstein          Standards Track                     [Page 3]

RFC 2049                    MIME Conformance               November 1996


            -- 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 1-127.

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

            -- Treat material in an unknown character set as if
            it were "application/octet-stream".

          Image, audio, and video:

            -- At a minumum provide facilities to treat any
            unrecognized subtypes as if they were
            "application/octet-stream".

          Application:

            -- Offer the ability to remove either of the quoted-
            printable or base64 encodings defined in this
            document if they were used and put the resulting
            information in a user file.

          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".







Freed & Borenstein          Standards Track                     [Page 4]

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



Freed & Borenstein          Standards Track                     [Page 5]

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
          able to display the unencoded text if the character set
          is "US-ASCII".  For the ISO-8859-* character sets, the
          mail reading program must at least be able to display
          the characters which are also in the US-ASCII set.

   A user agent that meets the above conditions is said to be MIME-
   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.

3.  Guidelines for Sending Email Data

   Internet email is not a perfect, homogeneous system.  Mail may become
   corrupted at several stages in its travel to a final destination.
   Specifically, email sent throughout the Internet may travel across
   many networking technologies. Many networking and mail technologies
   do not support the full functionality possible in the SMTP transport
   environment.  Mail traversing these systems is likely to be modified
   in order that it can be transported.

   There exist many widely-deployed non-conformant MTAs in the Internet.
   These MTAs, speaking the SMTP protocol, alter messages on the fly to
   take advantage of the internal data structure of the hosts they are
   implemented on, or are just plain broken.