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