"Fossies" - the Fresh Open Source Software Archive

Member "libgcgi.a-0.9.5/doc/rfc2046.txt" (22 Jun 2002, 105854 Bytes) of package /linux/www/old/gcgi-0.9.5.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 
    2 
    3 
    4 
    5 
    6 
    7 Network Working Group                                          N. Freed
    8 Request for Comments: 2046                                     Innosoft
    9 Obsoletes: 1521, 1522, 1590                               N. Borenstein
   10 Category: Standards Track                                 First Virtual
   11                                                           November 1996
   12 
   13 
   14                  Multipurpose Internet Mail Extensions
   15                             (MIME) Part Two:
   16                               Media Types
   17 
   18 Status of this Memo
   19 
   20    This document specifies an Internet standards track protocol for the
   21    Internet community, and requests discussion and suggestions for
   22    improvements.  Please refer to the current edition of the "Internet
   23    Official Protocol Standards" (STD 1) for the standardization state
   24    and status of this protocol.  Distribution of this memo is unlimited.
   25 
   26 Abstract
   27 
   28    STD 11, RFC 822 defines a message representation protocol specifying
   29    considerable detail about US-ASCII message headers, but which leaves
   30    the message content, or message body, as flat US-ASCII text.  This
   31    set of documents, collectively called the Multipurpose Internet Mail
   32    Extensions, or MIME, redefines the format of messages to allow for
   33 
   34     (1)   textual message bodies in character sets other than
   35           US-ASCII,
   36 
   37     (2)   an extensible set of different formats for non-textual
   38           message bodies,
   39 
   40     (3)   multi-part message bodies, and
   41 
   42     (4)   textual header information in character sets other than
   43           US-ASCII.
   44 
   45    These documents are based on earlier work documented in RFC 934, STD
   46    11, and RFC 1049, but extends and revises them.  Because RFC 822 said
   47    so little about message bodies, these documents are largely
   48    orthogonal to (rather than a revision of) RFC 822.
   49 
   50    The initial document in this set, RFC 2045, specifies the various
   51    headers used to describe the structure of MIME messages. This second
   52    document defines the general structure of the MIME media typing
   53    system and defines an initial set of media types. The third document,
   54    RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text
   55 
   56 
   57 
   58 Freed & Borenstein          Standards Track                     [Page 1]
   59 
   60 RFC 2046                      Media Types                  November 1996
   61 
   62 
   63    data in Internet mail header fields. The fourth document, RFC 2048,
   64    specifies various IANA registration procedures for MIME-related
   65    facilities.  The fifth and final document, RFC 2049, describes MIME
   66    conformance criteria as well as providing some illustrative examples
   67    of MIME message formats, acknowledgements, and the bibliography.
   68 
   69    These documents are revisions of RFCs 1521 and 1522, which themselves
   70    were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049
   71    describes differences and changes from previous versions.
   72 
   73 Table of Contents
   74 
   75    1. Introduction .........................................    3
   76    2. Definition of a Top-Level Media Type .................    4
   77    3. Overview Of The Initial Top-Level Media Types ........    4
   78    4. Discrete Media Type Values ...........................    6
   79    4.1 Text Media Type .....................................    6
   80    4.1.1 Representation of Line Breaks .....................    7
   81    4.1.2 Charset Parameter .................................    7
   82    4.1.3 Plain Subtype .....................................   11
   83    4.1.4 Unrecognized Subtypes .............................   11
   84    4.2 Image Media Type ....................................   11
   85    4.3 Audio Media Type ....................................   11
   86    4.4 Video Media Type ....................................   12
   87    4.5 Application Media Type ..............................   12
   88    4.5.1 Octet-Stream Subtype ..............................   13
   89    4.5.2 PostScript Subtype ................................   14
   90    4.5.3 Other Application Subtypes ........................   17
   91    5. Composite Media Type Values ..........................   17
   92    5.1 Multipart Media Type ................................   17
   93    5.1.1 Common Syntax .....................................   19
   94    5.1.2 Handling Nested Messages and Multiparts ...........   24
   95    5.1.3 Mixed Subtype .....................................   24
   96    5.1.4 Alternative Subtype ...............................   24
   97    5.1.5 Digest Subtype ....................................   26
   98    5.1.6 Parallel Subtype ..................................   27
   99    5.1.7 Other Multipart Subtypes ..........................   28
  100    5.2 Message Media Type ..................................   28
  101    5.2.1 RFC822 Subtype ....................................   28
  102    5.2.2 Partial Subtype ...................................   29
  103    5.2.2.1 Message Fragmentation and Reassembly ............   30
  104    5.2.2.2 Fragmentation and Reassembly Example ............   31
  105    5.2.3 External-Body Subtype .............................   33
  106    5.2.4 Other Message Subtypes ............................   40
  107    6. Experimental Media Type Values .......................   40
  108    7. Summary ..............................................   41
  109    8. Security Considerations ..............................   41
  110    9. Authors' Addresses ...................................   42
  111 
  112 
  113 
  114 Freed & Borenstein          Standards Track                     [Page 2]
  115 
  116 RFC 2046                      Media Types                  November 1996
  117 
  118 
  119    A. Collected Grammar ....................................   43
  120 
  121 1.  Introduction
  122 
  123    The first document in this set, RFC 2045, defines a number of header
  124    fields, including Content-Type. The Content-Type field is used to
  125    specify the nature of the data in the body of a MIME entity, by
  126    giving media type and subtype identifiers, and by providing auxiliary
  127    information that may be required for certain media types.  After the
  128    type and subtype names, the remainder of the header field is simply a
  129    set of parameters, specified in an attribute/value notation.  The
  130    ordering of parameters is not significant.
  131 
  132    In general, the top-level media type is used to declare the general
  133    type of data, while the subtype specifies a specific format for that
  134    type of data.  Thus, a media type of "image/xyz" is enough to tell a
  135    user agent that the data is an image, even if the user agent has no
  136    knowledge of the specific image format "xyz".  Such information can
  137    be used, for example, to decide whether or not to show a user the raw
  138    data from an unrecognized subtype -- such an action might be
  139    reasonable for unrecognized subtypes of "text", but not for
  140    unrecognized subtypes of "image" or "audio".  For this reason,
  141    registered subtypes of "text", "image", "audio", and "video" should
  142    not contain embedded information that is really of a different type.
  143    Such compound formats should be represented using the "multipart" or
  144    "application" types.
  145 
  146    Parameters are modifiers of the media subtype, and as such do not
  147    fundamentally affect the nature of the content.  The set of
  148    meaningful parameters depends on the media type and subtype.  Most
  149    parameters are associated with a single specific subtype.  However, a
  150    given top-level media type may define parameters which are applicable
  151    to any subtype of that type.  Parameters may be required by their
  152    defining media type or subtype or they may be optional.  MIME
  153    implementations must also ignore any parameters whose names they do
  154    not recognize.
  155 
  156    MIME's Content-Type header field and media type mechanism has been
  157    carefully designed to be extensible, and it is expected that the set
  158    of media type/subtype pairs and their associated parameters will grow
  159    significantly over time.  Several other MIME facilities, such as
  160    transfer encodings and "message/external-body" access types, are
  161    likely to have new values defined over time.  In order to ensure that
  162    the set of such values is developed in an orderly, well-specified,
  163    and public manner, MIME sets up a registration process which uses the
  164    Internet Assigned Numbers Authority (IANA) as a central registry for
  165    MIME's various areas of extensibility.  The registration process for
  166    these areas is described in a companion document, RFC 2048.
  167 
  168 
  169 
  170 Freed & Borenstein          Standards Track                     [Page 3]
  171 
  172 RFC 2046                      Media Types                  November 1996
  173 
  174 
  175    The initial seven standard top-level media type are defined and
  176    described in the remainder of this document.
  177 
  178 2.  Definition of a Top-Level Media Type
  179 
  180    The definition of a top-level media type consists of:
  181 
  182     (1)   a name and a description of the type, including
  183           criteria for whether a particular type would qualify
  184           under that type,
  185 
  186     (2)   the names and definitions of parameters, if any, which
  187           are defined for all subtypes of that type (including
  188           whether such parameters are required or optional),
  189 
  190     (3)   how a user agent and/or gateway should handle unknown
  191           subtypes of this type,
  192 
  193     (4)   general considerations on gatewaying entities of this
  194           top-level type, if any, and
  195 
  196     (5)   any restrictions on content-transfer-encodings for
  197           entities of this top-level type.
  198 
  199 3.  Overview Of The Initial Top-Level Media Types
  200 
  201    The five discrete top-level media types are:
  202 
  203     (1)   text -- textual information.  The subtype "plain" in
  204           particular indicates plain text containing no
  205           formatting commands or directives of any sort. Plain
  206           text is intended to be displayed "as-is". No special
  207           software is required to get the full meaning of the
  208           text, aside from support for the indicated character
  209           set. Other subtypes are to be used for enriched text in
  210           forms where application software may enhance the
  211           appearance of the text, but such software must not be
  212           required in order to get the general idea of the
  213           content.  Possible subtypes of "text" thus include any
  214           word processor format that can be read without
  215           resorting to software that understands the format.  In
  216           particular, formats that employ embeddded binary
  217           formatting information are not considered directly
  218           readable. A very simple and portable subtype,
  219           "richtext", was defined in RFC 1341, with a further
  220           revision in RFC 1896 under the name "enriched".
  221 
  222 
  223 
  224 
  225 
  226 Freed & Borenstein          Standards Track                     [Page 4]
  227 
  228 RFC 2046                      Media Types                  November 1996
  229 
  230 
  231     (2)   image -- image data.  "Image" requires a display device
  232           (such as a graphical display, a graphics printer, or a
  233           FAX machine) to view the information. An initial
  234           subtype is defined for the widely-used image format
  235           JPEG. .  subtypes are defined for two widely-used image
  236           formats, jpeg and gif.
  237 
  238     (3)   audio -- audio data.  "Audio" requires an audio output
  239           device (such as a speaker or a telephone) to "display"
  240           the contents.  An initial subtype "basic" is defined in
  241           this document.
  242 
  243     (4)   video -- video data.  "Video" requires the capability
  244           to display moving images, typically including
  245           specialized hardware and software.  An initial subtype
  246           "mpeg" is defined in this document.
  247 
  248     (5)   application -- some other kind of data, typically
  249           either uninterpreted binary data or information to be
  250           processed by an application.  The subtype "octet-
  251           stream" is to be used in the case of uninterpreted
  252           binary data, in which case the simplest recommended
  253           action is to offer to write the information into a file
  254           for the user.  The "PostScript" subtype is also defined
  255           for the transport of PostScript material.  Other
  256           expected uses for "application" include spreadsheets,
  257           data for mail-based scheduling systems, and languages
  258           for "active" (computational) messaging, and word
  259           processing formats that are not directly readable.
  260           Note that security considerations may exist for some
  261           types of application data, most notably
  262           "application/PostScript" and any form of active
  263           messaging.  These issues are discussed later in this
  264           document.
  265 
  266    The two composite top-level media types are:
  267 
  268     (1)   multipart -- data consisting of multiple entities of
  269           independent data types.  Four subtypes are initially
  270           defined, including the basic "mixed" subtype specifying
  271           a generic mixed set of parts, "alternative" for
  272           representing the same data in multiple formats,
  273           "parallel" for parts intended to be viewed
  274           simultaneously, and "digest" for multipart entities in
  275           which each part has a default type of "message/rfc822".
  276 
  277 
  278 
  279 
  280 
  281 
  282 Freed & Borenstein          Standards Track                     [Page 5]
  283 
  284 RFC 2046                      Media Types                  November 1996
  285 
  286 
  287     (2)   message -- an encapsulated message.  A body of media
  288           type "message" is itself all or a portion of some kind
  289           of message object.  Such objects may or may not in turn
  290           contain other entities.  The "rfc822" subtype is used
  291           when the encapsulated content is itself an RFC 822
  292           message.  The "partial" subtype is defined for partial
  293           RFC 822 messages, to permit the fragmented transmission
  294           of bodies that are thought to be too large to be passed
  295           through transport facilities in one piece.  Another
  296           subtype, "external-body", is defined for specifying
  297           large bodies by reference to an external data source.
  298 
  299    It should be noted that the list of media type values given here may
  300    be augmented in time, via the mechanisms described above, and that
  301    the set of subtypes is expected to grow substantially.
  302 
  303 4.  Discrete Media Type Values
  304 
  305    Five of the seven initial media type values refer to discrete bodies.
  306    The content of these types must be handled by non-MIME mechanisms;
  307    they are opaque to MIME processors.
  308 
  309 4.1.  Text Media Type
  310 
  311    The "text" media type is intended for sending material which is
  312    principally textual in form.  A "charset" parameter may be used to
  313    indicate the character set of the body text for "text" subtypes,
  314    notably including the subtype "text/plain", which is a generic
  315    subtype for plain text.  Plain text does not provide for or allow
  316    formatting commands, font attribute specifications, processing
  317    instructions, interpretation directives, or content markup.  Plain
  318    text is seen simply as a linear sequence of characters, possibly
  319    interrupted by line breaks or page breaks.  Plain text may allow the
  320    stacking of several characters in the same position in the text.
  321    Plain text in scripts like Arabic and Hebrew may also include
  322    facilitites that allow the arbitrary mixing of text segments with
  323    opposite writing directions.
  324 
  325    Beyond plain text, there are many formats for representing what might
  326    be known as "rich text".  An interesting characteristic of many such
  327    representations is that they are to some extent readable even without
  328    the software that interprets them.  It is useful, then, to
  329    distinguish them, at the highest level, from such unreadable data as
  330    images, audio, or text represented in an unreadable form. In the
  331    absence of appropriate interpretation software, it is reasonable to
  332    show subtypes of "text" to the user, while it is not reasonable to do
  333    so with most nontextual data. Such formatted textual data should be
  334    represented using subtypes of "text".
  335 
  336 
  337 
  338 Freed & Borenstein          Standards Track                     [Page 6]
  339 
  340 RFC 2046                      Media Types                  November 1996
  341 
  342 
  343 4.1.1.  Representation of Line Breaks
  344 
  345    The canonical form of any MIME "text" subtype MUST always represent a
  346    line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
  347    MIME "text" MUST represent a line break.  Use of CR and LF outside of
  348    line break sequences is also forbidden.
  349 
  350    This rule applies regardless of format or character set or sets
  351    involved.
  352 
  353    NOTE: The proper interpretation of line breaks when a body is
  354    displayed depends on the media type. In particular, while it is
  355    appropriate to treat a line break as a transition to a new line when
  356    displaying a "text/plain" body, this treatment is actually incorrect
  357    for other subtypes of "text" like "text/enriched" [RFC-1896].
  358    Similarly, whether or not line breaks should be added during display
  359    operations is also a function of the media type. It should not be
  360    necessary to add any line breaks to display "text/plain" correctly,
  361    whereas proper display of "text/enriched" requires the appropriate
  362    addition of line breaks.
  363 
  364    NOTE: Some protocols defines a maximum line length.  E.g. SMTP [RFC-
  365    821] allows a maximum of 998 octets before the next CRLF sequence.
  366    To be transported by such protocols, data which includes too long
  367    segments without CRLF sequences must be encoded with a suitable
  368    content-transfer-encoding.
  369 
  370 4.1.2.  Charset Parameter
  371 
  372    A critical parameter that may be specified in the Content-Type field
  373    for "text/plain" data is the character set.  This is specified with a
  374    "charset" parameter, as in:
  375 
  376      Content-type: text/plain; charset=iso-8859-1
  377 
  378    Unlike some other parameter values, the values of the charset
  379    parameter are NOT case sensitive.  The default character set, which
  380    must be assumed in the absence of a charset parameter, is US-ASCII.
  381 
  382    The specification for any future subtypes of "text" must specify
  383    whether or not they will also utilize a "charset" parameter, and may
  384    possibly restrict its values as well.  For other subtypes of "text"
  385    than "text/plain", the semantics of the "charset" parameter should be
  386    defined to be identical to those specified here for "text/plain",
  387    i.e., the body consists entirely of characters in the given charset.
  388    In particular, definers of future "text" subtypes should pay close
  389    attention to the implications of multioctet character sets for their
  390    subtype definitions.
  391 
  392 
  393 
  394 Freed & Borenstein          Standards Track                     [Page 7]
  395 
  396 RFC 2046                      Media Types                  November 1996
  397 
  398 
  399    The charset parameter for subtypes of "text" gives a name of a
  400    character set, as "character set" is defined in RFC 2045.  The rules
  401    regarding line breaks detailed in the previous section must also be
  402    observed -- a character set whose definition does not conform to
  403    these rules cannot be used in a MIME "text" subtype.
  404 
  405    An initial list of predefined character set names can be found at the
  406    end of this section.  Additional character sets may be registered
  407    with IANA.
  408 
  409    Other media types than subtypes of "text" might choose to employ the
  410    charset parameter as defined here, but with the CRLF/line break
  411    restriction removed.  Therefore, all character sets that conform to
  412    the general definition of "character set" in RFC 2045 can be
  413    registered for MIME use.
  414 
  415    Note that if the specified character set includes 8-bit characters
  416    and such characters are used in the body, a Content-Transfer-Encoding
  417    header field and a corresponding encoding on the data are required in
  418    order to transmit the body via some mail transfer protocols, such as
  419    SMTP [RFC-821].
  420 
  421    The default character set, US-ASCII, has been the subject of some
  422    confusion and ambiguity in the past.  Not only were there some
  423    ambiguities in the definition, there have been wide variations in
  424    practice.  In order to eliminate such ambiguity and variations in the
  425    future, it is strongly recommended that new user agents explicitly
  426    specify a character set as a media type parameter in the Content-Type
  427    header field. "US-ASCII" does not indicate an arbitrary 7-bit
  428    character set, but specifies that all octets in the body must be
  429    interpreted as characters according to the US-ASCII character set.
  430    National and application-oriented versions of ISO 646 [ISO-646] are
  431    usually NOT identical to US-ASCII, and in that case their use in
  432    Internet mail is explicitly discouraged.  The omission of the ISO 646
  433    character set from this document is deliberate in this regard.  The
  434    character set name of "US-ASCII" explicitly refers to the character
  435    set defined in ANSI X3.4-1986 [US- ASCII].  The new international
  436    reference version (IRV) of the 1991 edition of ISO 646 is identical
  437    to US-ASCII.  The character set name "ASCII" is reserved and must not
  438    be used for any purpose.
  439 
  440    NOTE: RFC 821 explicitly specifies "ASCII", and references an earlier
  441    version of the American Standard.  Insofar as one of the purposes of
  442    specifying a media type and character set is to permit the receiver
  443    to unambiguously determine how the sender intended the coded message
  444    to be interpreted, assuming anything other than "strict ASCII" as the
  445    default would risk unintentional and incompatible changes to the
  446    semantics of messages now being transmitted.  This also implies that
  447 
  448 
  449 
  450 Freed & Borenstein          Standards Track                     [Page 8]
  451 
  452 RFC 2046                      Media Types                  November 1996
  453 
  454 
  455    messages containing characters coded according to other versions of
  456    ISO 646 than US-ASCII and the 1991 IRV, or using code-switching
  457    procedures (e.g., those of ISO 2022), as well as 8bit or multiple
  458    octet character encodings MUST use an appropriate character set
  459    specification to be consistent with MIME.
  460 
  461    The complete US-ASCII character set is listed in ANSI X3.4- 1986.
  462    Note that the control characters including DEL (0-31, 127) have no
  463    defined meaning in apart from the combination CRLF (US-ASCII values
  464    13 and 10) indicating a new line.  Two of the characters have de
  465    facto meanings in wide use: FF (12) often means "start subsequent
  466    text on the beginning of a new page"; and TAB or HT (9) often (though
  467    not always) means "move the cursor to the next available column after
  468    the current position where the column number is a multiple of 8
  469    (counting the first column as column 0)."  Aside from these
  470    conventions, any use of the control characters or DEL in a body must
  471    either occur
  472 
  473     (1)   because a subtype of text other than "plain"
  474           specifically assigns some additional meaning, or
  475 
  476     (2)   within the context of a private agreement between the
  477           sender and recipient. Such private agreements are
  478           discouraged and should be replaced by the other
  479           capabilities of this document.
  480 
  481    NOTE: An enormous proliferation of character sets exist beyond US-
  482    ASCII.  A large number of partially or totally overlapping character
  483    sets is NOT a good thing.  A SINGLE character set that can be used
  484    universally for representing all of the world's languages in Internet
  485    mail would be preferrable.  Unfortunately, existing practice in
  486    several communities seems to point to the continued use of multiple
  487    character sets in the near future.  A small number of standard
  488    character sets are, therefore, defined for Internet use in this
  489    document.
  490 
  491    The defined charset values are:
  492 
  493     (1)   US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
  494 
  495     (2)   ISO-8859-X -- where "X" is to be replaced, as
  496           necessary, for the parts of ISO-8859 [ISO-8859].  Note
  497           that the ISO 646 character sets have deliberately been
  498           omitted in favor of their 8859 replacements, which are
  499           the designated character sets for Internet mail.  As of
  500           the publication of this document, the legitimate values
  501           for "X" are the digits 1 through 10.
  502 
  503 
  504 
  505 
  506 Freed & Borenstein          Standards Track                     [Page 9]
  507 
  508 RFC 2046                      Media Types                  November 1996
  509 
  510 
  511    Characters in the range 128-159 has no assigned meaning in ISO-8859-
  512    X.  Characters with values below 128 in ISO-8859-X have the same
  513    assigned meaning as they do in US-ASCII.
  514 
  515    Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew
  516    alphabet) includes both characters for which the normal writing
  517    direction is right to left and characters for which it is left to
  518    right, but do not define a canonical ordering method for representing
  519    bi-directional text.  The charset values "ISO-8859-6" and "ISO-8859-
  520    8", however, specify that the visual method is used [RFC-1556].
  521 
  522    All of these character sets are used as pure 7bit or 8bit sets
  523    without any shift or escape functions.  The meaning of shift and
  524    escape sequences in these character sets is not defined.
  525 
  526    The character sets specified above are the ones that were relatively
  527    uncontroversial during the drafting of MIME.  This document does not
  528    endorse the use of any particular character set other than US-ASCII,
  529    and recognizes that the future evolution of world character sets
  530    remains unclear.
  531 
  532    Note that the character set used, if anything other than US- ASCII,
  533    must always be explicitly specified in the Content-Type field.
  534 
  535    No character set name other than those defined above may be used in
  536    Internet mail without the publication of a formal specification and
  537    its registration with IANA, or by private agreement, in which case
  538    the character set name must begin with "X-".
  539 
  540    Implementors are discouraged from defining new character sets unless
  541    absolutely necessary.
  542 
  543    The "charset" parameter has been defined primarily for the purpose of
  544    textual data, and is described in this section for that reason.
  545    However, it is conceivable that non-textual data might also wish to
  546    specify a charset value for some purpose, in which case the same
  547    syntax and values should be used.
  548 
  549    In general, composition software should always use the "lowest common
  550    denominator" character set possible.  For example, if a body contains
  551    only US-ASCII characters, it SHOULD be marked as being in the US-
  552    ASCII character set, not ISO-8859-1, which, like all the ISO-8859
  553    family of character sets, is a superset of US-ASCII.  More generally,
  554    if a widely-used character set is a subset of another character set,
  555    and a body contains only characters in the widely-used subset, it
  556    should be labelled as being in that subset.  This will increase the
  557    chances that the recipient will be able to view the resulting entity
  558    correctly.
  559 
  560 
  561 
  562 Freed & Borenstein          Standards Track                    [Page 10]
  563 
  564 RFC 2046                      Media Types                  November 1996
  565 
  566 
  567 4.1.3.  Plain Subtype
  568 
  569    The simplest and most important subtype of "text" is "plain".  This
  570    indicates plain text that does not contain any formatting commands or
  571    directives. Plain text is intended to be displayed "as-is", that is,
  572    no interpretation of embedded formatting commands, font attribute
  573    specifications, processing instructions, interpretation directives,
  574    or content markup should be necessary for proper display.  The
  575    default media type of "text/plain; charset=us-ascii" for Internet
  576    mail describes existing Internet practice.  That is, it is the type
  577    of body defined by RFC 822.
  578 
  579    No other "text" subtype is defined by this document.
  580 
  581 4.1.4.  Unrecognized Subtypes
  582 
  583    Unrecognized subtypes of "text" should be treated as subtype "plain"
  584    as long as the MIME implementation knows how to handle the charset.
  585    Unrecognized subtypes which also specify an unrecognized charset
  586    should be treated as "application/octet- stream".
  587 
  588 4.2.  Image Media Type
  589 
  590    A media type of "image" indicates that the body contains an image.
  591    The subtype names the specific image format.  These names are not
  592    case sensitive. An initial subtype is "jpeg" for the JPEG format
  593    using JFIF encoding [JPEG].
  594 
  595    The list of "image" subtypes given here is neither exclusive nor
  596    exhaustive, and is expected to grow as more types are registered with
  597    IANA, as described in RFC 2048.
  598 
  599    Unrecognized subtypes of "image" should at a miniumum be treated as
  600    "application/octet-stream".  Implementations may optionally elect to
  601    pass subtypes of "image" that they do not specifically recognize to a
  602    secure and robust general-purpose image viewing application, if such
  603    an application is available.
  604 
  605    NOTE: Using of a generic-purpose image viewing application this way
  606    inherits the security problems of the most dangerous type supported
  607    by the application.
  608 
  609 4.3.  Audio Media Type
  610 
  611    A media type of "audio" indicates that the body contains audio data.
  612    Although there is not yet a consensus on an "ideal" audio format for
  613    use with computers, there is a pressing need for a format capable of
  614    providing interoperable behavior.
  615 
  616 
  617 
  618 Freed & Borenstein          Standards Track                    [Page 11]
  619 
  620 RFC 2046                      Media Types                  November 1996
  621 
  622 
  623    The initial subtype of "basic" is specified to meet this requirement
  624    by providing an absolutely minimal lowest common denominator audio
  625    format.  It is expected that richer formats for higher quality and/or
  626    lower bandwidth audio will be defined by a later document.
  627 
  628    The content of the "audio/basic" subtype is single channel audio
  629    encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz.
  630 
  631    Unrecognized subtypes of "audio" should at a miniumum be treated as
  632    "application/octet-stream".  Implementations may optionally elect to
  633    pass subtypes of "audio" that they do not specifically recognize to a
  634    robust general-purpose audio playing application, if such an
  635    application is available.
  636 
  637 4.4.  Video Media Type
  638 
  639    A media type of "video" indicates that the body contains a time-
  640    varying-picture image, possibly with color and coordinated sound.
  641    The term 'video' is used in its most generic sense, rather than with
  642    reference to any particular technology or format, and is not meant to
  643    preclude subtypes such as animated drawings encoded compactly.  The
  644    subtype "mpeg" refers to video coded according to the MPEG standard
  645    [MPEG].
  646 
  647    Note that although in general this document strongly discourages the
  648    mixing of multiple media in a single body, it is recognized that many
  649    so-called video formats include a representation for synchronized
  650    audio, and this is explicitly permitted for subtypes of "video".
  651 
  652    Unrecognized subtypes of "video" should at a minumum be treated as
  653    "application/octet-stream".  Implementations may optionally elect to
  654    pass subtypes of "video" that they do not specifically recognize to a
  655    robust general-purpose video display application, if such an
  656    application is available.
  657 
  658 4.5.  Application Media Type
  659 
  660    The "application" media type is to be used for discrete data which do
  661    not fit in any of the other categories, and particularly for data to
  662    be processed by some type of application program.  This is
  663    information which must be processed by an application before it is
  664    viewable or usable by a user.  Expected uses for the "application"
  665    media type include file transfer, spreadsheets, data for mail-based
  666    scheduling systems, and languages for "active" (computational)
  667    material.  (The latter, in particular, can pose security problems
  668    which must be understood by implementors, and are considered in
  669    detail in the discussion of the "application/PostScript" media type.)
  670 
  671 
  672 
  673 
  674 Freed & Borenstein          Standards Track                    [Page 12]
  675 
  676 RFC 2046                      Media Types                  November 1996
  677 
  678 
  679    For example, a meeting scheduler might define a standard
  680    representation for information about proposed meeting dates.  An
  681    intelligent user agent would use this information to conduct a dialog
  682    with the user, and might then send additional material based on that
  683    dialog.  More generally, there have been several "active" messaging
  684    languages developed in which programs in a suitably specialized
  685    language are transported to a remote location and automatically run
  686    in the recipient's environment.
  687 
  688    Such applications may be defined as subtypes of the "application"
  689    media type. This document defines two subtypes:
  690 
  691    octet-stream, and PostScript.
  692 
  693    The subtype of "application" will often be either the name or include
  694    part of the name of the application for which the data are intended.
  695    This does not mean, however, that any application program name may be
  696    used freely as a subtype of "application".
  697 
  698 4.5.1.  Octet-Stream Subtype
  699 
  700    The "octet-stream" subtype is used to indicate that a body contains
  701    arbitrary binary data.  The set of currently defined parameters is:
  702 
  703     (1)   TYPE -- the general type or category of binary data.
  704           This is intended as information for the human recipient
  705           rather than for any automatic processing.
  706 
  707     (2)   PADDING -- the number of bits of padding that were
  708           appended to the bit-stream comprising the actual
  709           contents to produce the enclosed 8bit byte-oriented
  710           data.  This is useful for enclosing a bit-stream in a
  711           body when the total number of bits is not a multiple of
  712           8.
  713 
  714    Both of these parameters are optional.
  715 
  716    An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
  717    has since been removed.  RFC 1341 also defined the use of a "NAME"
  718    parameter which gave a suggested file name to be used if the data
  719    were to be written to a file.  This has been deprecated in
  720    anticipation of a separate Content-Disposition header field, to be
  721    defined in a subsequent RFC.
  722 
  723    The recommended action for an implementation that receives an
  724    "application/octet-stream" entity is to simply offer to put the data
  725    in a file, with any Content-Transfer-Encoding undone, or perhaps to
  726    use it as input to a user-specified process.
  727 
  728 
  729 
  730 Freed & Borenstein          Standards Track                    [Page 13]
  731 
  732 RFC 2046                      Media Types                  November 1996
  733 
  734 
  735    To reduce the danger of transmitting rogue programs, it is strongly
  736    recommended that implementations NOT implement a path-search
  737    mechanism whereby an arbitrary program named in the Content-Type
  738    parameter (e.g., an "interpreter=" parameter) is found and executed
  739    using the message body as input.
  740 
  741 4.5.2.  PostScript Subtype
  742 
  743    A media type of "application/postscript" indicates a PostScript
  744    program.  Currently two variants of the PostScript language are
  745    allowed; the original level 1 variant is described in [POSTSCRIPT]
  746    and the more recent level 2 variant is described in [POSTSCRIPT2].
  747 
  748    PostScript is a registered trademark of Adobe Systems, Inc.  Use of
  749    the MIME media type "application/postscript" implies recognition of
  750    that trademark and all the rights it entails.
  751 
  752    The PostScript language definition provides facilities for internal
  753    labelling of the specific language features a given program uses.
  754    This labelling, called the PostScript document structuring
  755    conventions, or DSC, is very general and provides substantially more
  756    information than just the language level.  The use of document
  757    structuring conventions, while not required, is strongly recommended
  758    as an aid to interoperability.  Documents which lack proper
  759    structuring conventions cannot be tested to see whether or not they
  760    will work in a given environment.  As such, some systems may assume
  761    the worst and refuse to process unstructured documents.
  762 
  763    The execution of general-purpose PostScript interpreters entails
  764    serious security risks, and implementors are discouraged from simply
  765    sending PostScript bodies to "off- the-shelf" interpreters.  While it
  766    is usually safe to send PostScript to a printer, where the potential
  767    for harm is greatly constrained by typical printer environments,
  768    implementors should consider all of the following before they add
  769    interactive display of PostScript bodies to their MIME readers.
  770 
  771    The remainder of this section outlines some, though probably not all,
  772    of the possible problems with the transport of PostScript entities.
  773 
  774     (1)   Dangerous operations in the PostScript language
  775           include, but may not be limited to, the PostScript
  776           operators "deletefile", "renamefile", "filenameforall",
  777           and "file".  "File" is only dangerous when applied to
  778           something other than standard input or output.
  779           Implementations may also define additional nonstandard
  780           file operators; these may also pose a threat to
  781           security. "Filenameforall", the wildcard file search
  782           operator, may appear at first glance to be harmless.
  783 
  784 
  785 
  786 Freed & Borenstein          Standards Track                    [Page 14]
  787 
  788 RFC 2046                      Media Types                  November 1996
  789 
  790 
  791           Note, however, that this operator has the potential to
  792           reveal information about what files the recipient has
  793           access to, and this information may itself be
  794           sensitive.  Message senders should avoid the use of
  795           potentially dangerous file operators, since these
  796           operators are quite likely to be unavailable in secure
  797           PostScript implementations.  Message receiving and
  798           displaying software should either completely disable
  799           all potentially dangerous file operators or take
  800           special care not to delegate any special authority to
  801           their operation.  These operators should be viewed as
  802           being done by an outside agency when interpreting
  803           PostScript documents.  Such disabling and/or checking
  804           should be done completely outside of the reach of the
  805           PostScript language itself; care should be taken to
  806           insure that no method exists for re-enabling full-
  807           function versions of these operators.
  808 
  809     (2)   The PostScript language provides facilities for exiting
  810           the normal interpreter, or server, loop.  Changes made
  811           in this "outer" environment are customarily retained
  812           across documents, and may in some cases be retained
  813           semipermanently in nonvolatile memory.  The operators
  814           associated with exiting the interpreter loop have the
  815           potential to interfere with subsequent document
  816           processing.  As such, their unrestrained use
  817           constitutes a threat of service denial.  PostScript
  818           operators that exit the interpreter loop include, but
  819           may not be limited to, the exitserver and startjob
  820           operators.  Message sending software should not
  821           generate PostScript that depends on exiting the
  822           interpreter loop to operate, since the ability to exit
  823           will probably be unavailable in secure PostScript
  824           implementations.  Message receiving and displaying
  825           software should completely disable the ability to make
  826           retained changes to the PostScript environment by
  827           eliminating or disabling the "startjob" and
  828           "exitserver" operations.  If these operations cannot be
  829           eliminated or completely disabled the password
  830           associated with them should at least be set to a hard-
  831           to-guess value.
  832 
  833     (3)   PostScript provides operators for setting system-wide
  834           and device-specific parameters.  These parameter
  835           settings may be retained across jobs and may
  836           potentially pose a threat to the correct operation of
  837           the interpreter.  The PostScript operators that set
  838           system and device parameters include, but may not be
  839 
  840 
  841 
  842 Freed & Borenstein          Standards Track                    [Page 15]
  843 
  844 RFC 2046                      Media Types                  November 1996
  845 
  846 
  847           limited to, the "setsystemparams" and "setdevparams"
  848           operators.  Message sending software should not
  849           generate PostScript that depends on the setting of
  850           system or device parameters to operate correctly.  The
  851           ability to set these parameters will probably be
  852           unavailable in secure PostScript implementations.
  853           Message receiving and displaying software should
  854           disable the ability to change system and device
  855           parameters.  If these operators cannot be completely
  856           disabled the password associated with them should at
  857           least be set to a hard-to-guess value.
  858 
  859     (4)   Some PostScript implementations provide nonstandard
  860           facilities for the direct loading and execution of
  861           machine code.  Such facilities are quite obviously open
  862           to substantial abuse.  Message sending software should
  863           not make use of such features.  Besides being totally
  864           hardware-specific, they are also likely to be
  865           unavailable in secure implementations of PostScript.
  866           Message receiving and displaying software should not
  867           allow such operators to be used if they exist.
  868 
  869     (5)   PostScript is an extensible language, and many, if not
  870           most, implementations of it provide a number of their
  871           own extensions.  This document does not deal with such
  872           extensions explicitly since they constitute an unknown
  873           factor.  Message sending software should not make use
  874           of nonstandard extensions; they are likely to be
  875           missing from some implementations.  Message receiving
  876           and displaying software should make sure that any
  877           nonstandard PostScript operators are secure and don't
  878           present any kind of threat.
  879 
  880     (6)   It is possible to write PostScript that consumes huge
  881           amounts of various system resources.  It is also
  882           possible to write PostScript programs that loop
  883           indefinitely.  Both types of programs have the
  884           potential to cause damage if sent to unsuspecting
  885           recipients.  Message-sending software should avoid the
  886           construction and dissemination of such programs, which
  887           is antisocial.  Message receiving and displaying
  888           software should provide appropriate mechanisms to abort
  889           processing after a reasonable amount of time has
  890           elapsed. In addition, PostScript interpreters should be
  891           limited to the consumption of only a reasonable amount
  892           of any given system resource.
  893 
  894 
  895 
  896 
  897 
  898 Freed & Borenstein          Standards Track                    [Page 16]
  899 
  900 RFC 2046                      Media Types                  November 1996
  901 
  902 
  903     (7)   It is possible to include raw binary information inside
  904           PostScript in various forms.  This is not recommended
  905           for use in Internet mail, both because it is not
  906           supported by all PostScript interpreters and because it
  907           significantly complicates the use of a MIME Content-
  908           Transfer-Encoding.  (Without such binary, PostScript
  909           may typically be viewed as line-oriented data.  The
  910           treatment of CRLF sequences becomes extremely
  911           problematic if binary and line-oriented data are mixed
  912           in a single Postscript data stream.)
  913 
  914     (8)   Finally, bugs may exist in some PostScript interpreters
  915           which could possibly be exploited to gain unauthorized
  916           access to a recipient's system.  Apart from noting this
  917           possibility, there is no specific action to take to
  918           prevent this, apart from the timely correction of such
  919           bugs if any are found.
  920 
  921 4.5.3.  Other Application Subtypes
  922 
  923    It is expected that many other subtypes of "application" will be
  924    defined in the future.  MIME implementations must at a minimum treat
  925    any unrecognized subtypes as being equivalent to "application/octet-
  926    stream".
  927 
  928 5.  Composite Media Type Values
  929 
  930    The remaining two of the seven initial Content-Type values refer to
  931    composite entities.  Composite entities are handled using MIME
  932    mechanisms -- a MIME processor typically handles the body directly.
  933 
  934 5.1.  Multipart Media Type
  935 
  936    In the case of multipart entities, in which one or more different
  937    sets of data are combined in a single body, a "multipart" media type
  938    field must appear in the entity's header.  The body must then contain
  939    one or more body parts, each preceded by a boundary delimiter line,
  940    and the last one followed by a closing boundary delimiter line.
  941    After its boundary delimiter line, each body part then consists of a
  942    header area, a blank line, and a body area.  Thus a body part is
  943    similar to an RFC 822 message in syntax, but different in meaning.
  944 
  945    A body part is an entity and hence is NOT to be interpreted as
  946    actually being an RFC 822 message.  To begin with, NO header fields
  947    are actually required in body parts.  A body part that starts with a
  948    blank line, therefore, is allowed and is a body part for which all
  949    default values are to be assumed.  In such a case, the absence of a
  950    Content-Type header usually indicates that the corresponding body has
  951 
  952 
  953 
  954 Freed & Borenstein          Standards Track                    [Page 17]
  955 
  956 RFC 2046                      Media Types                  November 1996
  957 
  958 
  959    a content-type of "text/plain; charset=US-ASCII".
  960 
  961    The only header fields that have defined meaning for body parts are
  962    those the names of which begin with "Content-".  All other header
  963    fields may be ignored in body parts.  Although they should generally
  964    be retained if at all possible, they may be discarded by gateways if
  965    necessary.  Such other fields are permitted to appear in body parts
  966    but must not be depended on.  "X-" fields may be created for
  967    experimental or private purposes, with the recognition that the
  968    information they contain may be lost at some gateways.
  969 
  970    NOTE:  The distinction between an RFC 822 message and a body part is
  971    subtle, but important.  A gateway between Internet and X.400 mail,
  972    for example, must be able to tell the difference between a body part
  973    that contains an image and a body part that contains an encapsulated
  974    message, the body of which is a JPEG image.  In order to represent
  975    the latter, the body part must have "Content-Type: message/rfc822",
  976    and its body (after the blank line) must be the encapsulated message,
  977    with its own "Content-Type: image/jpeg" header field.  The use of
  978    similar syntax facilitates the conversion of messages to body parts,
  979    and vice versa, but the distinction between the two must be
  980    understood by implementors.  (For the special case in which parts
  981    actually are messages, a "digest" subtype is also defined.)
  982 
  983    As stated previously, each body part is preceded by a boundary
  984    delimiter line that contains the boundary delimiter.  The boundary
  985    delimiter MUST NOT appear inside any of the encapsulated parts, on a
  986    line by itself or as the prefix of any line.  This implies that it is
  987    crucial that the composing agent be able to choose and specify a
  988    unique boundary parameter value that does not contain the boundary
  989    parameter value of an enclosing multipart as a prefix.
  990 
  991    All present and future subtypes of the "multipart" type must use an
  992    identical syntax.  Subtypes may differ in their semantics, and may
  993    impose additional restrictions on syntax, but must conform to the
  994    required syntax for the "multipart" type.  This requirement ensures
  995    that all conformant user agents will at least be able to recognize
  996    and separate the parts of any multipart entity, even those of an
  997    unrecognized subtype.
  998 
  999    As stated in the definition of the Content-Transfer-Encoding field
 1000    [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is
 1001    permitted for entities of type "multipart".  The "multipart" boundary
 1002    delimiters and header fields are always represented as 7bit US-ASCII
 1003    in any case (though the header fields may encode non-US-ASCII header
 1004    text as per RFC 2047) and data within the body parts can be encoded
 1005    on a part-by-part basis, with Content-Transfer-Encoding fields for
 1006    each appropriate body part.
 1007 
 1008 
 1009 
 1010 Freed & Borenstein          Standards Track                    [Page 18]
 1011 
 1012 RFC 2046                      Media Types                  November 1996
 1013 
 1014 
 1015 5.1.1.  Common Syntax
 1016 
 1017    This section defines a common syntax for subtypes of "multipart".
 1018    All subtypes of "multipart" must use this syntax.  A simple example
 1019    of a multipart message also appears in this section.  An example of a
 1020    more complex multipart message is given in RFC 2049.
 1021 
 1022    The Content-Type field for multipart entities requires one parameter,
 1023    "boundary". The boundary delimiter line is then defined as a line
 1024    consisting entirely of two hyphen characters ("-", decimal value 45)
 1025    followed by the boundary parameter value from the Content-Type header
 1026    field, optional linear whitespace, and a terminating CRLF.
 1027 
 1028    NOTE:  The hyphens are for rough compatibility with the earlier RFC
 1029    934 method of message encapsulation, and for ease of searching for
 1030    the boundaries in some implementations.  However, it should be noted
 1031    that multipart messages are NOT completely compatible with RFC 934
 1032    encapsulations; in particular, they do not obey RFC 934 quoting
 1033    conventions for embedded lines that begin with hyphens.  This
 1034    mechanism was chosen over the RFC 934 mechanism because the latter
 1035    causes lines to grow with each level of quoting.  The combination of
 1036    this growth with the fact that SMTP implementations sometimes wrap
 1037    long lines made the RFC 934 mechanism unsuitable for use in the event
 1038    that deeply-nested multipart structuring is ever desired.
 1039 
 1040    WARNING TO IMPLEMENTORS:  The grammar for parameters on the Content-
 1041    type field is such that it is often necessary to enclose the boundary
 1042    parameter values in quotes on the Content-type line.  This is not
 1043    always necessary, but never hurts. Implementors should be sure to
 1044    study the grammar carefully in order to avoid producing invalid
 1045    Content-type fields.  Thus, a typical "multipart" Content-Type header
 1046    field might look like this:
 1047 
 1048      Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
 1049 
 1050    But the following is not valid:
 1051 
 1052      Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
 1053 
 1054    (because of the colon) and must instead be represented as
 1055 
 1056      Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
 1057 
 1058    This Content-Type value indicates that the content consists of one or
 1059    more parts, each with a structure that is syntactically identical to
 1060    an RFC 822 message, except that the header area is allowed to be
 1061    completely empty, and that the parts are each preceded by the line
 1062 
 1063 
 1064 
 1065 
 1066 Freed & Borenstein          Standards Track                    [Page 19]
 1067 
 1068 RFC 2046                      Media Types                  November 1996
 1069 
 1070 
 1071      --gc0pJq0M:08jU534c0p
 1072 
 1073    The boundary delimiter MUST occur at the beginning of a line, i.e.,
 1074    following a CRLF, and the initial CRLF is considered to be attached
 1075    to the boundary delimiter line rather than part of the preceding
 1076    part.  The boundary may be followed by zero or more characters of
 1077    linear whitespace. It is then terminated by either another CRLF and
 1078    the header fields for the next part, or by two CRLFs, in which case
 1079    there are no header fields for the next part.  If no Content-Type
 1080    field is present it is assumed to be "message/rfc822" in a
 1081    "multipart/digest" and "text/plain" otherwise.
 1082 
 1083    NOTE:  The CRLF preceding the boundary delimiter line is conceptually
 1084    attached to the boundary so that it is possible to have a part that
 1085    does not end with a CRLF (line  break).  Body parts that must be
 1086    considered to end with line breaks, therefore, must have two CRLFs
 1087    preceding the boundary delimiter line, the first of which is part of
 1088    the preceding body part, and the second of which is part of the
 1089    encapsulation boundary.
 1090 
 1091    Boundary delimiters must not appear within the encapsulated material,
 1092    and must be no longer than 70 characters, not counting the two
 1093    leading hyphens.
 1094 
 1095    The boundary delimiter line following the last body part is a
 1096    distinguished delimiter that indicates that no further body parts
 1097    will follow.  Such a delimiter line is identical to the previous
 1098    delimiter lines, with the addition of two more hyphens after the
 1099    boundary parameter value.
 1100 
 1101      --gc0pJq0M:08jU534c0p--
 1102 
 1103    NOTE TO IMPLEMENTORS:  Boundary string comparisons must compare the
 1104    boundary value with the beginning of each candidate line.  An exact
 1105    match of the entire candidate line is not required; it is sufficient
 1106    that the boundary appear in its entirety following the CRLF.
 1107 
 1108    There appears to be room for additional information prior to the
 1109    first boundary delimiter line and following the final boundary
 1110    delimiter line.  These areas should generally be left blank, and
 1111    implementations must ignore anything that appears before the first
 1112    boundary delimiter line or after the last one.
 1113 
 1114    NOTE:  These "preamble" and "epilogue" areas are generally not used
 1115    because of the lack of proper typing of these parts and the lack of
 1116    clear semantics for handling these areas at gateways, particularly
 1117    X.400 gateways.  However, rather than leaving the preamble area
 1118    blank, many MIME implementations have found this to be a convenient
 1119 
 1120 
 1121 
 1122 Freed & Borenstein          Standards Track                    [Page 20]
 1123 
 1124 RFC 2046                      Media Types                  November 1996
 1125 
 1126 
 1127    place to insert an explanatory note for recipients who read the
 1128    message with pre-MIME software, since such notes will be ignored by
 1129    MIME-compliant software.
 1130 
 1131    NOTE:  Because boundary delimiters must not appear in the body parts
 1132    being encapsulated, a user agent must exercise care to choose a
 1133    unique boundary parameter value.  The boundary parameter value in the
 1134    example above could have been the result of an algorithm designed to
 1135    produce boundary delimiters with a very low probability of already
 1136    existing in the data to be encapsulated without having to prescan the
 1137    data.  Alternate algorithms might result in more "readable" boundary
 1138    delimiters for a recipient with an old user agent, but would require
 1139    more attention to the possibility that the boundary delimiter might
 1140    appear at the beginning of some line in the encapsulated part.  The
 1141    simplest boundary delimiter line possible is something like "---",
 1142    with a closing boundary delimiter line of "-----".
 1143 
 1144    As a very simple example, the following multipart message has two
 1145    parts, both of them plain text, one of them explicitly typed and one
 1146    of them implicitly typed:
 1147 
 1148      From: Nathaniel Borenstein <nsb@bellcore.com>
 1149      To: Ned Freed <ned@innosoft.com>
 1150      Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
 1151      Subject: Sample message
 1152      MIME-Version: 1.0
 1153      Content-type: multipart/mixed; boundary="simple boundary"
 1154 
 1155      This is the preamble.  It is to be ignored, though it
 1156      is a handy place for composition agents to include an
 1157      explanatory note to non-MIME conformant readers.
 1158 
 1159      --simple boundary
 1160 
 1161      This is implicitly typed plain US-ASCII text.
 1162      It does NOT end with a linebreak.
 1163      --simple boundary
 1164      Content-type: text/plain; charset=us-ascii
 1165 
 1166      This is explicitly typed plain US-ASCII text.
 1167      It DOES end with a linebreak.
 1168 
 1169      --simple boundary--
 1170 
 1171      This is the epilogue.  It is also to be ignored.
 1172 
 1173 
 1174 
 1175 
 1176 
 1177 
 1178 Freed & Borenstein          Standards Track                    [Page 21]
 1179 
 1180 RFC 2046                      Media Types                  November 1996
 1181 
 1182 
 1183    The use of a media type of "multipart" in a body part within another
 1184    "multipart" entity is explicitly allowed.  In such cases, for obvious
 1185    reasons, care must be taken to ensure that each nested "multipart"
 1186    entity uses a different boundary delimiter.  See RFC 2049 for an
 1187    example of nested "multipart" entities.
 1188 
 1189    The use of the "multipart" media type with only a single body part
 1190    may be useful in certain contexts, and is explicitly permitted.
 1191 
 1192    NOTE: Experience has shown that a "multipart" media type with a
 1193    single body part is useful for sending non-text media types.  It has
 1194    the advantage of providing the preamble as a place to include
 1195    decoding instructions.  In addition, a number of SMTP gateways move
 1196    or remove the MIME headers, and a clever MIME decoder can take a good
 1197    guess at multipart boundaries even in the absence of the Content-Type
 1198    header and thereby successfully decode the message.
 1199 
 1200    The only mandatory global parameter for the "multipart" media type is
 1201    the boundary parameter, which consists of 1 to 70 characters from a
 1202    set of characters known to be very robust through mail gateways, and
 1203    NOT ending with white space. (If a boundary delimiter line appears to
 1204    end with white space, the white space must be presumed to have been
 1205    added by a gateway, and must be deleted.)  It is formally specified
 1206    by the following BNF:
 1207 
 1208      boundary := 0*69<bchars> bcharsnospace
 1209 
 1210      bchars := bcharsnospace / " "
 1211 
 1212      bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
 1213                       "+" / "_" / "," / "-" / "." /
 1214                       "/" / ":" / "=" / "?"
 1215 
 1216    Overall, the body of a "multipart" entity may be specified as
 1217    follows:
 1218 
 1219      dash-boundary := "--" boundary
 1220                       ; boundary taken from the value of
 1221                       ; boundary parameter of the
 1222                       ; Content-Type field.
 1223 
 1224      multipart-body := [preamble CRLF]
 1225                        dash-boundary transport-padding CRLF
 1226                        body-part *encapsulation
 1227                        close-delimiter transport-padding
 1228                        [CRLF epilogue]
 1229 
 1230 
 1231 
 1232 
 1233 
 1234 Freed & Borenstein          Standards Track                    [Page 22]
 1235 
 1236 RFC 2046                      Media Types                  November 1996
 1237 
 1238 
 1239      transport-padding := *LWSP-char
 1240                           ; Composers MUST NOT generate
 1241                           ; non-zero length transport
 1242                           ; padding, but receivers MUST
 1243                           ; be able to handle padding
 1244                           ; added by message transports.
 1245 
 1246      encapsulation := delimiter transport-padding
 1247                       CRLF body-part
 1248 
 1249      delimiter := CRLF dash-boundary
 1250 
 1251      close-delimiter := delimiter "--"
 1252 
 1253      preamble := discard-text
 1254 
 1255      epilogue := discard-text
 1256 
 1257      discard-text := *(*text CRLF) *text
 1258                      ; May be ignored or discarded.
 1259 
 1260      body-part := MIME-part-headers [CRLF *OCTET]
 1261                   ; Lines in a body-part must not start
 1262                   ; with the specified dash-boundary and
 1263                   ; the delimiter must not appear anywhere
 1264                   ; in the body part.  Note that the
 1265                   ; semantics of a body-part differ from
 1266                   ; the semantics of a message, as
 1267                   ; described in the text.
 1268 
 1269      OCTET := <any 0-255 octet value>
 1270 
 1271    IMPORTANT:  The free insertion of linear-white-space and RFC 822
 1272    comments between the elements shown in this BNF is NOT allowed since
 1273    this BNF does not specify a structured header field.
 1274 
 1275    NOTE:  In certain transport enclaves, RFC 822 restrictions such as
 1276    the one that limits bodies to printable US-ASCII characters may not
 1277    be in force. (That is, the transport domains may exist that resemble
 1278    standard Internet mail transport as specified in RFC 821 and assumed
 1279    by RFC 822, but without certain restrictions.) The relaxation of
 1280    these restrictions should be construed as locally extending the
 1281    definition of bodies, for example to include octets outside of the
 1282    US-ASCII range, as long as these extensions are supported by the
 1283    transport and adequately documented in the Content- Transfer-Encoding
 1284    header field.  However, in no event are headers (either message
 1285    headers or body part headers) allowed to contain anything other than
 1286    US-ASCII characters.
 1287 
 1288 
 1289 
 1290 Freed & Borenstein          Standards Track                    [Page 23]
 1291 
 1292 RFC 2046                      Media Types                  November 1996
 1293 
 1294 
 1295    NOTE:  Conspicuously missing from the "multipart" type is a notion of
 1296    structured, related body parts. It is recommended that those wishing
 1297    to provide more structured or integrated multipart messaging
 1298    facilities should define subtypes of multipart that are syntactically
 1299    identical but define relationships between the various parts. For
 1300    example, subtypes of multipart could be defined that include a
 1301    distinguished part which in turn is used to specify the relationships
 1302    between the other parts, probably referring to them by their
 1303    Content-ID field.  Old implementations will not recognize the new
 1304    subtype if this approach is used, but will treat it as
 1305    multipart/mixed and will thus be able to show the user the parts that
 1306    are recognized.
 1307 
 1308 5.1.2.  Handling Nested Messages and Multiparts
 1309 
 1310    The "message/rfc822" subtype defined in a subsequent section of this
 1311    document has no terminating condition other than running out of data.
 1312    Similarly, an improperly truncated "multipart" entity may not have
 1313    any terminating boundary marker, and can turn up operationally due to
 1314    mail system malfunctions.
 1315 
 1316    It is essential that such entities be handled correctly when they are
 1317    themselves imbedded inside of another "multipart" structure.  MIME
 1318    implementations are therefore required to recognize outer level
 1319    boundary markers at ANY level of inner nesting.  It is not sufficient
 1320    to only check for the next expected marker or other terminating
 1321    condition.
 1322 
 1323 5.1.3.  Mixed Subtype
 1324 
 1325    The "mixed" subtype of "multipart" is intended for use when the body
 1326    parts are independent and need to be bundled in a particular order.
 1327    Any "multipart" subtypes that an implementation does not recognize
 1328    must be treated as being of subtype "mixed".
 1329 
 1330 5.1.4.  Alternative Subtype
 1331 
 1332    The "multipart/alternative" type is syntactically identical to
 1333    "multipart/mixed", but the semantics are different.  In particular,
 1334    each of the body parts is an "alternative" version of the same
 1335    information.
 1336 
 1337    Systems should recognize that the content of the various parts are
 1338    interchangeable.  Systems should choose the "best" type based on the
 1339    local environment and references, in some cases even through user
 1340    interaction.  As with "multipart/mixed", the order of body parts is
 1341    significant.  In this case, the alternatives appear in an order of
 1342    increasing faithfulness to the original content.  In general, the
 1343 
 1344 
 1345 
 1346 Freed & Borenstein          Standards Track                    [Page 24]
 1347 
 1348 RFC 2046                      Media Types                  November 1996
 1349 
 1350 
 1351    best choice is the LAST part of a type supported by the recipient
 1352    system's local environment.
 1353 
 1354    "Multipart/alternative" may be used, for example, to send a message
 1355    in a fancy text format in such a way that it can easily be displayed
 1356    anywhere:
 1357 
 1358      From: Nathaniel Borenstein <nsb@bellcore.com>
 1359      To: Ned Freed <ned@innosoft.com>
 1360      Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
 1361      Subject: Formatted text mail
 1362      MIME-Version: 1.0
 1363      Content-Type: multipart/alternative; boundary=boundary42
 1364 
 1365      --boundary42
 1366      Content-Type: text/plain; charset=us-ascii
 1367 
 1368        ... plain text version of message goes here ...
 1369 
 1370      --boundary42
 1371      Content-Type: text/enriched
 1372 
 1373        ... RFC 1896 text/enriched version of same message
 1374            goes here ...
 1375 
 1376      --boundary42
 1377      Content-Type: application/x-whatever
 1378 
 1379        ... fanciest version of same message goes here ...
 1380 
 1381      --boundary42--
 1382 
 1383    In this example, users whose mail systems understood the
 1384    "application/x-whatever" format would see only the fancy version,
 1385    while other users would see only the enriched or plain text version,
 1386    depending on the capabilities of their system.
 1387 
 1388    In general, user agents that compose "multipart/alternative" entities
 1389    must place the body parts in increasing order of preference, that is,
 1390    with the preferred format last.  For fancy text, the sending user
 1391    agent should put the plainest format first and the richest format
 1392    last.  Receiving user agents should pick and display the last format
 1393    they are capable of displaying.  In the case where one of the
 1394    alternatives is itself of type "multipart" and contains unrecognized
 1395    sub-parts, the user agent may choose either to show that alternative,
 1396    an earlier alternative, or both.
 1397 
 1398 
 1399 
 1400 
 1401 
 1402 Freed & Borenstein          Standards Track                    [Page 25]
 1403 
 1404 RFC 2046                      Media Types                  November 1996
 1405 
 1406 
 1407    NOTE: From an implementor's perspective, it might seem more sensible
 1408    to reverse this ordering, and have the plainest alternative last.
 1409    However, placing the plainest alternative first is the friendliest
 1410    possible option when "multipart/alternative" entities are viewed
 1411    using a non-MIME-conformant viewer.  While this approach does impose
 1412    some burden on conformant MIME viewers, interoperability with older
 1413    mail readers was deemed to be more important in this case.
 1414 
 1415    It may be the case that some user agents, if they can recognize more
 1416    than one of the formats, will prefer to offer the user the choice of
 1417    which format to view.  This makes sense, for example, if a message
 1418    includes both a nicely- formatted image version and an easily-edited
 1419    text version.  What is most critical, however, is that the user not
 1420    automatically be shown multiple versions of the same data.  Either
 1421    the user should be shown the last recognized version or should be
 1422    given the choice.
 1423 
 1424    THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE:  Each part of a
 1425    "multipart/alternative" entity represents the same data, but the
 1426    mappings between the two are not necessarily without information
 1427    loss.  For example, information is lost when translating ODA to
 1428    PostScript or plain text.  It is recommended that each part should
 1429    have a different Content-ID value in the case where the information
 1430    content of the two parts is not identical.  And when the information
 1431    content is identical -- for example, where several parts of type
 1432    "message/external-body" specify alternate ways to access the
 1433    identical data -- the same Content-ID field value should be used, to
 1434    optimize any caching mechanisms that might be present on the
 1435    recipient's end.  However, the Content-ID values used by the parts
 1436    should NOT be the same Content-ID value that describes the
 1437    "multipart/alternative" as a whole, if there is any such Content-ID
 1438    field.  That is, one Content-ID value will refer to the
 1439    "multipart/alternative" entity, while one or more other Content-ID
 1440    values will refer to the parts inside it.
 1441 
 1442 5.1.5.  Digest Subtype
 1443 
 1444    This document defines a "digest" subtype of the "multipart" Content-
 1445    Type.  This type is syntactically identical to "multipart/mixed", but
 1446    the semantics are different.  In particular, in a digest, the default
 1447    Content-Type value for a body part is changed from "text/plain" to
 1448    "message/rfc822".  This is done to allow a more readable digest
 1449    format that is largely compatible (except for the quoting convention)
 1450    with RFC 934.
 1451 
 1452    Note: Though it is possible to specify a Content-Type value for a
 1453    body part in a digest which is other than "message/rfc822", such as a
 1454    "text/plain" part containing a description of the material in the
 1455 
 1456 
 1457 
 1458 Freed & Borenstein          Standards Track                    [Page 26]
 1459 
 1460 RFC 2046                      Media Types                  November 1996
 1461 
 1462 
 1463    digest, actually doing so is undesireble. The "multipart/digest"
 1464    Content-Type is intended to be used to send collections of messages.
 1465    If a "text/plain" part is needed, it should be included as a seperate
 1466    part of a "multipart/mixed" message.
 1467 
 1468    A digest in this format might, then, look something like this:
 1469 
 1470      From: Moderator-Address
 1471      To: Recipient-List
 1472      Date: Mon, 22 Mar 1994 13:34:51 +0000
 1473      Subject: Internet Digest, volume 42
 1474      MIME-Version: 1.0
 1475      Content-Type: multipart/mixed;
 1476                    boundary="---- main boundary ----"
 1477 
 1478      ------ main boundary ----
 1479 
 1480        ...Introductory text or table of contents...
 1481 
 1482      ------ main boundary ----
 1483      Content-Type: multipart/digest;
 1484                    boundary="---- next message ----"
 1485 
 1486      ------ next message ----
 1487 
 1488      From: someone-else
 1489      Date: Fri, 26 Mar 1993 11:13:32 +0200
 1490      Subject: my opinion
 1491 
 1492        ...body goes here ...
 1493 
 1494      ------ next message ----
 1495 
 1496      From: someone-else-again
 1497      Date: Fri, 26 Mar 1993 10:07:13 -0500
 1498      Subject: my different opinion
 1499 
 1500        ... another body goes here ...
 1501 
 1502      ------ next message ------
 1503 
 1504      ------ main boundary ------
 1505 
 1506 5.1.6.  Parallel Subtype
 1507 
 1508    This document defines a "parallel" subtype of the "multipart"
 1509    Content-Type.  This type is syntactically identical to
 1510    "multipart/mixed", but the semantics are different.  In particular,
 1511 
 1512 
 1513 
 1514 Freed & Borenstein          Standards Track                    [Page 27]
 1515 
 1516 RFC 2046                      Media Types                  November 1996
 1517 
 1518 
 1519    in a parallel entity, the order of body parts is not significant.
 1520 
 1521    A common presentation of this type is to display all of the parts
 1522    simultaneously on hardware and software that are capable of doing so.
 1523    However, composing agents should be aware that many mail readers will
 1524    lack this capability and will show the parts serially in any event.
 1525 
 1526 5.1.7.  Other Multipart Subtypes
 1527 
 1528    Other "multipart" subtypes are expected in the future.  MIME
 1529    implementations must in general treat unrecognized subtypes of
 1530    "multipart" as being equivalent to "multipart/mixed".
 1531 
 1532 5.2.  Message Media Type
 1533 
 1534    It is frequently desirable, in sending mail, to encapsulate another
 1535    mail message.  A special media type, "message", is defined to
 1536    facilitate this.  In particular, the "rfc822" subtype of "message" is
 1537    used to encapsulate RFC 822 messages.
 1538 
 1539    NOTE:  It has been suggested that subtypes of "message" might be
 1540    defined for forwarded or rejected messages.  However, forwarded and
 1541    rejected messages can be handled as multipart messages in which the
 1542    first part contains any control or descriptive information, and a
 1543    second part, of type "message/rfc822", is the forwarded or rejected
 1544    message.  Composing rejection and forwarding messages in this manner
 1545    will preserve the type information on the original message and allow
 1546    it to be correctly presented to the recipient, and hence is strongly
 1547    encouraged.
 1548 
 1549    Subtypes of "message" often impose restrictions on what encodings are
 1550    allowed.  These restrictions are described in conjunction with each
 1551    specific subtype.
 1552 
 1553    Mail gateways, relays, and other mail handling agents are commonly
 1554    known to alter the top-level header of an RFC 822 message.  In
 1555    particular, they frequently add, remove, or reorder header fields.
 1556    These operations are explicitly forbidden for the encapsulated
 1557    headers embedded in the bodies of messages of type "message."
 1558 
 1559 5.2.1.  RFC822 Subtype
 1560 
 1561    A media type of "message/rfc822" indicates that the body contains an
 1562    encapsulated message, with the syntax of an RFC 822 message.
 1563    However, unlike top-level RFC 822 messages, the restriction that each
 1564    "message/rfc822" body must include a "From", "Date", and at least one
 1565    destination header is removed and replaced with the requirement that
 1566    at least one of "From", "Subject", or "Date" must be present.
 1567 
 1568 
 1569 
 1570 Freed & Borenstein          Standards Track                    [Page 28]
 1571 
 1572 RFC 2046                      Media Types                  November 1996
 1573 
 1574 
 1575    It should be noted that, despite the use of the numbers "822", a
 1576    "message/rfc822" entity isn't restricted to material in strict
 1577    conformance to RFC822, nor are the semantics of "message/rfc822"
 1578    objects restricted to the semantics defined in RFC822. More
 1579    specifically, a "message/rfc822" message could well be a News article
 1580    or a MIME message.
 1581 
 1582    No encoding other than "7bit", "8bit", or "binary" is permitted for
 1583    the body of a "message/rfc822" entity.  The message header fields are
 1584    always US-ASCII in any case, and data within the body can still be
 1585    encoded, in which case the Content-Transfer-Encoding header field in
 1586    the encapsulated message will reflect this.  Non-US-ASCII text in the
 1587    headers of an encapsulated message can be specified using the
 1588    mechanisms described in RFC 2047.
 1589 
 1590 5.2.2.  Partial Subtype
 1591 
 1592    The "partial" subtype is defined to allow large entities to be
 1593    delivered as several separate pieces of mail and automatically
 1594    reassembled by a receiving user agent.  (The concept is similar to IP
 1595    fragmentation and reassembly in the basic Internet Protocols.)  This
 1596    mechanism can be used when intermediate transport agents limit the
 1597    size of individual messages that can be sent.  The media type
 1598    "message/partial" thus indicates that the body contains a fragment of
 1599    a larger entity.
 1600 
 1601    Because data of type "message" may never be encoded in base64 or
 1602    quoted-printable, a problem might arise if "message/partial" entities
 1603    are constructed in an environment that supports binary or 8bit
 1604    transport.  The problem is that the binary data would be split into
 1605    multiple "message/partial" messages, each of them requiring binary
 1606    transport.  If such messages were encountered at a gateway into a
 1607    7bit transport environment, there would be no way to properly encode
 1608    them for the 7bit world, aside from waiting for all of the fragments,
 1609    reassembling the inner message, and then encoding the reassembled
 1610    data in base64 or quoted-printable.  Since it is possible that
 1611    different fragments might go through different gateways, even this is
 1612    not an acceptable solution.  For this reason, it is specified that
 1613    entities of type "message/partial" must always have a content-
 1614    transfer-encoding of 7bit (the default).  In particular, even in
 1615    environments that support binary or 8bit transport, the use of a
 1616    content- transfer-encoding of "8bit" or "binary" is explicitly
 1617    prohibited for MIME entities of type "message/partial". This in turn
 1618    implies that the inner message must not use "8bit" or "binary"
 1619    encoding.
 1620 
 1621 
 1622 
 1623 
 1624 
 1625 
 1626 Freed & Borenstein          Standards Track                    [Page 29]
 1627 
 1628 RFC 2046                      Media Types                  November 1996
 1629 
 1630 
 1631    Because some message transfer agents may choose to automatically
 1632    fragment large messages, and because such agents may use very
 1633    different fragmentation thresholds, it is possible that the pieces of
 1634    a partial message, upon reassembly, may prove themselves to comprise
 1635    a partial message.  This is explicitly permitted.
 1636 
 1637    Three parameters must be specified in the Content-Type field of type
 1638    "message/partial":  The first, "id", is a unique identifier, as close
 1639    to a world-unique identifier as possible, to be used to match the
 1640    fragments together. (In general, the identifier is essentially a
 1641    message-id; if placed in double quotes, it can be ANY message-id, in
 1642    accordance with the BNF for "parameter" given in RFC 2045.)  The
 1643    second, "number", an integer, is the fragment number, which indicates
 1644    where this fragment fits into the sequence of fragments.  The third,
 1645    "total", another integer, is the total number of fragments.  This
 1646    third subfield is required on the final fragment, and is optional
 1647    (though encouraged) on the earlier fragments.  Note also that these
 1648    parameters may be given in any order.
 1649 
 1650    Thus, the second piece of a 3-piece message may have either of the
 1651    following header fields:
 1652 
 1653      Content-Type: Message/Partial; number=2; total=3;
 1654                    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
 1655 
 1656      Content-Type: Message/Partial;
 1657                    id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
 1658                    number=2
 1659 
 1660    But the third piece MUST specify the total number of fragments:
 1661 
 1662      Content-Type: Message/Partial; number=3; total=3;
 1663                    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
 1664 
 1665    Note that fragment numbering begins with 1, not 0.
 1666 
 1667    When the fragments of an entity broken up in this manner are put
 1668    together, the result is always a complete MIME entity, which may have
 1669    its own Content-Type header field, and thus may contain any other
 1670    data type.
 1671 
 1672 5.2.2.1.  Message Fragmentation and Reassembly
 1673 
 1674    The semantics of a reassembled partial message must be those of the
 1675    "inner" message, rather than of a message containing the inner
 1676    message.  This makes it possible, for example, to send a large audio
 1677    message as several partial messages, and still have it appear to the
 1678    recipient as a simple audio message rather than as an encapsulated
 1679 
 1680 
 1681 
 1682 Freed & Borenstein          Standards Track                    [Page 30]
 1683 
 1684 RFC 2046                      Media Types                  November 1996
 1685 
 1686 
 1687    message containing an audio message.  That is, the encapsulation of
 1688    the message is considered to be "transparent".
 1689 
 1690    When generating and reassembling the pieces of a "message/partial"
 1691    message, the headers of the encapsulated message must be merged with
 1692    the headers of the enclosing entities.  In this process the following
 1693    rules must be observed:
 1694 
 1695     (1)   Fragmentation agents must split messages at line
 1696           boundaries only. This restriction is imposed because
 1697           splits at points other than the ends of lines in turn
 1698           depends on message transports being able to preserve
 1699           the semantics of messages that don't end with a CRLF
 1700           sequence. Many transports are incapable of preserving
 1701           such semantics.
 1702 
 1703     (2)   All of the header fields from the initial enclosing
 1704           message, except those that start with "Content-" and
 1705           the specific header fields "Subject", "Message-ID",
 1706           "Encrypted", and "MIME-Version", must be copied, in
 1707           order, to the new message.
 1708 
 1709     (3)   The header fields in the enclosed message which start
 1710           with "Content-", plus the "Subject", "Message-ID",
 1711           "Encrypted", and "MIME-Version" fields, must be
 1712           appended, in order, to the header fields of the new
 1713           message.  Any header fields in the enclosed message
 1714           which do not start with "Content-" (except for the
 1715           "Subject", "Message-ID", "Encrypted", and "MIME-
 1716           Version" fields) will be ignored and dropped.
 1717 
 1718     (4)   All of the header fields from the second and any
 1719           subsequent enclosing messages are discarded by the
 1720           reassembly process.
 1721 
 1722 5.2.2.2.  Fragmentation and Reassembly Example
 1723 
 1724    If an audio message is broken into two pieces, the first piece might
 1725    look something like this:
 1726 
 1727      X-Weird-Header-1: Foo
 1728      From: Bill@host.com
 1729      To: joe@otherhost.com
 1730      Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
 1731      Subject: Audio mail (part 1 of 2)
 1732      Message-ID: <id1@host.com>
 1733      MIME-Version: 1.0
 1734      Content-type: message/partial; id="ABC@host.com";
 1735 
 1736 
 1737 
 1738 Freed & Borenstein          Standards Track                    [Page 31]
 1739 
 1740 RFC 2046                      Media Types                  November 1996
 1741 
 1742 
 1743                    number=1; total=2
 1744 
 1745      X-Weird-Header-1: Bar
 1746      X-Weird-Header-2: Hello
 1747      Message-ID: <anotherid@foo.com>
 1748      Subject: Audio mail
 1749      MIME-Version: 1.0
 1750      Content-type: audio/basic
 1751      Content-transfer-encoding: base64
 1752 
 1753        ... first half of encoded audio data goes here ...
 1754 
 1755    and the second half might look something like this:
 1756 
 1757      From: Bill@host.com
 1758      To: joe@otherhost.com
 1759      Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
 1760      Subject: Audio mail (part 2 of 2)
 1761      MIME-Version: 1.0
 1762      Message-ID: <id2@host.com>
 1763      Content-type: message/partial;
 1764                    id="ABC@host.com"; number=2; total=2
 1765 
 1766        ... second half of encoded audio data goes here ...
 1767 
 1768    Then, when the fragmented message is reassembled, the resulting
 1769    message to be displayed to the user should look something like this:
 1770 
 1771      X-Weird-Header-1: Foo
 1772      From: Bill@host.com
 1773      To: joe@otherhost.com
 1774      Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
 1775      Subject: Audio mail
 1776      Message-ID: <anotherid@foo.com>
 1777      MIME-Version: 1.0
 1778      Content-type: audio/basic
 1779      Content-transfer-encoding: base64
 1780 
 1781        ... first half of encoded audio data goes here ...
 1782        ... second half of encoded audio data goes here ...
 1783 
 1784    The inclusion of a "References" field in the headers of the second
 1785    and subsequent pieces of a fragmented message that references the
 1786    Message-Id on the previous piece may be of benefit to mail readers
 1787    that understand and track references.  However, the generation of
 1788    such "References" fields is entirely optional.
 1789 
 1790 
 1791 
 1792 
 1793 
 1794 Freed & Borenstein          Standards Track                    [Page 32]
 1795 
 1796 RFC 2046                      Media Types                  November 1996
 1797 
 1798 
 1799    Finally, it should be noted that the "Encrypted" header field has
 1800    been made obsolete by Privacy Enhanced Messaging (PEM) [RFC-1421,
 1801    RFC-1422, RFC-1423, RFC-1424], but the rules above are nevertheless
 1802    believed to describe the correct way to treat it if it is encountered
 1803    in the context of conversion to and from "message/partial" fragments.
 1804 
 1805 5.2.3.  External-Body Subtype
 1806 
 1807    The external-body subtype indicates that the actual body data are not
 1808    included, but merely referenced.  In this case, the parameters
 1809    describe a mechanism for accessing the external data.
 1810 
 1811    When a MIME entity is of type "message/external-body", it consists of
 1812    a header, two consecutive CRLFs, and the message header for the
 1813    encapsulated message.  If another pair of consecutive CRLFs appears,
 1814    this of course ends the message header for the encapsulated message.
 1815    However, since the encapsulated message's body is itself external, it
 1816    does NOT appear in the area that follows.  For example, consider the
 1817    following message:
 1818 
 1819      Content-type: message/external-body;
 1820                    access-type=local-file;
 1821                    name="/u/nsb/Me.jpeg"
 1822 
 1823      Content-type: image/jpeg
 1824      Content-ID: <id42@guppylake.bellcore.com>
 1825      Content-Transfer-Encoding: binary
 1826 
 1827      THIS IS NOT REALLY THE BODY!
 1828 
 1829    The area at the end, which might be called the "phantom body", is
 1830    ignored for most external-body messages.  However, it may be used to
 1831    contain auxiliary information for some such messages, as indeed it is
 1832    when the access-type is "mail- server".  The only access-type defined
 1833    in this document that uses the phantom body is "mail-server", but
 1834    other access-types may be defined in the future in other
 1835    specifications that use this area.
 1836 
 1837    The encapsulated headers in ALL "message/external-body" entities MUST
 1838    include a Content-ID header field to give a unique identifier by
 1839    which to reference the data.  This identifier may be used for caching
 1840    mechanisms, and for recognizing the receipt of the data when the
 1841    access-type is "mail-server".
 1842 
 1843    Note that, as specified here, the tokens that describe external-body
 1844    data, such as file names and mail server commands, are required to be
 1845    in the US-ASCII character set.
 1846 
 1847 
 1848 
 1849 
 1850 Freed & Borenstein          Standards Track                    [Page 33]
 1851 
 1852 RFC 2046                      Media Types                  November 1996
 1853 
 1854 
 1855    If this proves problematic in practice, a new mechanism may be
 1856    required as a future extension to MIME, either as newly defined
 1857    access-types for "message/external-body" or by some other mechanism.
 1858 
 1859    As with "message/partial", MIME entities of type "message/external-
 1860    body" MUST have a content-transfer-encoding of 7bit (the default).
 1861    In particular, even in environments that support binary or 8bit
 1862    transport, the use of a content- transfer-encoding of "8bit" or
 1863    "binary" is explicitly prohibited for entities of type
 1864    "message/external-body".
 1865 
 1866 5.2.3.1.  General External-Body Parameters
 1867 
 1868    The parameters that may be used with any "message/external- body"
 1869    are:
 1870 
 1871     (1)   ACCESS-TYPE -- A word indicating the supported access
 1872           mechanism by which the file or data may be obtained.
 1873           This word is not case sensitive.  Values include, but
 1874           are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL-
 1875           FILE", and "MAIL-SERVER".  Future values, except for
 1876           experimental values beginning with "X-", must be
 1877           registered with IANA, as described in RFC 2048.
 1878           This parameter is unconditionally mandatory and MUST be
 1879           present on EVERY "message/external-body".
 1880 
 1881     (2)   EXPIRATION -- The date (in the RFC 822 "date-time"
 1882           syntax, as extended by RFC 1123 to permit 4 digits in
 1883           the year field) after which the existence of the
 1884           external data is not guaranteed.  This parameter may be
 1885           used with ANY access-type and is ALWAYS optional.
 1886 
 1887     (3)   SIZE -- The size (in octets) of the data.  The intent
 1888           of this parameter is to help the recipient decide
 1889           whether or not to expend the necessary resources to
 1890           retrieve the external data.  Note that this describes
 1891           the size of the data in its canonical form, that is,
 1892           before any Content-Transfer-Encoding has been applied
 1893           or after the data have been decoded.  This parameter
 1894           may be used with ANY access-type and is ALWAYS
 1895           optional.
 1896 
 1897     (4)   PERMISSION -- A case-insensitive field that indicates
 1898           whether or not it is expected that clients might also
 1899           attempt to overwrite the data.  By default, or if
 1900           permission is "read", the assumption is that they are
 1901           not, and that if the data is retrieved once, it is
 1902           never needed again.  If PERMISSION is "read-write",
 1903 
 1904 
 1905 
 1906 Freed & Borenstein          Standards Track                    [Page 34]
 1907 
 1908 RFC 2046                      Media Types                  November 1996
 1909 
 1910 
 1911           this assumption is invalid, and any local copy must be
 1912           considered no more than a cache.  "Read" and "Read-
 1913           write" are the only defined values of permission.  This
 1914           parameter may be used with ANY access-type and is
 1915           ALWAYS optional.
 1916 
 1917    The precise semantics of the access-types defined here are described
 1918    in the sections that follow.
 1919 
 1920 5.2.3.2.  The 'ftp' and 'tftp' Access-Types
 1921 
 1922    An access-type of FTP or TFTP indicates that the message body is
 1923    accessible as a file using the FTP [RFC-959] or TFTP [RFC- 783]
 1924    protocols, respectively.  For these access-types, the following
 1925    additional parameters are mandatory:
 1926 
 1927     (1)   NAME -- The name of the file that contains the actual
 1928           body data.
 1929 
 1930     (2)   SITE -- A machine from which the file may be obtained,
 1931           using the given protocol.  This must be a fully
 1932           qualified domain name, not a nickname.
 1933 
 1934     (3)   Before any data are retrieved, using FTP, the user will
 1935           generally need to be asked to provide a login id and a
 1936           password for the machine named by the site parameter.
 1937           For security reasons, such an id and password are not
 1938           specified as content-type parameters, but must be
 1939           obtained from the user.
 1940 
 1941    In addition, the following parameters are optional:
 1942 
 1943     (1)   DIRECTORY -- A directory from which the data named by
 1944           NAME should be retrieved.
 1945 
 1946     (2)   MODE -- A case-insensitive string indicating the mode
 1947           to be used when retrieving the information.  The valid
 1948           values for access-type "TFTP" are "NETASCII", "OCTET",
 1949           and "MAIL", as specified by the TFTP protocol [RFC-
 1950           783].  The valid values for access-type "FTP" are
 1951           "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
 1952           decimal integer, typically 8.  These correspond to the
 1953           representation types "A" "E" "I" and "L n" as specified
 1954           by the FTP protocol [RFC-959].  Note that "BINARY" and
 1955           "TENEX" are not valid values for MODE and that "OCTET"
 1956           or "IMAGE" or "LOCAL8" should be used instead.  IF MODE
 1957           is not specified, the  default value is "NETASCII" for
 1958           TFTP and "ASCII" otherwise.
 1959 
 1960 
 1961 
 1962 Freed & Borenstein          Standards Track                    [Page 35]
 1963 
 1964 RFC 2046                      Media Types                  November 1996
 1965 
 1966 
 1967 5.2.3.3.  The 'anon-ftp' Access-Type
 1968 
 1969    The "anon-ftp" access-type is identical to the "ftp" access type,
 1970    except that the user need not be asked to provide a name and password
 1971    for the specified site.  Instead, the ftp protocol will be used with
 1972    login "anonymous" and a password that corresponds to the user's mail
 1973    address.
 1974 
 1975 5.2.3.4.  The 'local-file' Access-Type
 1976 
 1977    An access-type of "local-file" indicates that the actual body is
 1978    accessible as a file on the local machine.  Two additional parameters
 1979    are defined for this access type:
 1980 
 1981     (1)   NAME -- The name of the file that contains the actual
 1982           body data.  This parameter is mandatory for the
 1983           "local-file" access-type.
 1984 
 1985     (2)   SITE -- A domain specifier for a machine or set of
 1986           machines that are known to have access to the data
 1987           file.  This optional parameter is used to describe the
 1988           locality of reference for the data, that is, the site
 1989           or sites at which the file is expected to be visible.
 1990           Asterisks may be used for wildcard matching to a part
 1991           of a domain name, such as "*.bellcore.com", to indicate
 1992           a set of machines on which the data should be directly
 1993           visible, while a single asterisk may be used to
 1994           indicate a file that is expected to be universally
 1995           available, e.g., via a global file system.
 1996 
 1997 5.2.3.5.  The 'mail-server' Access-Type
 1998 
 1999    The "mail-server" access-type indicates that the actual body is
 2000    available from a mail server.  Two additional parameters are defined
 2001    for this access-type:
 2002 
 2003     (1)   SERVER -- The addr-spec of the mail server from which
 2004           the actual body data can be obtained.  This parameter
 2005           is mandatory for the "mail-server" access-type.
 2006 
 2007     (2)   SUBJECT -- The subject that is to be used in the mail
 2008           that is sent to obtain the data.  Note that keying mail
 2009           servers on Subject lines is NOT recommended, but such
 2010           mail servers are known to exist.  This is an optional
 2011           parameter.
 2012 
 2013 
 2014 
 2015 
 2016 
 2017 
 2018 Freed & Borenstein          Standards Track                    [Page 36]
 2019 
 2020 RFC 2046                      Media Types                  November 1996
 2021 
 2022 
 2023    Because mail servers accept a variety of syntaxes, some of which is
 2024    multiline, the full command to be sent to a mail server is not
 2025    included as a parameter in the content-type header field.  Instead,
 2026    it is provided as the "phantom body" when the media type is
 2027    "message/external-body" and the access-type is mail-server.
 2028 
 2029    Note that MIME does not define a mail server syntax.  Rather, it
 2030    allows the inclusion of arbitrary mail server commands in the phantom
 2031    body.  Implementations must include the phantom body in the body of
 2032    the message it sends to the mail server address to retrieve the
 2033    relevant data.
 2034 
 2035    Unlike other access-types, mail-server access is asynchronous and
 2036    will happen at an unpredictable time in the future.  For this reason,
 2037    it is important that there be a mechanism by which the returned data
 2038    can be matched up with the original "message/external-body" entity.
 2039    MIME mail servers must use the same Content-ID field on the returned
 2040    message that was used in the original "message/external-body"
 2041    entities, to facilitate such matching.
 2042 
 2043 5.2.3.6.  External-Body Security Issues
 2044 
 2045    "Message/external-body" entities give rise to two important security
 2046    issues:
 2047 
 2048     (1)   Accessing data via a "message/external-body" reference
 2049           effectively results in the message recipient performing
 2050           an operation that was specified by the message
 2051           originator.  It is therefore possible for the message
 2052           originator to trick a recipient into doing something
 2053           they would not have done otherwise.  For example, an
 2054           originator could specify a action that attempts
 2055           retrieval of material that the recipient is not
 2056           authorized to obtain, causing the recipient to
 2057           unwittingly violate some security policy.  For this
 2058           reason, user agents capable of resolving external
 2059           references must always take steps to describe the
 2060           action they are to take to the recipient and ask for
 2061           explicit permisssion prior to performing it.
 2062 
 2063           The 'mail-server' access-type is particularly
 2064           vulnerable, in that it causes the recipient to send a
 2065           new message whose contents are specified by the
 2066           original message's originator.  Given the potential for
 2067           abuse, any such request messages that are constructed
 2068           should contain a clear indication that they were
 2069           generated automatically (e.g. in a Comments: header
 2070           field) in an attempt to resolve a MIME
 2071 
 2072 
 2073 
 2074 Freed & Borenstein          Standards Track                    [Page 37]
 2075 
 2076 RFC 2046                      Media Types                  November 1996
 2077 
 2078 
 2079           "message/external-body" reference.
 2080 
 2081     (2)   MIME will sometimes be used in environments that
 2082           provide some guarantee of message integrity and
 2083           authenticity.  If present, such guarantees may apply
 2084           only to the actual direct content of messages -- they
 2085           may or may not apply to data accessed through MIME's
 2086           "message/external-body" mechanism.  In particular, it
 2087           may be possible to subvert certain access mechanisms
 2088           even when the messaging system itself is secure.
 2089 
 2090           It should be noted that this problem exists either with
 2091           or without the availabilty of MIME mechanisms.  A
 2092           casual reference to an FTP site containing a document
 2093           in the text of a secure message brings up similar
 2094           issues -- the only difference is that MIME provides for
 2095           automatic retrieval of such material, and users may
 2096           place unwarranted trust is such automatic retrieval
 2097           mechanisms.
 2098 
 2099 5.2.3.7.  Examples and Further Explanations
 2100 
 2101    When the external-body mechanism is used in conjunction with the
 2102    "multipart/alternative" media type it extends the functionality of
 2103    "multipart/alternative" to include the case where the same entity is
 2104    provided in the same format but via different accces mechanisms.
 2105    When this is done the originator of the message must order the parts
 2106    first in terms of preferred formats and then by preferred access
 2107    mechanisms.  The recipient's viewer should then evaluate the list
 2108    both in terms of format and access mechanisms.
 2109 
 2110    With the emerging possibility of very wide-area file systems, it
 2111    becomes very hard to know in advance the set of machines where a file
 2112    will and will not be accessible directly from the file system.
 2113    Therefore it may make sense to provide both a file name, to be tried
 2114    directly, and the name of one or more sites from which the file is
 2115    known to be accessible.  An implementation can try to retrieve remote
 2116    files using FTP or any other protocol, using anonymous file retrieval
 2117    or prompting the user for the necessary name and password.  If an
 2118    external body is accessible via multiple mechanisms, the sender may
 2119    include multiple entities of type "message/external-body" within the
 2120    body parts of an enclosing "multipart/alternative" entity.
 2121 
 2122    However, the external-body mechanism is not intended to be limited to
 2123    file retrieval, as shown by the mail-server access-type.  Beyond
 2124    this, one can imagine, for example, using a video server for external
 2125    references to video clips.
 2126 
 2127 
 2128 
 2129 
 2130 Freed & Borenstein          Standards Track                    [Page 38]
 2131 
 2132 RFC 2046                      Media Types                  November 1996
 2133 
 2134 
 2135    The embedded message header fields which appear in the body of the
 2136    "message/external-body" data must be used to declare the media type
 2137    of the external body if it is anything other than plain US-ASCII
 2138    text, since the external body does not have a header section to
 2139    declare its type.  Similarly, any Content-transfer-encoding other
 2140    than "7bit" must also be declared here.  Thus a complete
 2141    "message/external-body" message, referring to an object in PostScript
 2142    format, might look like this:
 2143 
 2144      From: Whomever
 2145      To: Someone
 2146      Date: Whenever
 2147      Subject: whatever
 2148      MIME-Version: 1.0
 2149      Message-ID: <id1@host.com>
 2150      Content-Type: multipart/alternative; boundary=42
 2151      Content-ID: <id001@guppylake.bellcore.com>
 2152 
 2153      --42
 2154      Content-Type: message/external-body; name="BodyFormats.ps";
 2155                    site="thumper.bellcore.com"; mode="image";
 2156                    access-type=ANON-FTP; directory="pub";
 2157                    expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
 2158 
 2159      Content-type: application/postscript
 2160      Content-ID: <id42@guppylake.bellcore.com>
 2161 
 2162      --42
 2163      Content-Type: message/external-body; access-type=local-file;
 2164                    name="/u/nsb/writing/rfcs/RFC-MIME.ps";
 2165                    site="thumper.bellcore.com";
 2166                    expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
 2167 
 2168      Content-type: application/postscript
 2169      Content-ID: <id42@guppylake.bellcore.com>
 2170 
 2171      --42
 2172      Content-Type: message/external-body;
 2173                    access-type=mail-server
 2174                    server="listserv@bogus.bitnet";
 2175                    expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
 2176 
 2177      Content-type: application/postscript
 2178      Content-ID: <id42@guppylake.bellcore.com>
 2179 
 2180      get RFC-MIME.DOC
 2181 
 2182      --42--
 2183 
 2184 
 2185 
 2186 Freed & Borenstein          Standards Track                    [Page 39]
 2187 
 2188 RFC 2046                      Media Types                  November 1996
 2189 
 2190 
 2191    Note that in the above examples, the default Content-transfer-
 2192    encoding of "7bit" is assumed for the external postscript data.
 2193 
 2194    Like the "message/partial" type, the "message/external-body" media
 2195    type is intended to be transparent, that is, to convey the data type
 2196    in the external body rather than to convey a message with a body of
 2197    that type.  Thus the headers on the outer and inner parts must be
 2198    merged using the same rules as for "message/partial".  In particular,
 2199    this means that the Content-type and Subject fields are overridden,
 2200    but the From field is preserved.
 2201 
 2202    Note that since the external bodies are not transported along with
 2203    the external body reference, they need not conform to transport
 2204    limitations that apply to the reference itself. In particular,
 2205    Internet mail transports may impose 7bit and line length limits, but
 2206    these do not automatically apply to binary external body references.
 2207    Thus a Content-Transfer-Encoding is not generally necessary, though
 2208    it is permitted.
 2209 
 2210    Note that the body of a message of type "message/external-body" is
 2211    governed by the basic syntax for an RFC 822 message.  In particular,
 2212    anything before the first consecutive pair of CRLFs is header
 2213    information, while anything after it is body information, which is
 2214    ignored for most access-types.
 2215 
 2216 5.2.4.  Other Message Subtypes
 2217 
 2218    MIME implementations must in general treat unrecognized subtypes of
 2219    "message" as being equivalent to "application/octet-stream".
 2220 
 2221    Future subtypes of "message" intended for use with email should be
 2222    restricted to "7bit" encoding. A type other than "message" should be
 2223    used if restriction to "7bit" is not possible.
 2224 
 2225 6.  Experimental Media Type Values
 2226 
 2227    A media type value beginning with the characters "X-" is a private
 2228    value, to be used by consenting systems by mutual agreement.  Any
 2229    format without a rigorous and public definition must be named with an
 2230    "X-" prefix, and publicly specified values shall never begin with
 2231    "X-".  (Older versions of the widely used Andrew system use the "X-
 2232    BE2" name, so new systems should probably choose a different name.)
 2233 
 2234    In general, the use of "X-" top-level types is strongly discouraged.
 2235    Implementors should invent subtypes of the existing types whenever
 2236    possible. In many cases, a subtype of "application" will be more
 2237    appropriate than a new top-level type.
 2238 
 2239 
 2240 
 2241 
 2242 Freed & Borenstein          Standards Track                    [Page 40]
 2243 
 2244 RFC 2046                      Media Types                  November 1996
 2245 
 2246 
 2247 7.  Summary
 2248 
 2249    The five discrete media types provide provide a standardized
 2250    mechanism for tagging entities as "audio", "image", or several other
 2251    kinds of data. The composite "multipart" and "message" media types
 2252    allow mixing and hierarchical structuring of entities of different
 2253    types in a single message. A distinguished parameter syntax allows
 2254    further specification of data format details, particularly the
 2255    specification of alternate character sets.  Additional optional
 2256    header fields provide mechanisms for certain extensions deemed
 2257    desirable by many implementors. Finally, a number of useful media
 2258    types are defined for general use by consenting user agents, notably
 2259    "message/partial" and "message/external-body".
 2260 
 2261 9.  Security Considerations
 2262 
 2263    Security issues are discussed in the context of the
 2264    "application/postscript" type, the "message/external-body" type, and
 2265    in RFC 2048.  Implementors should pay special attention to the
 2266    security implications of any media types that can cause the remote
 2267    execution of any actions in the recipient's environment.  In such
 2268    cases, the discussion of the "application/postscript" type may serve
 2269    as a model for considering other media types with remote execution
 2270    capabilities.
 2271 
 2272 
 2273 
 2274 
 2275 
 2276 
 2277 
 2278 
 2279 
 2280 
 2281 
 2282 
 2283 
 2284 
 2285 
 2286 
 2287 
 2288 
 2289 
 2290 
 2291 
 2292 
 2293 
 2294 
 2295 
 2296 
 2297 
 2298 Freed & Borenstein          Standards Track                    [Page 41]
 2299 
 2300 RFC 2046                      Media Types                  November 1996
 2301 
 2302 
 2303 9.  Authors' Addresses
 2304 
 2305    For more information, the authors of this document are best contacted
 2306    via Internet mail:
 2307 
 2308    Ned Freed
 2309    Innosoft International, Inc.
 2310    1050 East Garvey Avenue South
 2311    West Covina, CA 91790
 2312    USA
 2313 
 2314    Phone: +1 818 919 3600
 2315    Fax:   +1 818 919 3614
 2316    EMail: ned@innosoft.com
 2317 
 2318 
 2319    Nathaniel S. Borenstein
 2320    First Virtual Holdings
 2321    25 Washington Avenue
 2322    Morristown, NJ 07960
 2323    USA
 2324 
 2325    Phone: +1 201 540 8967
 2326    Fax:   +1 201 993 3032
 2327    EMail: nsb@nsb.fv.com
 2328 
 2329 
 2330    MIME is a result of the work of the Internet Engineering Task Force
 2331    Working Group on RFC 822 Extensions.  The chairman of that group,
 2332    Greg Vaudreuil, may be reached at:
 2333 
 2334    Gregory M. Vaudreuil
 2335    Octel Network Services
 2336    17080 Dallas Parkway
 2337    Dallas, TX 75248-1905
 2338    USA
 2339 
 2340    EMail: Greg.Vaudreuil@Octel.Com
 2341 
 2342 
 2343 
 2344 
 2345 
 2346 
 2347 
 2348 
 2349 
 2350 
 2351 
 2352 
 2353 
 2354 Freed & Borenstein          Standards Track                    [Page 42]
 2355 
 2356 RFC 2046                      Media Types                  November 1996
 2357 
 2358 
 2359 Appendix A -- Collected Grammar
 2360 
 2361    This appendix contains the complete BNF grammar for all the syntax
 2362    specified by this document.
 2363 
 2364    By itself, however, this grammar is incomplete.  It refers by name to
 2365    several syntax rules that are defined by RFC 822.  Rather than
 2366    reproduce those definitions here, and risk unintentional differences
 2367    between the two, this document simply refers the reader to RFC 822
 2368    for the remaining definitions. Wherever a term is undefined, it
 2369    refers to the RFC 822 definition.
 2370 
 2371      boundary := 0*69<bchars> bcharsnospace
 2372 
 2373      bchars := bcharsnospace / " "
 2374 
 2375      bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
 2376                       "+" / "_" / "," / "-" / "." /
 2377                       "/" / ":" / "=" / "?"
 2378 
 2379      body-part := <"message" as defined in RFC 822, with all
 2380                    header fields optional, not starting with the
 2381                    specified dash-boundary, and with the
 2382                    delimiter not occurring anywhere in the
 2383                    body part.  Note that the semantics of a
 2384                    part differ from the semantics of a message,
 2385                    as described in the text.>
 2386 
 2387      close-delimiter := delimiter "--"
 2388 
 2389      dash-boundary := "--" boundary
 2390                       ; boundary taken from the value of
 2391                       ; boundary parameter of the
 2392                       ; Content-Type field.
 2393 
 2394      delimiter := CRLF dash-boundary
 2395 
 2396      discard-text := *(*text CRLF)
 2397                      ; May be ignored or discarded.
 2398 
 2399      encapsulation := delimiter transport-padding
 2400                       CRLF body-part
 2401 
 2402      epilogue := discard-text
 2403 
 2404      multipart-body := [preamble CRLF]
 2405                        dash-boundary transport-padding CRLF
 2406                        body-part *encapsulation
 2407 
 2408 
 2409 
 2410 Freed & Borenstein          Standards Track                    [Page 43]
 2411 
 2412 RFC 2046                      Media Types                  November 1996
 2413 
 2414 
 2415                        close-delimiter transport-padding
 2416                        [CRLF epilogue]
 2417 
 2418      preamble := discard-text
 2419 
 2420      transport-padding := *LWSP-char
 2421                           ; Composers MUST NOT generate
 2422                           ; non-zero length transport
 2423                           ; padding, but receivers MUST
 2424                           ; be able to handle padding
 2425                           ; added by message transports.
 2426 
 2427 
 2428 
 2429 
 2430 
 2431 
 2432 
 2433 
 2434 
 2435 
 2436 
 2437 
 2438 
 2439 
 2440 
 2441 
 2442 
 2443 
 2444 
 2445 
 2446 
 2447 
 2448 
 2449 
 2450 
 2451 
 2452 
 2453 
 2454 
 2455 
 2456 
 2457 
 2458 
 2459 
 2460 
 2461 
 2462 
 2463 
 2464 
 2465 
 2466 Freed & Borenstein          Standards Track                    [Page 44]
 2467