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

    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
   14                  Multipurpose Internet Mail Extensions
   15                             (MIME) Part Two:
   16                               Media Types
   18 Status of this Memo
   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.
   26 Abstract
   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
   34     (1)   textual message bodies in character sets other than
   35           US-ASCII,
   37     (2)   an extensible set of different formats for non-textual
   38           message bodies,
   40     (3)   multi-part message bodies, and
   42     (4)   textual header information in character sets other than
   43           US-ASCII.
   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.
   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
   58 Freed & Borenstein          Standards Track                     [Page 1]
   60 RFC 2046                      Media Types                  November 1996
   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.
   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.
   73 Table of Contents
   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 Message Fragmentation and Reassembly ............   30
  104 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
  114 Freed & Borenstein          Standards Track                     [Page 2]
  116 RFC 2046                      Media Types                  November 1996
  119    A. Collected Grammar ....................................   43
  121 1.  Introduction
  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.
  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.
  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.
  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.
  170 Freed & Borenstein          Standards Track                     [Page 3]
  172 RFC 2046                      Media Types                  November 1996
  175    The initial seven standard top-level media type are defined and
  176    described in the remainder of this document.
  178 2.  Definition of a Top-Level Media Type
  180    The definition of a top-level media type consists of:
  182     (1)   a name and a description of the type, including
  183           criteria for whether a particular type would qualify
  184           under that type,
  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),
  190     (3)   how a user agent and/or gateway should handle unknown
  191           subtypes of this type,
  193     (4)   general considerations on gatewaying entities of this
  194           top-level type, if any, and
  196     (5)   any restrictions on content-transfer-encodings for
  197           entities of this top-level type.
  199 3.  Overview Of The Initial Top-Level Media Types
  201    The five discrete top-level media types are:
  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".
  226 Freed & Borenstein          Standards Track                     [Page 4]
  228 RFC 2046                      Media Types                  November 1996
  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.
  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.
  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.
  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.
  266    The two composite top-level media types are:
  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".
  282 Freed & Borenstein          Standards Track                     [Page 5]
  284 RFC 2046                      Media Types                  November 1996
  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.
  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.
  303 4.  Discrete Media Type Values
  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.
  309 4.1.  Text Media Type
  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.
  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".
  338 Freed & Borenstein          Standards Track                     [Page 6]
  340 RFC 2046                      Media Types                  November 1996
  343 4.1.1.  Representation of Line Breaks
  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.
  350    This rule applies regardless of format or character set or sets
  351    involved.
  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.
  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.
  370 4.1.2.  Charset Parameter
  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:
  376      Content-type: text/plain; charset=iso-8859-1
  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.
  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.
  394 Freed & Borenstein          Standards Track                     [Page 7]
  396 RFC 2046                      Media Types                  November 1996
  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.
  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.
  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.
  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].
  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.
  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
  450 Freed & Borenstein          Standards Track                     [Page 8]
  452 RFC 2046                      Media Types                  November 1996
  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.
  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
  473     (1)   because a subtype of text other than "plain"
  474           specifically assigns some additional meaning, or
  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.
  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.
  491    The defined charset values are:
  493     (1)   US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
  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.
  506 Freed & Borenstein          Standards Track                     [Page 9]
  508 RFC 2046                      Media Types                  November 1996
  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.
  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].
  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.
  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.
  532    Note that the character set used, if anything other than US- ASCII,
  533    must always be explicitly specified in the Content-Type field.
  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-".
  540    Implementors are discouraged from defining new character sets unless
  541    absolutely necessary.
  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.
  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.
  562 Freed & Borenstein          Standards Track                    [Page 10]
  564 RFC 2046                      Media Types                  November 1996
  567 4.1.3.  Plain Subtype
  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.
  579    No other "text" subtype is defined by this document.
  581 4.1.4.  Unrecognized Subtypes
  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".
  588 4.2.  Image Media Type
  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].
  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.
  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.
  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.
  609 4.3.  Audio Media Type
  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.
  618 Freed & Borenstein          Standards Track                    [Page 11]
  620 RFC 2046                      Media Types                  November 1996
  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.
  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.
  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.
  637 4.4.  Video Media Type
  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].
  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".
  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.
  658 4.5.  Application Media Type
  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.)
  674 Freed & Borenstein          Standards Track                    [Page 12]
  676 RFC 2046                      Media Types                  November 1996
  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.
  688    Such applications may be defined as subtypes of the "application"
  689    media type. This document defines two subtypes:
  691    octet-stream, and PostScript.
  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".
  698 4.5.1.  Octet-Stream Subtype
  700    The "octet-stream" subtype is used to indicate that a body contains
  701    arbitrary binary data.  The set of currently defined parameters is:
  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.
  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.
  714    Both of these parameters are optional.
  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.
  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.
  730 Freed & Borenstein          Standards Track                    [Page 13]
  732 RFC 2046                      Media Types                  November 1996
  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.
  741 4.5.2.  PostScript Subtype
  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].
  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.
  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.
  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.
  771    The remainder of this section outlines some, though probably not all,
  772    of the possible problems with the transport of PostScript entities.
  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.
  786 Freed & Borenstein          Standards Track                    [Page 14]
  788 RFC 2046                      Media Types                  November 1996
  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.
  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.
  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
  842 Freed & Borenstein          Standards Track                    [Page 15]
  844 RFC 2046                      Media Types                  November 1996
  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.
  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.
  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.
  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.
  898 Freed & Borenstein          Standards Track                    [Page 16]
  900 RFC 2046                      Media Types                  November 1996
  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.)
  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.
  921 4.5.3.  Other Application Subtypes
  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".
  928 5.  Composite Media Type Values
  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.
  934 5.1.  Multipart Media Type
  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.
  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
  954 Freed & Borenstein          Standards Track                    [Page 17]
  956 RFC 2046                      Media Types                  November 1996
  959    a content-type of "text/plain; charset=US-ASCII".
  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.
  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.)
  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.
  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.
  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.
 1010 Freed & Borenstein          Standards Track                    [Page 18]
 1012 RFC 2046                      Media Types                  November 1996
 1015 5.1.1.  Common Syntax
 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.
 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.
 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.
 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:
 1048      Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
 1050    But the following is not valid:
 1052      Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
 1054    (because of the colon) and must instead be represented as
 1056      Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
 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
 1066 Freed & Borenstein          Standards Track                    [Page 19]
 1068 RFC 2046                      Media Types                  November 1996
 1071      --gc0pJq0M:08jU534c0p
 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.
 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.
 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.
 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.
 1101      --gc0pJq0M:08jU534c0p--
 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.
 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.
 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
 1122 Freed & Borenstein          Standards Track                    [Page 20]
 1124 RFC 2046                      Media Types                  November 1996
 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.
 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 "-----".
 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:
 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"
 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.
 1159      --simple boundary
 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
 1166      This is explicitly typed plain US-ASCII text.
 1167      It DOES end with a linebreak.
 1169      --simple boundary--
 1171      This is the epilogue.  It is also to be ignored.
 1178 Freed & Borenstein          Standards Track                    [Page 21]
 1180 RFC 2046                      Media Types                  November 1996
 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.
 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.
 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.
 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:
 1208      boundary := 0*69<bchars> bcharsnospace
 1210      bchars := bcharsnospace / " "
 1212      bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
 1213                       "+" / "_" / "," / "-" / "." /
 1214                       "/" / ":" / "=" / "?"
 1216    Overall, the body of a "multipart" entity may be specified as
 1217    follows:
 1219      dash-boundary := "--" boundary
 1220                       ; boundary taken from the value of
 1221                       ; boundary parameter of the
 1222                       ; Content-Type field.
 1224      multipart-body := [preamble CRLF]
 1225                        dash-boundary transport-padding CRLF
 1226                        body-part *encapsulation
 1227                        close-delimiter transport-padding
 1228                        [CRLF epilogue]
 1234 Freed & Borenstein          Standards Track                    [Page 22]
 1236 RFC 2046                      Media Types                  November 1996
 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.
 1246      encapsulation := delimiter transport-padding
 1247                       CRLF body-part
 1249      delimiter := CRLF dash-boundary
 1251      close-delimiter := delimiter "--"
 1253      preamble := discard-text
 1255      epilogue := discard-text
 1257      discard-text := *(*text CRLF) *text
 1258                      ; May be ignored or discarded.
 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.
 1269      OCTET := <any 0-255 octet value>
 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.
 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.
 1290 Freed & Borenstein          Standards Track                    [Page 23]
 1292 RFC 2046                      Media Types                  November 1996
 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.
 1308 5.1.2.  Handling Nested Messages and Multiparts
 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.
 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.
 1323 5.1.3.  Mixed Subtype
 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".
 1330 5.1.4.  Alternative Subtype
 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.
 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
 1346 Freed & Borenstein          Standards Track                    [Page 24]
 1348 RFC 2046                      Media Types                  November 1996
 1351    best choice is the LAST part of a type supported by the recipient
 1352    system's local environment.
 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:
 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
 1365      --boundary42
 1366      Content-Type: text/plain; charset=us-ascii
 1368        ... plain text version of message goes here ...
 1370      --boundary42
 1371      Content-Type: text/enriched
 1373        ... RFC 1896 text/enriched version of same message
 1374            goes here ...
 1376      --boundary42
 1377      Content-Type: application/x-whatever
 1379        ... fanciest version of same message goes here ...
 1381      --boundary42--
 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.
 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.
 1402 Freed & Borenstein          Standards Track                    [Page 25]
 1404 RFC 2046                      Media Types                  November 1996
 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.
 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.
 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.
 1442 5.1.5.  Digest Subtype
 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.
 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
 1458 Freed & Borenstein          Standards Track                    [Page 26]
 1460 RFC 2046                      Media Types                  November 1996
 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.
 1468    A digest in this format might, then, look something like this:
 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 ----"
 1478      ------ main boundary ----
 1480        ...Introductory text or table of contents...
 1482      ------ main boundary ----
 1483      Content-Type: multipart/digest;
 1484                    boundary="---- next message ----"
 1486      ------ next message ----
 1488      From: someone-else
 1489      Date: Fri, 26 Mar 1993 11:13:32 +0200
 1490      Subject: my opinion
 1492        ...body goes here ...
 1494      ------ next message ----
 1496      From: someone-else-again
 1497      Date: Fri, 26 Mar 1993 10:07:13 -0500
 1498      Subject: my different opinion
 1500        ... another body goes here ...
 1502      ------ next message ------
 1504      ------ main boundary ------
 1506 5.1.6.  Parallel Subtype
 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,
 1514 Freed & Borenstein          Standards Track                    [Page 27]
 1516 RFC 2046                      Media Types                  November 1996
 1519    in a parallel entity, the order of body parts is not significant.
 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.
 1526 5.1.7.  Other Multipart Subtypes
 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".
 1532 5.2.  Message Media Type
 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.
 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.
 1549    Subtypes of "message" often impose restrictions on what encodings are
 1550    allowed.  These restrictions are described in conjunction with each
 1551    specific subtype.
 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."
 1559 5.2.1.  RFC822 Subtype
 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.
 1570 Freed & Borenstein          Standards Track                    [Page 28]
 1572 RFC 2046                      Media Types                  November 1996
 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.
 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.
 1590 5.2.2.  Partial Subtype
 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.
 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.
 1626 Freed & Borenstein          Standards Track                    [Page 29]
 1628 RFC 2046                      Media Types                  November 1996
 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.
 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.
 1650    Thus, the second piece of a 3-piece message may have either of the
 1651    following header fields:
 1653      Content-Type: Message/Partial; number=2; total=3;
 1654                    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
 1656      Content-Type: Message/Partial;
 1657                    id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
 1658                    number=2
 1660    But the third piece MUST specify the total number of fragments:
 1662      Content-Type: Message/Partial; number=3; total=3;
 1663                    id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
 1665    Note that fragment numbering begins with 1, not 0.
 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.
 1672  Message Fragmentation and Reassembly
 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
 1682 Freed & Borenstein          Standards Track                    [Page 30]
 1684 RFC 2046                      Media Types                  November 1996
 1687    message containing an audio message.  That is, the encapsulation of
 1688    the message is considered to be "transparent".
 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:
 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.
 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.
 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.
 1718     (4)   All of the header fields from the second and any
 1719           subsequent enclosing messages are discarded by the
 1720           reassembly process.
 1722  Fragmentation and Reassembly Example
 1724    If an audio message is broken into two pieces, the first piece might
 1725    look something like this:
 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";
 1738 Freed & Borenstein          Standards Track                    [Page 31]
 1740 RFC 2046                      Media Types                  November 1996
 1743                    number=1; total=2
 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
 1753        ... first half of encoded audio data goes here ...
 1755    and the second half might look something like this:
 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
 1766        ... second half of encoded audio data goes here ...
 1768    Then, when the fragmented message is reassembled, the resulting
 1769    message to be displayed to the user should look something like this:
 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
 1781        ... first half of encoded audio data goes here ...
 1782        ... second half of encoded audio data goes here ...
 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.
 1794 Freed & Borenstein          Standards Track                    [Page 32]
 1796 RFC 2046                      Media Types                  November 1996
 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.
 1805 5.2.3.  External-Body Subtype
 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.
 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:
 1819      Content-type: message/external-body;
 1820                    access-type=local-file;
 1821                    name="/u/nsb/Me.jpeg"
 1823      Content-type: image/jpeg
 1824      Content-ID: <id42@guppylake.bellcore.com>
 1825      Content-Transfer-Encoding: binary
 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.
 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".
 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.
 1850 Freed & Borenstein          Standards Track                    [Page 33]
 1852 RFC 2046                      Media Types                  November 1996
 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.
 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".
 1866  General External-Body Parameters
 1868    The parameters that may be used with any "message/external- body"
 1869    are:
 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".
 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.
 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.
 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",
 1906 Freed & Borenstein          Standards Track                    [Page 34]
 1908 RFC 2046                      Media Types                  November 1996
 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.
 1917    The precise semantics of the access-types defined here are described
 1918    in the sections that follow.
 1920  The 'ftp' and 'tftp' Access-Types
 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:
 1927     (1)   NAME -- The name of the file that contains the actual
 1928           body data.
 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.
 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.
 1941    In addition, the following parameters are optional:
 1943     (1)   DIRECTORY -- A directory from which the data named by
 1944           NAME should be retrieved.
 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.
 1962 Freed & Borenstein          Standards Track                    [Page 35]
 1964 RFC 2046                      Media Types                  November 1996
 1967  The 'anon-ftp' Access-Type
 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.
 1975  The 'local-file' Access-Type
 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:
 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.
 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.
 1997  The 'mail-server' Access-Type
 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:
 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.
 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.
 2018 Freed & Borenstein          Standards Track                    [Page 36]
 2020 RFC 2046                      Media Types                  November 1996
 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.
 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.
 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.
 2043  External-Body Security Issues
 2045    "Message/external-body" entities give rise to two important security
 2046    issues:
 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.
 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
 2074 Freed & Borenstein          Standards Track                    [Page 37]
 2076 RFC 2046                      Media Types                  November 1996
 2079           "message/external-body" reference.
 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.
 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.
 2099  Examples and Further Explanations
 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.
 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.
 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.
 2130 Freed & Borenstein          Standards Track                    [Page 38]
 2132 RFC 2046                      Media Types                  November 1996
 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:
 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>
 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)"
 2159      Content-type: application/postscript
 2160      Content-ID: <id42@guppylake.bellcore.com>
 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)"
 2168      Content-type: application/postscript
 2169      Content-ID: <id42@guppylake.bellcore.com>
 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)"
 2177      Content-type: application/postscript
 2178      Content-ID: <id42@guppylake.bellcore.com>
 2180      get RFC-MIME.DOC
 2182      --42--
 2186 Freed & Borenstein          Standards Track                    [Page 39]
 2188 RFC 2046                      Media Types                  November 1996
 2191    Note that in the above examples, the default Content-transfer-
 2192    encoding of "7bit" is assumed for the external postscript data.
 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.
 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.
 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.
 2216 5.2.4.  Other Message Subtypes
 2218    MIME implementations must in general treat unrecognized subtypes of
 2219    "message" as being equivalent to "application/octet-stream".
 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.
 2225 6.  Experimental Media Type Values
 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.)
 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.
 2242 Freed & Borenstein          Standards Track                    [Page 40]
 2244 RFC 2046                      Media Types                  November 1996
 2247 7.  Summary
 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".
 2261 9.  Security Considerations
 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.
 2298 Freed & Borenstein          Standards Track                    [Page 41]
 2300 RFC 2046                      Media Types                  November 1996
 2303 9.  Authors' Addresses
 2305    For more information, the authors of this document are best contacted
 2306    via Internet mail:
 2308    Ned Freed
 2309    Innosoft International, Inc.
 2310    1050 East Garvey Avenue South
 2311    West Covina, CA 91790
 2312    USA
 2314    Phone: +1 818 919 3600
 2315    Fax:   +1 818 919 3614
 2316    EMail: ned@innosoft.com
 2319    Nathaniel S. Borenstein
 2320    First Virtual Holdings
 2321    25 Washington Avenue
 2322    Morristown, NJ 07960
 2323    USA
 2325    Phone: +1 201 540 8967
 2326    Fax:   +1 201 993 3032
 2327    EMail: nsb@nsb.fv.com
 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:
 2334    Gregory M. Vaudreuil
 2335    Octel Network Services
 2336    17080 Dallas Parkway
 2337    Dallas, TX 75248-1905
 2338    USA
 2340    EMail: Greg.Vaudreuil@Octel.Com
 2354 Freed & Borenstein          Standards Track                    [Page 42]
 2356 RFC 2046                      Media Types                  November 1996
 2359 Appendix A -- Collected Grammar
 2361    This appendix contains the complete BNF grammar for all the syntax
 2362    specified by this document.
 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.
 2371      boundary := 0*69<bchars> bcharsnospace
 2373      bchars := bcharsnospace / " "
 2375      bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
 2376                       "+" / "_" / "," / "-" / "." /
 2377                       "/" / ":" / "=" / "?"
 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.>
 2387      close-delimiter := delimiter "--"
 2389      dash-boundary := "--" boundary
 2390                       ; boundary taken from the value of
 2391                       ; boundary parameter of the
 2392                       ; Content-Type field.
 2394      delimiter := CRLF dash-boundary
 2396      discard-text := *(*text CRLF)
 2397                      ; May be ignored or discarded.
 2399      encapsulation := delimiter transport-padding
 2400                       CRLF body-part
 2402      epilogue := discard-text
 2404      multipart-body := [preamble CRLF]
 2405                        dash-boundary transport-padding CRLF
 2406                        body-part *encapsulation
 2410 Freed & Borenstein          Standards Track                    [Page 43]
 2412 RFC 2046                      Media Types                  November 1996
 2415                        close-delimiter transport-padding
 2416                        [CRLF epilogue]
 2418      preamble := discard-text
 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.
 2466 Freed & Borenstein          Standards Track                    [Page 44]