rfc2046.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

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

                 Multipurpose Internet Mail Extensions
                            (MIME) Part Two:
                              Media Types

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, but which 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. This 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-ASCII text

   data in Internet mail header fields. The fourth document, RFC 2048,
   specifies various IANA registration procedures for MIME-related
   facilities.  The fifth and final document, RFC 2049, 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 and 1522, which themselves
   were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049
   describes differences and changes from previous versions.

Table of Contents

   1. Introduction .........................................    3
   2. Definition of a Top-Level Media Type .................    4
   3. Overview Of The Initial Top-Level Media Types ........    4
   4. Discrete Media Type Values ...........................    6
   4.1 Text Media Type .....................................    6
   4.1.1 Representation of Line Breaks .....................    7
   4.1.2 Charset Parameter .................................    7
   4.1.3 Plain Subtype .....................................   11
   4.1.4 Unrecognized Subtypes .............................   11
   4.2 Image Media Type ....................................   11
   4.3 Audio Media Type ....................................   11
   4.4 Video Media Type ....................................   12
   4.5 Application Media Type ..............................   12
   4.5.1 Octet-Stream Subtype ..............................   13
   4.5.2 PostScript Subtype ................................   14
   4.5.3 Other Application Subtypes ........................   17
   5. Composite Media Type Values ..........................   17
   5.1 Multipart Media Type ................................   17
   5.1.1 Common Syntax .....................................   19
   5.1.2 Handling Nested Messages and Multiparts ...........   24
   5.1.3 Mixed Subtype .....................................   24
   5.1.4 Alternative Subtype ...............................   24
   5.1.5 Digest Subtype ....................................   26
   5.1.6 Parallel Subtype ..................................   27
   5.1.7 Other Multipart Subtypes ..........................   28
   5.2 Message Media Type ..................................   28
   5.2.1 RFC822 Subtype ....................................   28
   5.2.2 Partial Subtype ...................................   29
   5.2.2.1 Message Fragmentation and Reassembly ............   30
   5.2.2.2 Fragmentation and Reassembly Example ............   31
   5.2.3 External-Body Subtype .............................   33
   5.2.4 Other Message Subtypes ............................   40
   6. Experimental Media Type Values .......................   40
   7. Summary ..............................................   41
   8. Security Considerations ..............................   41
   9. Authors' Addresses ...................................   42

   A. Collected Grammar ....................................   43

1.  Introduction

   The first document in this set, RFC 2045, defines a number of header
   fields, including Content-Type. The Content-Type field is used to
   specify the nature of the data in the body of a MIME entity, by
   giving media type and subtype identifiers, and by providing auxiliary
   information that may be required for certain media types.  After the
   type and subtype names, the remainder of the header field is simply a
   set of parameters, specified in an attribute/value notation.  The
   ordering of parameters is not significant.

   In general, the top-level media type is used to declare the general
   type of data, while the subtype specifies a specific format for that
   type of data.  Thus, a media type of "image/xyz" is enough to tell a
   user agent that the data is an image, even if the user agent has no
   knowledge of the specific image format "xyz".  Such information can
   be used, for example, to decide whether or not to show a user the raw
   data from an unrecognized subtype -- such an action might be
   reasonable for unrecognized subtypes of "text", but not for
   unrecognized subtypes of "image" or "audio".  For this reason,
   registered subtypes of "text", "image", "audio", and "video" should
   not contain embedded information that is really of a different type.
   Such compound formats should be represented using the "multipart" or
   "application" types.

   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content.  The set of
   meaningful parameters depends on the media type and subtype.  Most
   parameters are associated with a single specific subtype.  However, a
   given top-level media type may define parameters which are applicable
   to any subtype of that type.  Parameters may be required by their
   defining media type or subtype or they may be optional.  MIME
   implementations must also ignore any parameters whose names they do
   not recognize.

   MIME's Content-Type header field and media type mechanism has been
   carefully designed to be extensible, and it is expected that the set
   of media type/subtype pairs and their associated parameters will grow
   significantly over time.  Several other MIME facilities, such as
   transfer encodings and "message/external-body" access types, 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 sets up a registration process which uses the
   Internet Assigned Numbers Authority (IANA) as a central registry for
   MIME's various areas of extensibility.  The registration process for
   these areas is described in a companion document, RFC 2048.

   The initial seven standard top-level media type are defined and
   described in the remainder of this document.

2.  Definition of a Top-Level Media Type

   The definition of a top-level media type consists of:

    (1)   a name and a description of the type, including
          criteria for whether a particular type would qualify
          under that type,

    (2)   the names and definitions of parameters, if any, which
          are defined for all subtypes of that type (including
          whether such parameters are required or optional),

    (3)   how a user agent and/or gateway should handle unknown
          subtypes of this type,

    (4)   general considerations on gatewaying entities of this
          top-level type, if any, and

    (5)   any restrictions on content-transfer-encodings for
          entities of this top-level type.

3.  Overview Of The Initial Top-Level Media Types

   The five discrete top-level media types are:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".

    (2)   image -- image data.  "Image" requires a display device
          (such as a graphical display, a graphics printer, or a
          FAX machine) to view the information. An initial
          subtype is defined for the widely-used image format
          JPEG. .  subtypes are defined for two widely-used image
          formats, jpeg and gif.

    (3)   audio -- audio data.  "Audio" requires an audio output
          device (such as a speaker or a telephone) to "display"
          the contents.  An initial subtype "basic" is defined in
          this document.

    (4)   video -- video data.  "Video" requires the capability
          to display moving images, typically including
          specialized hardware and software.  An initial subtype
          "mpeg" is defined in this document.

    (5)   application -- some other kind of data, typically
          either uninterpreted binary data or information to be
          processed by an application.  The subtype "octet-
          stream" is to be used in the case of uninterpreted
          binary data, in which case the simplest recommended
          action is to offer to write the information into a file
          for the user.  The "PostScript" subtype is also defined
          for the transport of PostScript material.  Other
          expected uses for "application" include spreadsheets,
          data for mail-based scheduling systems, and languages
          for "active" (computational) messaging, and word
          processing formats that are not directly readable.
          Note that security considerations may exist for some
          types of application data, most notably
          "application/PostScript" and any form of active
          messaging.  These issues are discussed later in this
          document.

   The two composite top-level media types are:

    (1)   multipart -- data consisting of multiple entities of
          independent data types.  Four subtypes are initially
          defined, including the basic "mixed" subtype specifying
          a generic mixed set of parts, "alternative" for
          representing the same data in multiple formats,
          "parallel" for parts intended to be viewed
          simultaneously, and "digest" for multipart entities in
          which each part has a default type of "message/rfc822".

    (2)   message -- an encapsulated message.  A body of media
          type "message" is itself all or a portion of some kind
          of message object.  Such objects may or may not in turn
          contain other entities.  The "rfc822" subtype is used
          when the encapsulated content is itself an RFC 822
          message.  The "partial" subtype is defined for partial
          RFC 822 messages, to permit the fragmented transmission
          of bodies that are thought to be too large to be passed
          through transport facilities in one piece.  Another
          subtype, "external-body", is defined for specifying
          large bodies by reference to an external data source.

   It should be noted that the list of media type values given here may
   be augmented in time, via the mechanisms described above, and that