rfc1521_mime.txt

邮件编码格式说明。

Network Working Group                                      N. Borenstein
Request for Comments: 1521                                      Bellcore
Obsoletes: 1341                                                 N. Freed
Category: Standards Track                                       Innosoft
                                                          September 1993


         MIME (Multipurpose Internet Mail Extensions) Part One:
                Mechanisms for Specifying and Describing
                 the Format of Internet Message Bodies

Status of this Memo

   This RFC 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" 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 which
   specifies considerable detail about message headers, but which leaves
   the message content, or message body, as flat ASCII text.  This
   document redefines the format of message bodies to allow multi-part
   textual and non-textual message bodies to be represented and
   exchanged without loss of information.  This is based on earlier work
   documented in RFC 934 and STD 11, RFC 1049, but extends and revises
   that work.  Because RFC 822 said so little about message bodies, this
   document is largely orthogonal to (rather than a revision of) RFC
   822.

   In particular, this document is designed to provide facilities to
   include multiple objects in a single message, to represent body text
   in character sets other than US-ASCII, to represent formatted multi-
   font text messages, to represent non-textual material such as images
   and audio fragments, and generally to facilitate later extensions
   defining new types of Internet mail for use by cooperating mail
   agents.

   This document does NOT extend Internet mail header fields to permit
   anything other than US-ASCII text data.  Such extensions are the
   subject of a companion document [RFC-1522].

   This document is a revision of RFC 1341.  Significant differences
   from RFC 1341 are summarized in Appendix H.





Borenstein & Freed                                              [Page 1]

RFC 1521                          MIME                    September 1993


Table of Contents

   1.     Introduction.......................................  3
   2.     Notations, Conventions, and Generic BNF Grammar....  6
   3.     The MIME-Version Header Field......................  7
   4.     The Content-Type Header Field......................  9
   5.     The Content-Transfer-Encoding Header Field......... 13
   5.1.   Quoted-Printable Content-Transfer-Encoding......... 18
   5.2.   Base64 Content-Transfer-Encoding................... 21
   6.     Additional Content-Header Fields................... 23
   6.1.   Optional Content-ID Header Field................... 23
   6.2.   Optional Content-Description Header Field.......... 24
   7.     The Predefined Content-Type Values................. 24
   7.1.   The Text Content-Type.............................. 24
   7.1.1. The charset parameter.............................. 25
   7.1.2. The Text/plain subtype............................. 28
   7.2.   The Multipart Content-Type......................... 28
   7.2.1. Multipart:  The common syntax...................... 29
   7.2.2. The Multipart/mixed (primary) subtype.............. 34
   7.2.3. The Multipart/alternative subtype.................. 34
   7.2.4. The Multipart/digest subtype....................... 36
   7.2.5. The Multipart/parallel subtype..................... 37
   7.2.6. Other Multipart subtypes........................... 37
   7.3.   The Message Content-Type........................... 38
   7.3.1. The Message/rfc822 (primary) subtype............... 38
   7.3.2. The Message/Partial subtype........................ 39
   7.3.3. The Message/External-Body subtype.................. 42
   7.3.3.1.  The "ftp" and "tftp" access-types............... 44
   7.3.3.2.  The "anon-ftp" access-type...................... 45
   7.3.3.3.  The "local-file" and "afs" access-types......... 45
   7.3.3.4.  The "mail-server" access-type................... 45
   7.3.3.5.  Examples and Further Explanations............... 46
   7.4.   The Application Content-Type....................... 49
   7.4.1. The Application/Octet-Stream (primary) subtype..... 50
   7.4.2. The Application/PostScript subtype................. 50
   7.4.3. Other Application subtypes......................... 53
   7.5.   The Image Content-Type............................. 53
   7.6.   The Audio Content-Type............................. 54
   7.7.   The Video Content-Type............................. 54
   7.8.   Experimental Content-Type Values................... 54
   8.     Summary............................................ 56
   9.     Security Considerations............................ 56
   10.    Authors' Addresses................................. 57
   11.    Acknowledgements................................... 58
   Appendix A -- Minimal MIME-Conformance.................... 60
   Appendix B -- General Guidelines For Sending Email Data... 63
   Appendix C -- A Complex Multipart Example................. 66
   Appendix D -- Collected Grammar........................... 68



Borenstein & Freed                                              [Page 2]

RFC 1521                          MIME                    September 1993


   Appendix E -- IANA Registration Procedures................ 72
   E.1  Registration of New Content-type/subtype Values...... 72
   E.2  Registration of New Access-type Values
        for Message/external-body............................ 73
   Appendix F -- Summary of the Seven Content-types.......... 74
   Appendix G -- Canonical Encoding Model.................... 76
   Appendix H -- Changes from RFC 1341....................... 78
   References................................................ 80

1.    Introduction

   Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined
   the standard format of textual mail messages on the Internet.  Its
   success has been such that the RFC 822 format has been adopted,
   wholly or partially, well beyond the confines of the Internet and the
   Internet SMTP transport defined by STD 10, RFC 821 [RFC-821].  As the
   format has seen wider use, a number of limitations have proven
   increasingly restrictive for the user community.

   RFC 822 was intended to specify a format for text messages.  As such,
   non-text messages, such as multimedia messages that might include
   audio or images, are simply not mentioned.  Even in the case of text,
   however, RFC 822 is inadequate for the needs of mail users whose
   languages require the use of character sets richer than US ASCII
   [US-ASCII]. Since RFC 822 does not specify mechanisms for mail
   containing audio, video, Asian language text, or even text in most
   European languages, additional specifications are needed.

   One of the notable limitations of RFC 821/822 based mail systems is
   the fact that they limit the contents of electronic mail messages to
   relatively short lines of seven-bit ASCII.  This forces users to
   convert any non-textual data that they may wish to send into seven-
   bit bytes representable as printable ASCII characters before invoking
   a local mail UA (User Agent, a program with which human users send
   and receive mail). Examples of such encodings currently used in the
   Internet include pure hexadecimal, uuencode, the 3-in-4 base 64
   scheme specified in RFC 1421, the Andrew Toolkit Representation
   [ATK], and many others.

   The limitations of RFC 822 mail become even more apparent as gateways
   are designed to allow for the exchange of mail messages between RFC
   822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
   inclusion of non-textual body parts within electronic mail messages.
   The current standards for the mapping of X.400 messages to RFC 822
   messages specify either that X.400 non-textual body parts must be
   converted to (not encoded in) an ASCII format, or that they must be
   discarded, notifying the RFC 822 user that discarding has occurred.
   This is clearly undesirable, as information that a user may wish to



Borenstein & Freed                                              [Page 3]

RFC 1521                          MIME                    September 1993


   receive is lost.  Even though a user's UA may not have the capability
   of dealing with the non-textual body part, the user might have some
   mechanism external to the UA that can extract useful information from
   the body part.  Moreover, it does not allow for the fact that the
   message may eventually be gatewayed back into an X.400 message
   handling system (i.e., the X.400 message is "tunneled" through
   Internet mail), where the non-textual information would definitely
   become useful again.

   This document describes several mechanisms that combine to solve most
   of these problems without introducing any serious incompatibilities
   with the existing world of RFC 822 mail.  In particular, it
   describes:

   1. A MIME-Version header field, which uses a version number to
       declare a message to be conformant with this specification and
       allows mail processing agents to distinguish between such
       messages and those generated by older or non-conformant software,
       which is presumed to lack such a field.

   2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],
       which can be used to specify the type and subtype of data in the
       body of a message and to fully specify the native representation
       (encoding) of such data.

       2.a. A "text" Content-Type value, which can be used to represent
            textual information in a number of character sets and
            formatted text description languages in a standardized
            manner.

       2.b. A "multipart" Content-Type value, which can be used to
            combine several body parts, possibly of differing types of
            data, into a single message.

       2.c. An "application" Content-Type value, which can be used to
            transmit application data or binary data, and hence, among
            other uses, to implement an electronic mail file transfer
            service.

       2.d. A "message" Content-Type value, for encapsulating another
            mail message.

       2.e An "image" Content-Type value, for transmitting still image
            (picture) data.

       2.f. An "audio" Content-Type value, for transmitting audio or
            voice data.




Borenstein & Freed                                              [Page 4]

RFC 1521                          MIME                    September 1993


       2.g. A "video" Content-Type value, for transmitting video or
            moving image data, possibly with audio as part of the
            composite video data format.

   3. A Content-Transfer-Encoding header field, which can be used to
       specify an auxiliary encoding that was applied to the data in
       order to allow it to pass through mail transport mechanisms which
       may have data or character set limitations.

   4. Two additional header fields that can be used to further describe
       the data in a message body, the Content-ID and Content-
       Description header fields.

   MIME has been carefully designed as an extensible mechanism, and it
   is expected that the set of content-type/subtype pairs and their
   associated parameters will grow significantly with time.  Several
   other MIME fields, notably including character set names, are likely
   to have new values defined over time.  In order to ensure that the
   set of such values is developed in an orderly, well-specified, and
   public manner, MIME defines a registration process which uses the
   Internet Assigned Numbers Authority (IANA) as a central registry for
   such values.  Appendix E provides details about how IANA registration
   is accomplished.

   Finally, to specify and promote interoperability, Appendix A of this
   document provides a basic applicability statement for a subset of the
   above mechanisms that defines a minimal level of "conformance" with
   this document.

      HISTORICAL NOTE: Several of the mechanisms described in this
      document may seem somewhat strange or even baroque at first
      reading.  It is important to note that compatibility with existing
      standards AND robustness across existing practice were two of the
      highest priorities of the working group that developed this
      document.  In particular, compatibility was always favored over
      elegance.

   MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]