< draft-ietf-822ext-mime-imt-01.txt   draft-ietf-822ext-mime-imt-02.txt >
Network Working Group Nathaniel Borenstein Network Working Group Nathaniel Borenstein
Internet Draft Ned Freed Internet Draft Ned Freed
<draft-ietf-822ext-mime-imt-01.txt> <draft-ietf-822ext-mime-imt-02.txt>
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
(MIME) Part Two: (MIME) Part Two:
Media Types Media Types
May 5, 1995 December 1995
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 2, line ? skipping to change at page 2, line ?
These documents are based on earlier work documented in RFC These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them. 934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision documents are largely orthogonal to (rather than a revision
of) RFC 822. of) RFC 822.
In particular, these documents are designed to provide In particular, these documents are designed to provide
facilities to include multiple parts in a single message, to facilities to include multiple parts in a single message, to
represent body and header text in character sets other than represent body and header text in character sets other than
US-ASCII, to represent formatted multi-font text messages, to US-ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio represent non-textual material such as images and audio clips,
fragments, and generally to facilitate later extensions and generally to facilitate later extensions defining new
defining new types of Internet mail for use by cooperating types of Internet mail for use by cooperating mail agents.
mail agents.
The initial document in this set, RFC MIME-IMB, specifies the The initial document in this set, RFC MIME-IMB, specifies the
various headers used to describe the structure of MIME various headers used to describe the structure of MIME
messages. This second document defines the general structure messages. This second document defines the general structure
of the MIME media typing system and defines an initial set of of the MIME media typing system and defines an initial set of
media types. The third document, RFC MIME-HEADERS, describes media types. The third document, RFC MIME-HEADERS, describes
extensions to RFC 822 to allow non-US-ASCII text data in extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields. The fourth document, RFC MIME- Internet mail header fields. The fourth document, RFC MIME-
REG, specifies various IANA registration procedures for MIME- REG, specifies various IANA registration procedures for MIME-
related entities. The fifth and final document, RFC MIME- related facilities. The fifth and final document, RFC MIME-
CONF, describes MIME conformance criteria as well as providing CONF, describes MIME conformance criteria as well as providing
some illustrative examples of MIME message formats, some illustrative examples of MIME message formats,
acknowledgements, and the bibliography. acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521 and 1522, which These documents are revisions of RFCs 1521 and 1522, which
themselves were revisions of RFCs 1341 and 1342. An appendix themselves were revisions of RFCs 1341 and 1342. An appendix
in RFC MIME-CONF describes differences and changes from in RFC MIME-CONF describes differences and changes from
previous versions. previous versions.
2. Table of Contents 2. Table of Contents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
6.3 Audio Media Type .................................... 13 6.3 Audio Media Type .................................... 13
6.4 Video Media Type .................................... 13 6.4 Video Media Type .................................... 13
6.5 Application Media Type .............................. 14 6.5 Application Media Type .............................. 14
6.5.1 Octet-Stream Subtype .............................. 15 6.5.1 Octet-Stream Subtype .............................. 15
6.5.2 PostScript Subtype ................................ 15 6.5.2 PostScript Subtype ................................ 15
6.5.3 Other Application Subtypes ........................ 19 6.5.3 Other Application Subtypes ........................ 19
7 Composite Media Type Values ........................... 19 7 Composite Media Type Values ........................... 19
7.1 Multipart Media Type ................................ 19 7.1 Multipart Media Type ................................ 19
7.1.1 Common Syntax ..................................... 21 7.1.1 Common Syntax ..................................... 21
7.1.2 Handling Nested Messages and Multiparts ........... 27 7.1.2 Handling Nested Messages and Multiparts ........... 27
7.1.3 Mixed Subtype ..................................... 27 7.1.3 Mixed Subtype ..................................... 28
7.1.4 Alternative Subtype ............................... 28 7.1.4 Alternative Subtype ............................... 28
7.1.5 Digest Subtype .................................... 30 7.1.5 Digest Subtype .................................... 30
7.1.6 Parallel Subtype .................................. 31 7.1.6 Parallel Subtype .................................. 31
7.1.7 Other Multipart Subtypes .......................... 32 7.1.7 Other Multipart Subtypes .......................... 32
7.2 Message Media Type .................................. 32 7.2 Message Media Type .................................. 32
7.2.1 RFC822 Subtype .................................... 32 7.2.1 RFC822 Subtype .................................... 32
7.2.2 Partial Subtype ................................... 33 7.2.2 Partial Subtype ................................... 33
7.2.2.1 Message Fragmentation and Reassembly ............ 34 7.2.2.1 Message Fragmentation and Reassembly ............ 34
7.2.2.2 Fragmentation and Reassembly Example ............ 35 7.2.2.2 Fragmentation and Reassembly Example ............ 35
7.2.3 External-Body Subtype ............................. 37 7.2.3 External-Body Subtype ............................. 37
skipping to change at page 4, line 9 skipping to change at page 4, line 9
8 Experimental Media Type Values ........................ 46 8 Experimental Media Type Values ........................ 46
9 Summary ............................................... 47 9 Summary ............................................... 47
10 Security Considerations .............................. 47 10 Security Considerations .............................. 47
11 Authors' Addresses ................................... 48 11 Authors' Addresses ................................... 48
A Collected Grammar ..................................... 49 A Collected Grammar ..................................... 49
3. Introduction 3. Introduction
The first document in this set, RFC MIME-IMB, defines a number The first document in this set, RFC MIME-IMB, defines a number
of header fields, including Content-Type. The Content-Type of header fields, including Content-Type. The Content-Type
field is used to specify the nature of the data in the body of field is used to specify the nature of the data in the body of
an entity, by giving media type and subtype identifiers, and a MIME entity, by giving media type and subtype identifiers,
by providing auxiliary information that may be required for and by providing auxiliary information that may be required
certain media types. After the type and subtype names, the for certain media types. After the type and subtype names,
remainder of the header field is simply a set of parameters, the remainder of the header field is simply a set of
specified in an attribute/value notation. The ordering of parameters, specified in an attribute/value notation. The
parameters is not significant. ordering of parameters is not significant.
In general, the top-level media type is used to declare the In general, the top-level media type is used to declare the
general type of data, while the subtype specifies a specific general type of data, while the subtype specifies a specific
format for that type of data. Thus, a media type of format for that type of data. Thus, a media type of
"image/xyz" is enough to tell a user agent that the data is an "image/xyz" is enough to tell a user agent that the data is an
image, even if the user agent has no knowledge of the specific image, even if the user agent has no knowledge of the specific
image format "xyz". Such information can be used, for image format "xyz". Such information can be used, for
example, to decide whether or not to show a user the raw data example, to decide whether or not to show a user the raw data
from an unrecognized subtype -- such an action might be from an unrecognized subtype -- such an action might be
reasonable for unrecognized subtypes of text, but not for reasonable for unrecognized subtypes of text, but not for
skipping to change at page 4, line 45 skipping to change at page 4, line 45
specific subtype. However, a given top-level media type may specific subtype. However, a given top-level media type may
define parameters which are applicable to any subtype of that define parameters which are applicable to any subtype of that
type. Parameters may be required by their defining media type type. Parameters may be required by their defining media type
or subtype or they may be optional. MIME implementations must or subtype or they may be optional. MIME implementations must
also ignore any parameters whose names they do not recognize. also ignore any parameters whose names they do not recognize.
MIME's Content-Type header field and media type mechanism has MIME's Content-Type header field and media type mechanism has
been carefully designed to be extensible, and it is expected been carefully designed to be extensible, and it is expected
that the set of media type/subtype pairs and their associated that the set of media type/subtype pairs and their associated
parameters will grow significantly over time. Several other parameters will grow significantly over time. Several other
MIME entities, most notably the list of the name of character MIME facilities, most notably the list of the name of
sets registered for MIME usage, are likely to have new values character sets registered for MIME usage, are likely to have
defined over time. In order to ensure that the set of such new values defined over time. In order to ensure that the set
values is developed in an orderly, well-specified, and public of such values is developed in an orderly, well-specified, and
manner, MIME sets up a registration process which uses the public manner, MIME sets up a registration process which uses
Internet Assigned Numbers Authority (IANA) as a central the Internet Assigned Numbers Authority (IANA) as a central
registry for MIME's extension areas. The registration process registry for MIME's extension areas. The registration process
is described in a companion document, RFC MIME-REG. is described in a companion document, RFC MIME-REG.
The initial seven standard top-level media type are defined The initial seven standard top-level media type are defined
and described in the remainder of this document. and described in the remainder of this document.
4. Definition of a Top-Level Media Type 4. Definition of a Top-Level Media Type
The definition of a top-level media type consists of: The definition of a top-level media type consists of:
skipping to change at page 5, line 27 skipping to change at page 5, line 27
criteria for whether a particular type would qualify criteria for whether a particular type would qualify
under that type, under that type,
(2) the names and definitions of parameters, if any, which (2) the names and definitions of parameters, if any, which
are defined for all subtypes of that type (including are defined for all subtypes of that type (including
whether such parameters are required or optional), whether such parameters are required or optional),
(3) how a user agent and/or gateway should handle unknown (3) how a user agent and/or gateway should handle unknown
subtypes of this type, subtypes of this type,
(4) general considerations on gatewaying objects of this (4) general considerations on gatewaying entities of this
top-level type, if any, and top-level type, if any, and
(5) any restrictions on content-transfer-encodings for (5) any restrictions on content-transfer-encodings for
objects of this top-level type. entities of this top-level type.
5. Overview Of The Initial Top-Level Media Types 5. Overview Of The Initial Top-Level Media Types
The five discrete top-level media types are: The five discrete top-level media types are:
(1) text -- textual information. The subtype "plain" in (1) text -- textual information. The subtype "plain" in
particular indicates plain (unformatted) text. No particular indicates plain (unformatted) text. No
special software is required to get the full meaning of special software is required to get the full meaning of
the text, aside from support for the indicated the text, aside from support for the indicated
character set. Other subtypes are to be used for character set. Other subtypes are to be used for
enriched text in forms where application software may enriched text in forms where application software may
enhance the appearance of the text, but such software enhance the appearance of the text, but such software
must not be required in order to get the general idea must not be required in order to get the general idea
of the content. Possible subtypes thus include any of the content. Possible subtypes thus include any
word processor format that can be read without word processor format that can be read without
resorting to software that understands the format. In resorting to software that understands the format. In
particular, formats that employ embeddded binary particular, formats that employ embeddded binary
formatting information are not considered directly formatting information are not considered directly
readable. A very simple and portable subtype, readable. A very simple and portable subtype,
richtext, was defined in RFC 1341 [RFC-1341], with a "richtext", was defined in RFC 1341 [RFC-1341], with a
further revision in RFC 1563 [RFC-1563] under the name further revision in RFC 1563 [RFC-1563] under the name
"enriched". "enriched".
(2) image -- image data. Image requires a display device (2) image -- image data. Image requires a display device
(such as a graphical display, a graphics printer, or a (such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial FAX machine) to view the information. An initial
subtype is defined for the widely-used image format subtype is defined for the widely-used image format
JPEG. JPEG.
(3) audio -- audio data. Audio requires an audio output (3) audio -- audio data. Audio requires an audio output
skipping to change at page 7, line 5 skipping to change at page 7, line 5
for "active" (computational) messaging, and word for "active" (computational) messaging, and word
processing formats that are not directly readable. processing formats that are not directly readable.
Note that security considerations may exist for some Note that security considerations may exist for some
types of application data, most notably types of application data, most notably
application/PostScript and any form of active application/PostScript and any form of active
messaging. These issues are discussed later in this messaging. These issues are discussed later in this
document. document.
The two composite top-level media types are: The two composite top-level media types are:
(1) multipart -- data consisting of multiple parts of (1) multipart -- data consisting of multiple entities of
independent data types. Four subtypes are initially independent data types. Four subtypes are initially
defined, including the basic "mixed" subtype specifying defined, including the basic "mixed" subtype specifying
a generic mixed set of parts, "alternative" for a generic mixed set of parts, "alternative" for
representing the same data in multiple formats, representing the same data in multiple formats,
"parallel" for parts intended to be viewed "parallel" for parts intended to be viewed
simultaneously, and "digest" for multipart entities in simultaneously, and "digest" for multipart entities in
which each part has a default type of "message/rfc822". which each part has a default type of "message/rfc822".
(2) message -- an encapsulated message. A body of media (2) message -- an encapsulated message. A body of media
type "message" is itself all or part of some kind of type "message" is itself all or a portion of some kind
message object. Such objects may in turn contain other of message object. Such objects may or may not in turn
messages and body parts of their own. The "rfc822" contain other entities. The "rfc822" subtype is used
subtype is used when the encapsulated content is itself when the encapsulated content is itself an RFC 822
an RFC 822 message. The "partial" subtype is defined message. The "partial" subtype is defined for partial
for partial RFC 822 messages, to permit the fragmented RFC 822 messages, to permit the fragmented transmission
transmission of bodies that are thought to be too large of bodies that are thought to be too large to be passed
to be passed through transport facilities in one piece. through transport facilities in one piece. Another
Another subtype, "external-body", is defined for subtype, "external-body", is defined for specifying
specifying large bodies by reference to an external large bodies by reference to an external data source.
data source.
It should be noted that the list of media type values given It should be noted that the list of media type values given
here may be augmented in time, via the mechanisms described here may be augmented in time, via the mechanisms described
above, and that the set of subtypes is expected to grow above, and that the set of subtypes is expected to grow
substantially. substantially.
6. Discrete Media Type Values 6. Discrete Media Type Values
Five of the seven initial media type values refer to discrete Five of the seven initial media type values refer to discrete
bodies. The content of such entities is handled by non-MIME bodies. The content of these types must be handled by non-MIME
mechanisms; they are opaque to MIME processors. mechanisms; they are opaque to MIME processors.
6.1. Text Media Type 6.1. Text Media Type
The text media type is intended for sending material which is The text media type is intended for sending material which is
principally textual in form. A "charset" parameter may be principally textual in form. A "charset" parameter may be
used to indicate the character set of the body text for some used to indicate the character set of the body text for some
text subtypes, notably including the subtype "text/plain", text subtypes, notably including the subtype "text/plain",
which indicates plain (unformatted) text. The default media which indicates plain (unformatted) text.
type for Internet mail if none is specified is "text/plain;
charset=us-ascii".
Beyond plain text, there are many formats for representing Beyond plain text, there are many formats for representing
what might be known as "extended text" -- text with embedded what might be known as "extended text" -- text with embedded
formatting and presentation information. An interesting formatting and presentation information. An interesting
characteristic of many such representations is that they are characteristic of many such representations is that they are
to some extent readable even without the software that to some extent readable even without the software that
interprets them. It is useful, then, to distinguish them, at interprets them. It is useful, then, to distinguish them, at
the highest level, from such unreadable data as images, audio, the highest level, from such unreadable data as images, audio,
or text represented in an unreadable form. In the absence of or text represented in an unreadable form. In the absence of
appropriate interpretation software, it is reasonable to show appropriate interpretation software, it is reasonable to show
skipping to change at page 9, line 29 skipping to change at page 9, line 26
the purposes of MIME to be the name of a character set, as the purposes of MIME to be the name of a character set, as
"character set" as defined in MIME-IMB. The rules regarding "character set" as defined in MIME-IMB. The rules regarding
line breaks detailed in the previous section must also be line breaks detailed in the previous section must also be
observed -- a character set whose definition does not conform observed -- a character set whose definition does not conform
to these rules cannot be used in a MIME text type. to these rules cannot be used in a MIME text type.
An initial list of predefined character set names can be found An initial list of predefined character set names can be found
at the end of this section. Additional character sets may be at the end of this section. Additional character sets may be
registered with IANA as described in RFC MIME-REG. registered with IANA as described in RFC MIME-REG.
Note that if the specified character set includes 8-bit data, Note that if the specified character set includes 8bit data, a
a Content-Transfer-Encoding header field and a corresponding Content-Transfer-Encoding header field and a corresponding
encoding on the data are required in order to transmit the encoding on the data are required in order to transmit the
body via some mail transfer protocols, such as SMTP. body via some mail transfer protocols, such as SMTP [RFC-821].
The default character set, US-ASCII, has been the subject of The default character set, US-ASCII, has been the subject of
some confusion and ambiguity in the past. Not only were there some confusion and ambiguity in the past. Not only were there
some ambiguities in the definition, there have been wide some ambiguities in the definition, there have been wide
variations in practice. In order to eliminate such ambiguity variations in practice. In order to eliminate such ambiguity
and variations in the future, it is strongly recommended that and variations in the future, it is strongly recommended that
new user agents explicitly specify a character set as a media new user agents explicitly specify a character set as a media
type parameter in the Content-Type header field. "US-ASCII" type parameter in the Content-Type header field. "US-ASCII"
does not indicate an arbitrary 7-bit character code, but does not indicate an arbitrary -bit character code, but
specifies that the body uses character coding that uses the specifies that the body uses character coding that uses the
exact correspondence of octets to characters specified in US- exact correspondence of octets to characters specified in US-
ASCII. National use variations of ISO 646 [ISO-646] are NOT ASCII. National use variations of ISO 646 [ISO-646] are NOT
US-ASCII and their use in Internet mail is explicitly US-ASCII and their use in Internet mail is explicitly
discouraged. The omission of the ISO 646 character set is discouraged. The omission of the ISO 646 character set from
deliberate in this regard. The character set name of "US- this document is deliberate in this regard. The character set
ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only. name of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-
ASCII] only. The character set name "ASCII" is reserved and
The character set name "ASCII" is reserved and must not be must not be used for any purpose.
used for any purpose.
NOTE: RFC 821 explicitly specifies "ASCII", and references an NOTE: RFC 821 explicitly specifies "ASCII", and references an
earlier version of the American Standard. Insofar as one of earlier version of the American Standard. Insofar as one of
the purposes of specifying a media type and character set is the purposes of specifying a media type and character set is
to permit the receiver to unambiguously determine how the to permit the receiver to unambiguously determine how the
sender intended the coded message to be interpreted, assuming sender intended the coded message to be interpreted, assuming
anything other than "strict ASCII" as the default would risk anything other than "strict ASCII" as the default would risk
unintentional and incompatible changes to the semantics of unintentional and incompatible changes to the semantics of
messages now being transmitted. This also implies that messages now being transmitted. This also implies that
messages containing characters coded according to national messages containing characters coded according to national
variations on ISO 646, or using code-switching procedures variations on ISO 646, or using code-switching procedures
(e.g., those of ISO 2022), as well as 8-bit or multiple octet (e.g., those of ISO 2022), as well as 8bit or multiple octet
character encodings MUST use an appropriate character set character encodings MUST use an appropriate character set
specification to be consistent with this specification. specification to be consistent with this specification.
The complete US-ASCII character set is listed in ANSI X3.4- The complete US-ASCII character set is listed in ANSI X3.4-
1986. Note that the control characters including DEL (0-31, 1986. Note that the control characters including DEL (0-31,
127) have no defined meaning apart from the combination CRLF 127) have no defined meaning apart from the combination CRLF
(US-ASCII values 13 and 10) indicating a new line. Two of the (US-ASCII values 13 and 10) indicating a new line. Two of the
characters have de facto meanings in wide use: FF (12) often characters have de facto meanings in wide use: FF (12) often
means "start subsequent text on the beginning of a new page"; means "start subsequent text on the beginning of a new page";
and TAB or HT (9) often (though not always) means "move the and TAB or HT (9) often (though not always) means "move the
cursor to the next available column after the current position cursor to the next available column after the current position
where the column number is a multiple of 8 (counting the first where the column number is a multiple of 8 (counting the first
column as column 0)." Apart from this, any use of the control column as column 0)." Aside from these conventions, any use
characters or DEL in a body must be part of a private of the control characters or DEL in a body must occur within
agreement between the sender and recipient. Such private the context of a private agreement between the sender and
agreements are discouraged and should be replaced by the other recipient. Such private agreements are discouraged and should
capabilities of this document. be replaced by the other capabilities of this document.
NOTE: Beyond US-ASCII, an enormous proliferation of character NOTE: Beyond US-ASCII, an enormous proliferation of character
sets is possible. It is the opinion of the IETF working group sets is possible. It is the opinion of the IETF working group
that a large number of character sets is NOT a good thing. We that a large number of character sets is NOT a good thing. We
would prefer to specify a SINGLE character set that can be would prefer to specify a SINGLE character set that can be
used universally for representing all of the world's languages used universally for representing all of the world's languages
in Internet mail. Unfortunately, existing practice in several in Internet mail. Unfortunately, existing practice in several
communities seems to point to the continued use of multiple communities seems to point to the continued use of multiple
character sets in the near future. For this reason, we define character sets in the near future. For this reason, we define
names for a small number of character sets for which a strong names for a small number of character sets for which a strong
skipping to change at page 11, line 15 skipping to change at page 11, line 13
(1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII]. (1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
(2) ISO-8859-X -- where "X" is to be replaced, as (2) ISO-8859-X -- where "X" is to be replaced, as
necessary, for the parts of ISO-8859 [ISO-8859]. Note necessary, for the parts of ISO-8859 [ISO-8859]. Note
that the ISO 646 character sets have deliberately been that the ISO 646 character sets have deliberately been
omitted in favor of their 8859 replacements, which are omitted in favor of their 8859 replacements, which are
the designated character sets for Internet mail. As of the designated character sets for Internet mail. As of
the publication of this document, the legitimate values the publication of this document, the legitimate values
for "X" are the digits 1 through 9. for "X" are the digits 1 through 9.
All of these character sets are used as pure 7- or 8-bit sets All of these character sets are used as pure 7bit or 8bit sets
without any shift or escape functions. The meaning of shift without any shift or escape functions. The meaning of shift
and escape sequences in these character sets is not defined. and escape sequences in these character sets is not defined.
The character sets specified above are the ones that were The character sets specified above are the ones that were
relatively uncontroversial during the drafting of MIME. This relatively uncontroversial during the drafting of MIME. This
document does not endorse the use of any particular character document does not endorse the use of any particular character
set other than US-ASCII, and recognizes that the future set other than US-ASCII, and recognizes that the future
evolution of world character sets remains unclear. It is evolution of world character sets remains unclear. It is
expected that in the future, additional character sets will be expected that in the future, additional character sets will be
registered for use in MIME. registered for use in MIME.
skipping to change at page 11, line 47 skipping to change at page 11, line 45
unless absolutely necessary. unless absolutely necessary.
The "charset" parameter has been defined primarily for the The "charset" parameter has been defined primarily for the
purpose of textual data, and is described in this section for purpose of textual data, and is described in this section for
that reason. However, it is conceivable that non-textual data that reason. However, it is conceivable that non-textual data
might also wish to specify a charset value for some purpose, might also wish to specify a charset value for some purpose,
in which case the same syntax and values should be used. in which case the same syntax and values should be used.
In general, composition software should always use the "lowest In general, composition software should always use the "lowest
common denominator" character set possible. For example, if a common denominator" character set possible. For example, if a
body contains only US-ASCII characters, it should be marked as body contains only US-ASCII characters, it SHOULD be marked as
being in the US-ASCII character set, not ISO-8859-1, which, being in the US-ASCII character set, not ISO-8859-1, which,
like all the ISO-8859 family of character sets, is a superset like all the ISO-8859 family of character sets, is a superset
of US-ASCII. More generally, if a widely-used character set of US-ASCII. More generally, if a widely-used character set
is a subset of another character set, and a body contains only is a subset of another character set, and a body contains only
characters in the widely-used subset, it should be labelled as characters in the widely-used subset, it should be labelled as
being in that subset. This will increase the chances that the being in that subset. This will increase the chances that the
recipient will be able to view the resulting object correctly. recipient will be able to view the resulting entity correctly.
6.1.3. Plain Subtype 6.1.3. Plain Subtype
The simplest and most important subtype of text is "plain". The simplest and most important subtype of text is "plain".
This indicates plain (unformatted) text. The default media This indicates plain (unformatted) text. The default media
type of "text/plain; charset=us-ascii" for Internet mail type of "text/plain; charset=us-ascii" for Internet mail
describes existing Internet practice. That is, it is the type describes existing Internet practice. That is, it is the type
of body defined by RFC 822. of body defined by RFC 822.
No other text subtype is defined by this document. No other text subtype is defined by this document.
skipping to change at page 12, line 33 skipping to change at page 12, line 31
"plain" as long as the MIME implementation knows how to handle "plain" as long as the MIME implementation knows how to handle
the charset. Unrecognized subtypes which also specify an the charset. Unrecognized subtypes which also specify an
unrecognized charset should be treated as "application/octet- unrecognized charset should be treated as "application/octet-
stream". stream".
6.2. Image Media Type 6.2. Image Media Type
A media type of "image" indicates that the body contains an A media type of "image" indicates that the body contains an
image. The subtype names the specific image format. These image. The subtype names the specific image format. These
names are not case sensitive. An initial subtype is "jpeg" for names are not case sensitive. An initial subtype is "jpeg" for
the JPEG format using JFIF encoding. the JPEG format using JFIF encoding [JPEG].
The list of image subtypes given here is neither exclusive nor The list of image subtypes given here is neither exclusive nor
exhaustive, and is expected to grow as more types are exhaustive, and is expected to grow as more types are
registered with IANA, as described in RFC MIME-REG. registered with IANA, as described in RFC MIME-REG.
Unrecognized subtypes of image should at a miniumum be treated Unrecognized subtypes of image should at a miniumum be treated
as "application/octet-stream". Implementations may optionally as "application/octet-stream". Implementations may optionally
elect to pass subtypes of image that they do not specifically elect to pass subtypes of image that they do not specifically
recognize to a robust general-purpose image viewing recognize to a secure and robust general-purpose image viewing
application, if such an application is available. application, if such an application is available.
NOTE: Using of a generic-purpose image viewing application
this way inherits the security problems of the most dangerous
type supported by the application.
6.3. Audio Media Type 6.3. Audio Media Type
A media type of "audio" indicates that the body contains audio A media type of "audio" indicates that the body contains audio
data. Although there is not yet a consensus on an "ideal" data. Although there is not yet a consensus on an "ideal"
audio format for use with computers, there is a pressing need audio format for use with computers, there is a pressing need
for a format capable of providing interoperable behavior. for a format capable of providing interoperable behavior.
The initial subtype of "basic" is specified to meet this The initial subtype of "basic" is specified to meet this
requirement by providing an absolutely minimal lowest common requirement by providing an absolutely minimal lowest common
denominator audio format. It is expected that richer formats denominator audio format. It is expected that richer formats
for higher quality and/or lower bandwidth audio will be for higher quality and/or lower bandwidth audio will be
defined by a later document. defined by a later document.
The content of the "audio/basic" subtype is single channel The content of the "audio/basic" subtype is single channel
audio encoded using 8-bit ISDN mu-law [PCM] at a sample rate audio encoded using 8bit ISDN mu-law [PCM] at a sample rate of
of 8000 Hz. 8000 Hz.
Unrecognized subtypes of audio should at a miniumum be treated Unrecognized subtypes of audio should at a miniumum be treated
as "application/octet-stream". Implementations may optionally as "application/octet-stream". Implementations may optionally
elect to pass subtypes of audio that they do not specifically elect to pass subtypes of audio that they do not specifically
recognize to a robust general-purpose audio playing recognize to a robust general-purpose audio playing
application, if such an application is available. application, if such an application is available.
6.4. Video Media Type 6.4. Video Media Type
A media type of "video" indicates that the body contains a A media type of "video" indicates that the body contains a
skipping to change at page 14, line 16 skipping to change at page 14, line 20
6.5. Application Media Type 6.5. Application Media Type
The "application" media type is to be used for discrete data The "application" media type is to be used for discrete data
which do not fit in any of the other categories, and which do not fit in any of the other categories, and
particularly for data to be processed by some type of particularly for data to be processed by some type of
application program. This is information which must be application program. This is information which must be
processed by an application before it is viewable or usable by processed by an application before it is viewable or usable by
a user. Expected uses for the application media type include a user. Expected uses for the application media type include
file transfer, spreadsheets, data for mail-based scheduling file transfer, spreadsheets, data for mail-based scheduling
systems, and languages for "active" (computational) messages. systems, and languages for "active" (computational) material.
(The latter, in particular, can pose security problems which (The latter, in particular, can pose security problems which
must be understood by implementors, and are considered in must be understood by implementors, and are considered in
detail in the discussion of the application/PostScript media detail in the discussion of the application/PostScript media
type.) type.)
For example, a meeting scheduler might define a standard For example, a meeting scheduler might define a standard
representation for information about proposed meeting dates. representation for information about proposed meeting dates.
An intelligent user agent would use this information to An intelligent user agent would use this information to
conduct a dialog with the user, and might then send additional conduct a dialog with the user, and might then send additional
material based on that dialog. More generally, there have material based on that dialog. More generally, there have
skipping to change at page 15, line 17 skipping to change at page 15, line 17
The "octet-stream" subtype is used to indicate that a body The "octet-stream" subtype is used to indicate that a body
contains arbitrary binary data. The set of currently defined contains arbitrary binary data. The set of currently defined
parameters is: parameters is:
(1) TYPE -- the general type or category of binary data. (1) TYPE -- the general type or category of binary data.
This is intended as information for the human recipient This is intended as information for the human recipient
rather than for any automatic processing. rather than for any automatic processing.
(2) PADDING -- the number of bits of padding that were (2) PADDING -- the number of bits of padding that were
appended to the bit-stream comprising the actual appended to the bit-stream comprising the actual
contents to produce the enclosed 8-bit byte-oriented contents to produce the enclosed 8bit byte-oriented
data. This is useful for enclosing a bit-stream in a data. This is useful for enclosing a bit-stream in a
body when the total number of bits is not a multiple of body when the total number of bits is not a multiple of
8. 8.
Both of these parameters are optional. Both of these parameters are optional.
An additional parameter, "CONVERSIONS", was defined in RFC An additional parameter, "CONVERSIONS", was defined in RFC
1341 but has since been removed. RFC 1341 also defined the 1341 but has since been removed. RFC 1341 also defined the
use of a "NAME" parameter which gave a suggested file name to use of a "NAME" parameter which gave a suggested file name to
be used if the data were to be written to a file. This has be used if the data were to be written to a file. This has
been deprecated in anticipation of a separate Content- been deprecated in anticipation of a separate Content-
Disposition header field, to be defined in a subsequent RFC. Disposition header field, to be defined in a subsequent RFC.
The recommended action for an implementation that receives an The recommended action for an implementation that receives an
application/octet-stream object is to simply offer to put the application/octet-stream entity is to simply offer to put the
data in a file, with any Content-Transfer-Encoding undone, or data in a file, with any Content-Transfer-Encoding undone, or
perhaps to use it as input to a user-specified process. perhaps to use it as input to a user-specified process.
To reduce the danger of transmitting rogue programs, it is To reduce the danger of transmitting rogue programs, it is
strongly recommended that implementations NOT implement a strongly recommended that implementations NOT implement a
path-search mechanism whereby an arbitrary program named in path-search mechanism whereby an arbitrary program named in
the Content-Type parameter (e.g., an "interpreter=" parameter) the Content-Type parameter (e.g., an "interpreter=" parameter)
is found and executed using the message body as input. is found and executed using the message body as input.
6.5.2. PostScript Subtype 6.5.2. PostScript Subtype
skipping to change at page 16, line 33 skipping to change at page 16, line 33
discouraged from simply sending PostScript bodies to "off- discouraged from simply sending PostScript bodies to "off-
the-shelf" interpreters. While it is usually safe to send the-shelf" interpreters. While it is usually safe to send
PostScript to a printer, where the potential for harm is PostScript to a printer, where the potential for harm is
greatly constrained by typical printer environments, greatly constrained by typical printer environments,
implementors should consider all of the following before they implementors should consider all of the following before they
add interactive display of PostScript bodies to their MIME add interactive display of PostScript bodies to their MIME
readers. readers.
The remainder of this section outlines some, though probably The remainder of this section outlines some, though probably
not all, of the possible problems with the transport of not all, of the possible problems with the transport of
PostScript objects. PostScript entities.
(1) Dangerous operations in the PostScript language (1) Dangerous operations in the PostScript language
include, but may not be limited to, the PostScript include, but may not be limited to, the PostScript
operators "deletefile", "renamefile", "filenameforall", operators "deletefile", "renamefile", "filenameforall",
and "file". "File" is only dangerous when applied to and "file". "File" is only dangerous when applied to
something other than standard input or output. something other than standard input or output.
Implementations may also define additional nonstandard Implementations may also define additional nonstandard
file operators; these may also pose a threat to file operators; these may also pose a threat to
security. "Filenameforall", the wildcard file search security. "Filenameforall", the wildcard file search
operator, may appear at first glance to be harmless. operator, may appear at first glance to be harmless.
skipping to change at page 19, line 39 skipping to change at page 19, line 39
7. Composite Media Type Values 7. Composite Media Type Values
The remaining two of the seven initial Content-Type values The remaining two of the seven initial Content-Type values
refer to composite entities. Composite entities are handled refer to composite entities. Composite entities are handled
using MIME mechanisms -- a MIME processor typically handles using MIME mechanisms -- a MIME processor typically handles
the body directly. the body directly.
7.1. Multipart Media Type 7.1. Multipart Media Type
In the case of multiple part entities, in which one or more In the case of multipart entities, in which one or more
different sets of data are combined in a single body, a different sets of data are combined in a single body, a
"multipart" media type field must appear in the entity's "multipart" media type field must appear in the entity's
header. The body must then contain one or more "body parts," header. The body must then contain one or more body parts,
each preceded by a boundary delimiter line, and the last one each preceded by a boundary delimiter line, and the last one
followed by a closing boundary delimiter line. After its followed by a closing boundary delimiter line. After its
boundary delimiter line, each body part then consists of a boundary delimiter line, each body part then consists of a
header area, a blank line, and a body area. Thus a body part header area, a blank line, and a body area. Thus a body part
is similar to an RFC 822 message in syntax, but different in is similar to an RFC 822 message in syntax, but different in
meaning. meaning.
A body part is NOT to be interpreted as actually being an RFC A body part is an entity and hence is NOT to be interpreted as
822 message. To begin with, NO header fields are actually actually being an RFC 822 message. To begin with, NO header
required in body parts. A body part that starts with a blank fields are actually required in body parts. A body part that
line, therefore, is allowed and is a body part for which all starts with a blank line, therefore, is allowed and is a body
default values are to be assumed. In such a case, the absence part for which all default values are to be assumed. In such
of a Content-Type header usually indicates that the a case, the absence of a Content-Type header usually indicates
corresponding body has a content-type of "text/plain; that the corresponding body has a content-type of "text/plain;
charset=US-ASCII". charset=US-ASCII".
The only header fields that have defined meaning for body The only header fields that have defined meaning for body
parts are those the names of which begin with "Content-". All parts are those the names of which begin with "Content-". All
other header fields are generally to be ignored in body parts. other header fields are generally to be ignored in body parts.
Although they should generally be retained if at all possible, Although they should generally be retained if at all possible,
they may be discarded by gateways if necessary. Such other they may be discarded by gateways if necessary. Such other
fields are permitted to appear in body parts but must not be fields are permitted to appear in body parts but must not be
depended on. "X-" fields may be created for experimental or depended on. "X-" fields may be created for experimental or
private purposes, with the recognition that the information private purposes, with the recognition that the information
skipping to change at page 20, line 39 skipping to change at page 20, line 39
X.400 mail, for example, must be able to tell the difference X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part between a body part that contains an image and a body part
that contains an encapsulated message, the body of which is a that contains an encapsulated message, the body of which is a
JPEG image. In order to represent the latter, the body part JPEG image. In order to represent the latter, the body part
must have "Content-Type: message/rfc822", and its body (after must have "Content-Type: message/rfc822", and its body (after
the blank line) must be the encapsulated message, with its own the blank line) must be the encapsulated message, with its own
"Content-Type: image/jpeg" header field. The use of similar "Content-Type: image/jpeg" header field. The use of similar
syntax facilitates the conversion of messages to body parts, syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which understood by implementors. (For the special case in which
all parts actually are messages, a "digest" subtype is also most parts actually are messages, a "digest" subtype is also
defined.) defined.)
As stated previously, each body part is preceded by a boundary As stated previously, each body part is preceded by a boundary
delimiter line that contains the boundary delimiter. The delimiter line that contains the boundary delimiter. The
boundary delimiter MUST NOT appear inside any of the boundary delimiter MUST NOT appear inside any of the
encapsulated parts, on a line by itself or as the prefix of encapsulated parts, on a line by itself or as the prefix of
any line. This implies that it is crucial that the composing any line. This implies that it is crucial that the composing
agent be able to choose and specify a unique boundary agent be able to choose and specify a unique boundary
parameter value that does not contain the boundary parameter parameter value that does not contain the boundary parameter
value of an enclosing multipart as a prefix. value of an enclosing multipart as a prefix.
skipping to change at page 21, line 19 skipping to change at page 21, line 19
but must conform to the required syntax for the multipart but must conform to the required syntax for the multipart
type. This requirement ensures that all conformant user type. This requirement ensures that all conformant user
agents will at least be able to recognize and separate the agents will at least be able to recognize and separate the
parts of any multipart entity, even those of an unrecognized parts of any multipart entity, even those of an unrecognized
subtype. subtype.
As stated in the definition of the Content-Transfer-Encoding As stated in the definition of the Content-Transfer-Encoding
field [MIME-IMB], no encoding other than "7bit", "8bit", or field [MIME-IMB], no encoding other than "7bit", "8bit", or
"binary" is permitted for entities of type "multipart". The "binary" is permitted for entities of type "multipart". The
multipart boundary delimiters and header fields are always multipart boundary delimiters and header fields are always
represented as 7-bit US-ASCII in any case (though the header represented as 7bit US-ASCII in any case (though the header
fields may encode non-US-ASCII header text as per RFC MIME- fields may encode non-US-ASCII header text as per RFC MIME-
HEADERS) and data within the body parts can be encoded on a HEADERS) and data within the body parts can be encoded on a
part-by-part basis, with Content-Transfer-Encoding fields for part-by-part basis, with Content-Transfer-Encoding fields for
each appropriate body part. each appropriate body part.
7.1.1. Common Syntax 7.1.1. Common Syntax
This section defines a common syntax for subtypes of This section defines a common syntax for subtypes of
multipart. All subtypes of multipart must use this syntax. A multipart. All subtypes of multipart must use this syntax. A
simple example of a multipart message also appears in this simple example of a multipart message also appears in this
skipping to change at page 25, line 13 skipping to change at page 25, line 13
another multipart entity is explicitly allowed. In such another multipart entity is explicitly allowed. In such
cases, for obvious reasons, care must be taken to ensure that cases, for obvious reasons, care must be taken to ensure that
each nested multipart entity uses a different boundary each nested multipart entity uses a different boundary
delimiter. See RFC MIME-CONF for an example of nested delimiter. See RFC MIME-CONF for an example of nested
multipart entities. multipart entities.
The use of the multipart media type with only a single body The use of the multipart media type with only a single body
part may be useful in certain contexts, and is explicitly part may be useful in certain contexts, and is explicitly
permitted. permitted.
NOTE: Experience has shown that a multipart media type with a
single body part is useful for sending non-text media types.
It has the advantage of providing the preamble as a place to
include decoding instructions. In addition, a number of SMTP
gateways move or remove the MIME headers, and a clever MIME
decoder can take a good guess at multipart boundaries even in
the absence of the Content-Type header and thereby successful
decode the message.
The only mandatory global parameter for the multipart media The only mandatory global parameter for the multipart media
type is the boundary parameter, which consists of 1 to 70 type is the boundary parameter, which consists of 1 to 70
characters from a set of characters known to be very robust characters from a set of characters known to be very robust
through mail gateways, and NOT ending with white space. (If a through mail gateways, and NOT ending with white space. (If a
boundary delimiter line appears to end with white space, the boundary delimiter line appears to end with white space, the
white space must be presumed to have been added by a gateway, white space must be presumed to have been added by a gateway,
and must be deleted.) It is formally specified by the and must be deleted.) It is formally specified by the
following BNF: following BNF:
boundary := 0*69<bchars> bcharsnospace boundary := 0*69<bchars> bcharsnospace
skipping to change at page 26, line 26 skipping to change at page 26, line 32
close-delimiter := delimiter "--" close-delimiter := delimiter "--"
preamble := discard-text preamble := discard-text
epilogue := discard-text epilogue := discard-text
discard-text := *(*text CRLF) *text discard-text := *(*text CRLF) *text
; To be ignored upon receipt. ; To be ignored upon receipt.
body-part := <"message" as defined in RFC 822, with all body-part := MIME-part-headers [CRLF *OCTET]
header fields optional, not starting with the ; Lines in a body-part must not start
specified dash-boundary, and with the ; with the specified dash-boundary and
delimiter not occurring anywhere in the ; the delimiter must not appear anywhere
body part. Note that the semantics of a ; in the body part. Note that the
part differ from the semantics of a message, ; semantics of a body-part differ from
as described in the text.> ; the semantics of a message, as
; described in the text.
IMPORTANT NOTE: The free insertion of linear-white-space and OCTET := <any 0-255 octet value>
RFC 822 comments between the elements shown in this BNF is NOT
IMPORTANT: The free insertion of linear-white-space and RFC
822 comments between the elements shown in this BNF is NOT
allowed since this BNF does not specify a structured header allowed since this BNF does not specify a structured header
field. field.
NOTE: In certain transport enclaves, RFC 822 restrictions NOTE: In certain transport enclaves, RFC 822 restrictions
such as the one that limits bodies to printable US-ASCII such as the one that limits bodies to printable US-ASCII
characters may not be in force. (That is, the transport characters may not be in force. (That is, the transport
domains may resemble standard Internet mail transport as domains may exist that resemble standard Internet mail
specified in RFC 821 and assumed by RFC 822, but without transport as specified in RFC 821 and assumed by RFC 822, but
certain restrictions.) The relaxation of these restrictions without certain restrictions.) The relaxation of these
should be construed as locally extending the definition of restrictions should be construed as locally extending the
bodies, for example to include octets outside of the US-ASCII definition of bodies, for example to include octets outside of
range, as long as these extensions are supported by the the US-ASCII range, as long as these extensions are supported
transport and adequately documented in the Content-Transfer- by the transport and adequately documented in the Content-
Encoding header field. However, in no event are headers Transfer-Encoding header field. However, in no event are
(either message headers or body-part headers) allowed to headers (either message headers or body part headers) allowed
contain anything other than US-ASCII characters. to contain anything other than US-ASCII characters.
NOTE: Conspicuously missing from the multipart type is a NOTE: Conspicuously missing from the multipart type is a
notion of structured, related body parts. In general, it notion of structured, related body parts. It is recommended
seems premature to try to standardize interpart structure yet. that those wishing to provide more structured or integrated
It is recommended that those wishing to provide a more multipart messaging facilities should define subtypes of
structured or integrated multipart messaging facility should multipart that are syntactically identical but define
define a subtype of multipart that is syntactically identical, relationships between the various parts. For example, subtypes
but that always expects the inclusion of a distinguished part of multipart could be defined that include a distinguished
that can be used to specify the structure and integration of part which in turn is used to specify the relationships
the other parts, probably referring to them by their Content- between the other parts, probably referring to them by their
ID field. If this approach is used, other implementations Content-ID field. Old implementations will not recognize the
will not recognize the new subtype, but will treat it as the new subtype if this approach is used, but will treat it as
primary subtype (multipart/mixed) and will thus be able to multipart/mixed and will thus be able to show the user the
show the user the parts that are recognized. parts that are recognized.
7.1.2. Handling Nested Messages and Multiparts 7.1.2. Handling Nested Messages and Multiparts
The "message/rfc822" subtype defined in a subsequent section The "message/rfc822" subtype defined in a subsequent section
of this document has no terminating condition other than of this document has no terminating condition other than
running out of data. Similarly, an improperly truncated running out of data. Similarly, an improperly truncated
multipart object may not have any terminating boundary marker, multipart entity may not have any terminating boundary marker,
and can turn up operationally due to mail system malfunctions. and can turn up operationally due to mail system malfunctions.
It is essential that such objects be handled correctly when It is essential that such entities be handled correctly when
they are themselves imbedded inside of another multipart they are themselves imbedded inside of another multipart
structure. MIME implementations are therefore required to structure. MIME implementations are therefore required to
recognize outer level boundary markers at ANY level of inner recognize outer level boundary markers at ANY level of inner
nesting. It is not sufficient to only check for the next nesting. It is not sufficient to only check for the next
expected marker or other terminating condition. expected marker or other terminating condition.
7.1.3. Mixed Subtype 7.1.3. Mixed Subtype
The "mixed" subtype of multipart is intended for use when the The "mixed" subtype of multipart is intended for use when the
body parts are independent and need to be bundled in a body parts are independent and need to be bundled in a
particular order. Any multipart subtypes that an particular order. Any multipart subtypes that an
implementation does not recognize must be treated as being of implementation does not recognize must be treated as being of
subtype "mixed". subtype "mixed".
7.1.4. Alternative Subtype 7.1.4. Alternative Subtype
The multipart/alternative type is syntactically identical to The multipart/alternative type is syntactically identical to
multipart/mixed, but the semantics are different. In multipart/mixed, but the semantics are different. In
particular, each of the parts is an "alternative" version of particular, each of the body parts is an "alternative" version
the same information. of the same information.
Systems should recognize that the content of the various parts Systems should recognize that the content of the various parts
are interchangeable. Systems should choose the "best" type are interchangeable. Systems should choose the "best" type
based on the local environment and references, in some cases based on the local environment and references, in some cases
even through user interaction. As with multipart/mixed, the even through user interaction. As with multipart/mixed, the
order of body parts is significant. In this case, the order of body parts is significant. In this case, the
alternatives appear in an order of increasing faithfulness to alternatives appear in an order of increasing faithfulness to
the original content. In general, the best choice is the LAST the original content. In general, the best choice is the LAST
part of a type supported by the recipient system's local part of a type supported by the recipient system's local
environment. environment.
skipping to change at page 30, line 20 skipping to change at page 30, line 20
It may be the case that some user agents, if they can It may be the case that some user agents, if they can
recognize more than one of the formats, will prefer to offer recognize more than one of the formats, will prefer to offer
the user the choice of which format to view. This makes the user the choice of which format to view. This makes
sense, for example, if a message includes both a nicely- sense, for example, if a message includes both a nicely-
formatted image version and an easily-edited text version. formatted image version and an easily-edited text version.
What is most critical, however, is that the user not What is most critical, however, is that the user not
automatically be shown multiple versions of the same data. automatically be shown multiple versions of the same data.
Either the user should be shown the last recognized version or Either the user should be shown the last recognized version or
should be given the choice. should be given the choice.
NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each
Each part of a multipart/alternative entity represents the part of a multipart/alternative entity represents the same
same data, but the mappings between the two are not data, but the mappings between the two are not necessarily
necessarily without information loss. For example, without information loss. For example, information is lost
information is lost when translating ODA to PostScript or when translating ODA to PostScript or plain text. It is
plain text. It is recommended that each part should have a recommended that each part should have a different Content-ID
different Content-ID value in the case where the information value in the case where the information content of the two
content of the two parts is not identical. And when the parts is not identical. And when the information content is
information content is identical -- for example, where several identical -- for example, where several parts of type
parts of type "message/external-body" specify alternate ways "message/external-body" specify alternate ways to access the
to access the identical data -- the same Content-ID field identical data -- the same Content-ID field value should be
value should be used, to optimize any caching mechanisms that used, to optimize any caching mechanisms that might be present
might be present on the recipient's end. However, the on the recipient's end. However, the Content-ID values used
Content-ID values used by the parts should NOT be the same by the parts should NOT be the same Content-ID value that
Content-ID value that describes the multipart/alternative as a describes the multipart/alternative as a whole, if there is
whole, if there is any such Content-ID field. That is, one any such Content-ID field. That is, one Content-ID value will
Content-ID value will refer to the multipart/alternative refer to the multipart/alternative entity, while one or more
entity, while one or more other Content-ID values will refer other Content-ID values will refer to the parts inside it.
to the parts inside it.
7.1.5. Digest Subtype 7.1.5. Digest Subtype
This document defines a "digest" subtype of the multipart This document defines a "digest" subtype of the multipart
Content-Type. This type is syntactically identical to Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In multipart/mixed, but the semantics are different. In
particular, in a digest, the default Content-Type value for a particular, in a digest, the default Content-Type value for a
body part is changed from "text/plain" to "message/rfc822". body part is changed from "text/plain" to "message/rfc822".
This is done to allow a more readable digest format that is This is done to allow a more readable digest format that is
largely compatible (except for the quoting convention) with largely compatible (except for the quoting convention) with
skipping to change at page 33, line 8 skipping to change at page 33, line 8
A media type of "message/rfc822" indicates that the body A media type of "message/rfc822" indicates that the body
contains an encapsulated message, with the syntax of an RFC contains an encapsulated message, with the syntax of an RFC
822 message. However, unlike top-level RFC 822 messages, the 822 message. However, unlike top-level RFC 822 messages, the
restriction that each message/rfc822 body must include a restriction that each message/rfc822 body must include a
"From", "Date", and at least one destination header is removed "From", "Date", and at least one destination header is removed
and replaced with the requirement that at least one of "From", and replaced with the requirement that at least one of "From",
"Subject", or "Date" must be present. "Subject", or "Date" must be present.
No encoding other than "7bit", "8bit", or "binary" is No encoding other than "7bit", "8bit", or "binary" is
permitted for body parts of type "message/rfc822". The permitted for the body of a "message/rfc822" entity. The
message header fields are always US-ASCII in any case, and message header fields are always US-ASCII in any case, and
data within the body can still be encoded, in which case the data within the body can still be encoded, in which case the
Content-Transfer-Encoding header field in the encapsulated Content-Transfer-Encoding header field in the encapsulated
message will reflect this. Non-US-ASCII text in the headers message will reflect this. Non-US-ASCII text in the headers
of an encapsulated message can be specified using the of an encapsulated message can be specified using the
mechanisms described in RFC MIME-HEADERS. mechanisms described in RFC MIME-HEADERS.
It should be noted that, despite the use of the numbers "822", It should be noted that, despite the use of the numbers "822",
a message/rfc822 entity can include enhanced information as a message/rfc822 entity can include enhanced information as
defined in this document. In other words, a message/rfc822 defined in this document. In other words, a message/rfc822
skipping to change at page 34, line 24 skipping to change at page 34, line 24
But the third piece MUST specify the total number of But the third piece MUST specify the total number of
fragments: fragments:
Content-Type: Message/Partial; number=3; total=3; Content-Type: Message/Partial; number=3; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com" id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Note that fragment numbering begins with 1, not 0. Note that fragment numbering begins with 1, not 0.
When the fragments of an entity broken up in this manner are When the fragments of an entity broken up in this manner are
put together, the result is a complete MIME entity, which may put together, the result is always a complete MIME entity,
have its own Content-Type header field, and thus may contain which may have its own Content-Type header field, and thus may
any other data type. contain any other data type.
7.2.2.1. Message Fragmentation and Reassembly 7.2.2.1. Message Fragmentation and Reassembly
The semantics of a reassembled partial message must be those The semantics of a reassembled partial message must be those
of the "inner" message, rather than of a message containing of the "inner" message, rather than of a message containing
the inner message. This makes it possible, for example, to the inner message. This makes it possible, for example, to
send a large audio message as several partial messages, and send a large audio message as several partial messages, and
still have it appear to the recipient as a simple audio still have it appear to the recipient as a simple audio
message rather than as an encapsulated message containing an message rather than as an encapsulated message containing an
audio message. That is, the encapsulation of the message is audio message. That is, the encapsulation of the message is
skipping to change at page 36, line 36 skipping to change at page 36, line 36
MIME-Version: 1.0 MIME-Version: 1.0
Content-type: audio/basic Content-type: audio/basic
Content-transfer-encoding: base64 Content-transfer-encoding: base64
... first half of encoded audio data goes here ... ... first half of encoded audio data goes here ...
... second half of encoded audio data goes here ... ... second half of encoded audio data goes here ...
Because data of type "message" may never be encoded in base64 Because data of type "message" may never be encoded in base64
or quoted-printable, a problem might arise if message/partial or quoted-printable, a problem might arise if message/partial
entities are constructed in an environment that supports entities are constructed in an environment that supports
binary or 8-bit transport. The problem is that the binary binary or 8bit transport. The problem is that the binary data
data would be split into multiple message/partial messages, would be split into multiple message/partial messages, each of
each of them requiring binary transport. If such messages them requiring binary transport. If such messages were
were encountered at a gateway into a 7-bit transport encountered at a gateway into a 7bit transport environment,
environment, there would be no way to properly encode them for there would be no way to properly encode them for the 7bit
the 7-bit world, aside from waiting for all of the fragments, world, aside from waiting for all of the fragments,
reassembling the inner message, and then encoding the reassembling the inner message, and then encoding the
reassembled data in base64 or quoted-printable. Since it is reassembled data in base64 or quoted-printable. Since it is
possible that different fragments might go through different possible that different fragments might go through different
gateways, even this is not an acceptable solution. For this gateways, even this is not an acceptable solution. For this
reason, it is specified that MIME entities of type reason, it is specified that entities of type message/partial
message/partial must always have a content-transfer-encoding must always have a content-transfer-encoding of 7bit (the
of 7-bit (the default). In particular, even in environments default). In particular, even in environments that support
that support binary or 8-bit transport, the use of a content- binary or 8bit transport, the use of a content-transfer-
transfer-encoding of "8bit" or "binary" is explicitly encoding of "8bit" or "binary" is explicitly prohibited for
prohibited for entities of type message/partial. MIME entities of type message/partial.
Because some message transfer agents may choose to Because some message transfer agents may choose to
automatically fragment large messages, and because such agents automatically fragment large messages, and because such agents
may use very different fragmentation thresholds, it is may use very different fragmentation thresholds, it is
possible that the pieces of a partial message, upon possible that the pieces of a partial message, upon
reassembly, may prove themselves to comprise a partial reassembly, may prove themselves to comprise a partial
message. This is explicitly permitted. message. This is explicitly permitted.
The inclusion of a "References" field in the headers of the The inclusion of a "References" field in the headers of the
second and subsequent pieces of a fragmented message that second and subsequent pieces of a fragmented message that
skipping to change at page 37, line 35 skipping to change at page 37, line 35
it if it is encountered in the context of conversion to and it if it is encountered in the context of conversion to and
from message/partial fragments. from message/partial fragments.
7.2.3. External-Body Subtype 7.2.3. External-Body Subtype
The external-body subtype indicates that the actual body data The external-body subtype indicates that the actual body data
are not included, but merely referenced. In this case, the are not included, but merely referenced. In this case, the
parameters describe a mechanism for accessing the external parameters describe a mechanism for accessing the external
data. data.
When an entity is of type "message/external-body", it consists When a MIME entity is of type "message/external-body", it
of a header, two consecutive CRLFs, and the message header for consists of a header, two consecutive CRLFs, and the message
the encapsulated message. If another pair of consecutive header for the encapsulated message. If another pair of
CRLFs appears, this of course ends the message header for the consecutive CRLFs appears, this of course ends the message
encapsulated message. However, since the encapsulated header for the encapsulated message. However, since the
message's body is itself external, it does NOT appear in the encapsulated message's body is itself external, it does NOT
area that follows. For example, consider the following appear in the area that follows. For example, consider the
message: following message:
Content-type: message/external-body; Content-type: message/external-body;
access-type=local-file; access-type=local-file;
name="/u/nsb/Me.jpeg" name="/u/nsb/Me.jpeg"
Content-type: image/jpeg Content-type: image/jpeg
Content-ID: <id42@guppylake.bellcore.com> Content-ID: <id42@guppylake.bellcore.com>
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY! THIS IS NOT REALLY THE BODY!
skipping to change at page 38, line 40 skipping to change at page 38, line 40
Note that, as specified here, the tokens that describe Note that, as specified here, the tokens that describe
external-body data, such as file names and mail server external-body data, such as file names and mail server
commands, are required to be in the US-ASCII character set. commands, are required to be in the US-ASCII character set.
If this proves problematic in practice, a new mechanism may be If this proves problematic in practice, a new mechanism may be
required as a future extension to MIME, either as newly required as a future extension to MIME, either as newly
defined access-types for message/external-body or by some defined access-types for message/external-body or by some
other mechanism. other mechanism.
As with message/partial, MIME entities of type As with message/partial, MIME entities of type
message/external-body MUST have a content-transfer-encoding of message/external-body MUST have a content-transfer-encoding of
7-bit (the default). In particular, even in environments that 7bit (the default). In particular, even in environments that
support binary or 8-bit transport, the use of a content- support binary or 8bit transport, the use of a content-
transfer-encoding of "8bit" or "binary" is explicitly transfer-encoding of "8bit" or "binary" is explicitly
prohibited for entities of type message/external-body. prohibited for entities of type message/external-body.
7.2.3.1. General External-Body Parameters 7.2.3.1. General External-Body Parameters
The parameters that may be used with any message/external-body The parameters that may be used with any message/external-body
are: are:
(1) ACCESS-TYPE -- A word indicating the supported access (1) ACCESS-TYPE -- A word indicating the supported access
mechanism by which the file or data may be obtained. mechanism by which the file or data may be obtained.
skipping to change at page 41, line 36 skipping to change at page 41, line 36
visible, while a single asterisk may be used to visible, while a single asterisk may be used to
indicate a file that is expected to be universally indicate a file that is expected to be universally
available, e.g., via a global file system. available, e.g., via a global file system.
7.2.3.5. The 'mail-server' Access-Type 7.2.3.5. The 'mail-server' Access-Type
The "mail-server" access-type indicates that the actual body The "mail-server" access-type indicates that the actual body
is available from a mail server. Two additional parameters is available from a mail server. Two additional parameters
are defined for this access-type: are defined for this access-type:
(1) SERVER -- The email address of the mail server from (1) SERVER -- The addr-spec of the mail server from which
which the actual body data can be obtained. This the actual body data can be obtained. This parameter
parameter is mandatory for the "mail-server" access- is mandatory for the "mail-server" access-type.
type.
(2) SUBJECT -- The subject that is to be used in the mail (2) SUBJECT -- The subject that is to be used in the mail
that is sent to obtain the data. Note that keying mail that is sent to obtain the data. Note that keying mail
servers on Subject lines is NOT recommended, but such servers on Subject lines is NOT recommended, but such
mail servers are known to exist. This is an optional mail servers are known to exist. This is an optional
parameter. parameter.
Because mail servers accept a variety of syntaxes, some of Because mail servers accept a variety of syntaxes, some of
which is multiline, the full command to be sent to a mail which is multiline, the full command to be sent to a mail
server is not included as a parameter in the content-type server is not included as a parameter in the content-type
skipping to change at page 42, line 24 skipping to change at page 42, line 24
the phantom body. Implementations must include the phantom the phantom body. Implementations must include the phantom
body in the body of the message it sends to the mail server body in the body of the message it sends to the mail server
address to retrieve the relevant data. address to retrieve the relevant data.
Unlike other access-types, mail-server access is asynchronous Unlike other access-types, mail-server access is asynchronous
and will happen at an unpredictable time in the future. For and will happen at an unpredictable time in the future. For
this reason, it is important that there be a mechanism by this reason, it is important that there be a mechanism by
which the returned data can be matched up with the original which the returned data can be matched up with the original
message/external-body entity. MIME mail servers must use the message/external-body entity. MIME mail servers must use the
same Content-ID field on the returned message that was used in same Content-ID field on the returned message that was used in
the original message/external-body entity, to facilitate such the original message/external-body entities, to facilitate
matching. such matching.
7.2.3.6. External-Body Security Issues 7.2.3.6. External-Body Security Issues
Message/external-body entities give rise to two important Message/external-body entities give rise to two important
security issues: security issues:
(1) Accessing data via a message/external-body reference (1) Accessing data via a message/external-body reference
effectively results in the message recipient performing effectively results in the message recipient performing
an operation that was specified by the message an operation that was specified by the message
originator. It is therefore possible for the message originator. It is therefore possible for the message
skipping to change at page 43, line 35 skipping to change at page 43, line 35
issues -- the only difference is that MIME provides for issues -- the only difference is that MIME provides for
automatic retrieval of such material, and users may automatic retrieval of such material, and users may
place unwarranted trust is such automatic retrieval place unwarranted trust is such automatic retrieval
mechanisms. mechanisms.
7.2.3.7. Examples and Further Explanations 7.2.3.7. Examples and Further Explanations
When the external-body mechanism is used in conjunction with When the external-body mechanism is used in conjunction with
the multipart/alternative media type it extends the the multipart/alternative media type it extends the
functionality of multipart/alternative to include the case functionality of multipart/alternative to include the case
where the same object is provided in the same format but via where the same entity is provided in the same format but via
different accces mechanisms. When this is done the originator different accces mechanisms. When this is done the originator
of the message must order the part first in terms of preferred of the message must order the parts first in terms of
formats and then by preferred access mechanisms. The preferred formats and then by preferred access mechanisms.
recipient's viewer should then evaluate the list both in terms The recipient's viewer should then evaluate the list both in
of format and access mechanisms. terms of format and access mechanisms.
With the emerging possibility of very wide-area file systems, With the emerging possibility of very wide-area file systems,
it becomes very hard to know in advance the set of machines it becomes very hard to know in advance the set of machines
where a file will and will not be accessible directly from the where a file will and will not be accessible directly from the
file system. Therefore it may make sense to provide both a file system. Therefore it may make sense to provide both a
file name, to be tried directly, and the name of one or more file name, to be tried directly, and the name of one or more
sites from which the file is known to be accessible. An sites from which the file is known to be accessible. An
implementation can try to retrieve remote files using FTP or implementation can try to retrieve remote files using FTP or
any other protocol, using anonymous file retrieval or any other protocol, using anonymous file retrieval or
prompting the user for the necessary name and password. If an prompting the user for the necessary name and password. If an
external body is accessible via multiple mechanisms, the external body is accessible via multiple mechanisms, the
sender may include multiple parts of type message/external- sender may include multiple entities of type
body within an entity of type multipart/alternative. message/external-body within the body parts of an enclosing
multipart/alternative entity.
However, the external-body mechanism is not intended to be However, the external-body mechanism is not intended to be
limited to file retrieval, as shown by the mail-server limited to file retrieval, as shown by the mail-server
access-type. Beyond this, one can imagine, for example, using access-type. Beyond this, one can imagine, for example, using
a video server for external references to video clips. a video server for external references to video clips.
The embedded message header fields which appear in the body of The embedded message header fields which appear in the body of
the message/external-body data must be used to declare the the message/external-body data must be used to declare the
media type of the external body if it is anything other than media type of the external body if it is anything other than
plain US-ASCII text, since the external body does not have a plain US-ASCII text, since the external body does not have a
skipping to change at page 46, line 11 skipping to change at page 46, line 11
Note that in the above examples, the default Content- Note that in the above examples, the default Content-
transfer-encoding of "7bit" is assumed for the external transfer-encoding of "7bit" is assumed for the external
postscript data. postscript data.
Like the message/partial type, the message/external-body media Like the message/partial type, the message/external-body media
type is intended to be transparent, that is, to convey the type is intended to be transparent, that is, to convey the
data type in the external body rather than to convey a message data type in the external body rather than to convey a message
with a body of that type. Thus the headers on the outer and with a body of that type. Thus the headers on the outer and
inner parts must be merged using the same rules as for inner parts must be merged using the same rules as for
message/partial. In particular, this means that the Content- message/partial. In particular, this means that the Content-
type header is overridden, but the From and Subject headers type and Subject fields are overridden, but the From field is
are preserved. preserved.
Note that since the external bodies are not transported along Note that since the external bodies are not transported along
with the external body reference, they need not conform to with the external body reference, they need not conform to
transport limitations that apply to the reference itself. In transport limitations that apply to the reference itself. In
particular, Internet mail transports may impose 7-bit and line particular, Internet mail transports may impose 7bit and line
length limits, but these do not automatically apply to binary length limits, but these do not automatically apply to binary
external body references. Thus a Content-Transfer-Encoding is external body references. Thus a Content-Transfer-Encoding is
not generally necessary, though it is permitted. not generally necessary, though it is permitted.
Note that the body of a message of type "message/external- Note that the body of a message of type "message/external-
body" is governed by the basic syntax for an RFC 822 message. body" is governed by the basic syntax for an RFC 822 message.
In particular, anything before the first consecutive pair of In particular, anything before the first consecutive pair of
CRLFs is header information, while anything after it is body CRLFs is header information, while anything after it is body
information, which is ignored for most access-types. information, which is ignored for most access-types.
skipping to change at page 47, line 10 skipping to change at page 47, line 10
In general, the use of "X-" top-level types is strongly In general, the use of "X-" top-level types is strongly
discouraged. Implementors should invent subtypes of the discouraged. Implementors should invent subtypes of the
existing types whenever possible. In many cases, a subtype of existing types whenever possible. In many cases, a subtype of
application will be more appropriate than a new top-level application will be more appropriate than a new top-level
type. type.
9. Summary 9. Summary
The five discrete media types provide provide a standardized The five discrete media types provide provide a standardized
mechanism for tagging messages or body parts as audio, image, mechanism for tagging entities as audio, image, or several
or several other kinds of data. The composite "multipart" and other kinds of data. The composite "multipart" and "message"
"message" media types allow mixing and hierarchical media types allow mixing and hierarchical structuring of
structuring of objects of different types in a single message. entities of different types in a single message. A
A distinguished parameter syntax allows further specification distinguished parameter syntax allows further specification of
of data format details, particularly the specification of data format details, particularly the specification of
alternate character sets. Additional optional header fields alternate character sets. Additional optional header fields
provide mechanisms for certain extensions deemed desirable by provide mechanisms for certain extensions deemed desirable by
many implementors. Finally, a number of useful media types are many implementors. Finally, a number of useful media types are
defined for general use by consenting user agents, notably defined for general use by consenting user agents, notably
message/partial, and message/external-body. message/partial, and message/external-body.
10. Security Considerations 10. Security Considerations
Security issues are discussed in the context of the Security issues are discussed in the context of the
application/postscript type, the message/external-body type, application/postscript type, the message/external-body type,
skipping to change at page 49, line 9 skipping to change at page 49, line 9
17060 Dallas Parkway 17060 Dallas Parkway
Dallas Texas, 75248 Dallas Texas, 75248
Email: greg.vaudreuil@ons.octel.com Email: greg.vaudreuil@ons.octel.com
Phone: +1 214 733 2722 Phone: +1 214 733 2722
Appendix A -- Collected Grammar Appendix A -- Collected Grammar
This appendix contains the complete BNF grammar for all the This appendix contains the complete BNF grammar for all the
syntax specified by this document. syntax specified by this document.
By itself, however, this grammar is incomplete. It refers to By itself, however, this grammar is incomplete. It refers by
several entities that are defined by RFC 822. Rather than name to several syntax rules that are defined by RFC 822.
reproduce those definitions here, and risk unintentional Rather than reproduce those definitions here, and risk
differences between the two, this document simply refers the unintentional differences between the two, this document
reader to RFC 822 for the remaining definitions. Wherever a simply refers the reader to RFC 822 for the remaining
term is undefined, it refers to the RFC 822 definition. definitions. Wherever a term is undefined, it refers to the
RFC 822 definition.
boundary := 0*69<bchars> bcharsnospace boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " " bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." / "+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?" "/" / ":" / "=" / "?"
body-part := <"message" as defined in RFC 822, with all body-part := <"message" as defined in RFC 822, with all
 End of changes. 61 change blocks. 
187 lines changed or deleted 198 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/