< draft-ietf-822ext-mime-imt-03.txt   draft-ietf-822ext-mime-imt-04.txt >
Network Working Group Nathaniel Borenstein Network Working Group Nathaniel Borenstein
Internet Draft Ned Freed Internet Draft Ned Freed
<draft-ietf-822ext-mime-imt-03.txt> <draft-ietf-822ext-mime-imt-04.txt>
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
(MIME) Part Two: (MIME) Part Two:
Media Types Media Types
January 1996 March 1996
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 ?
STD 11, RFC 822 defines a message representation protocol STD 11, RFC 822 defines a message representation protocol
specifying considerable detail about US-ASCII message headers, specifying considerable detail about US-ASCII message headers,
but which leaves the message content, or message body, as flat but which leaves the message content, or message body, as flat
US-ASCII text. This set of documents, collectively called the US-ASCII text. This set of documents, collectively called the
Multipurpose Internet Mail Extensions, or MIME, redefines the Multipurpose Internet Mail Extensions, or MIME, redefines the
format of messages to allow for format of messages to allow for
(1) textual message bodies in character sets other than (1) textual message bodies in character sets other than
US-ASCII, US-ASCII,
(2) non-textual message bodies, (2) an extensible set of different formats for non-textual
message bodies,
(3) multi-part message bodies, and (3) multi-part message bodies, and
(4) textual header information in character sets other than (4) textual header information in character sets other than
US-ASCII. US-ASCII.
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
facilities to include multiple parts in a single message, to
represent body and header text in character sets other than
US-ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio clips,
and generally to facilitate later extensions defining new
types of Internet mail for use by cooperating 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 facilities. 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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
6.1 Text Media Type ..................................... 7 6.1 Text Media Type ..................................... 7
6.1.1 Representation of Line Breaks ..................... 8 6.1.1 Representation of Line Breaks ..................... 8
6.1.2 Charset Parameter ................................. 8 6.1.2 Charset Parameter ................................. 8
6.1.3 Plain Subtype ..................................... 12 6.1.3 Plain Subtype ..................................... 12
6.1.4 Unrecognized Subtypes ............................. 12 6.1.4 Unrecognized Subtypes ............................. 12
6.2 Image Media Type .................................... 12 6.2 Image Media Type .................................... 12
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 ................................ 16
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 ................................ 20
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 ........... 28
7.1.3 Mixed Subtype ..................................... 28 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 .................................... 31
7.1.6 Parallel Subtype .................................. 32 7.1.6 Parallel Subtype .................................. 32
7.1.7 Other Multipart Subtypes .......................... 32 7.1.7 Other Multipart Subtypes .......................... 33
7.2 Message Media Type .................................. 32 7.2 Message Media Type .................................. 33
7.2.1 RFC822 Subtype .................................... 33 7.2.1 RFC822 Subtype .................................... 34
7.2.2 Partial Subtype ................................... 33 7.2.2 Partial Subtype ................................... 34
7.2.2.1 Message Fragmentation and Reassembly ............ 35 7.2.2.1 Message Fragmentation and Reassembly ............ 36
7.2.2.2 Fragmentation and Reassembly Example ............ 36 7.2.2.2 Fragmentation and Reassembly Example ............ 37
7.2.3 External-Body Subtype ............................. 38 7.2.3 External-Body Subtype ............................. 39
7.2.4 Other Message Subtypes ............................ 46 7.2.4 Other Message Subtypes ............................ 47
8 Experimental Media Type Values ........................ 46 8 Experimental Media Type Values ........................ 47
9 Summary ............................................... 47 9 Summary ............................................... 48
10 Security Considerations .............................. 47 10 Security Considerations .............................. 48
11 Authors' Addresses ................................... 48 11 Authors' Addresses ................................... 49
A Collected Grammar ..................................... 49 A Collected Grammar ..................................... 50
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
a MIME entity, by giving media type and subtype identifiers, a MIME entity, by giving media type and subtype identifiers,
and by providing auxiliary information that may be required and by providing auxiliary information that may be required
for certain media types. After the type and subtype names, for certain media types. After the type and subtype names,
the remainder of the header field is simply a set of the remainder of the header field is simply a set of
parameters, specified in an attribute/value notation. The parameters, specified in an attribute/value notation. The
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 facilities, most notably the list of the name of MIME facilities, such as transfer encodings and
character sets registered for MIME usage, are likely to have message/external-body access types, are likely to have new
new values defined over time. In order to ensure that the set values defined over time. In order to ensure that the set of
of such values is developed in an orderly, well-specified, and such values is developed in an orderly, well-specified, and
public manner, MIME sets up a registration process which uses public manner, MIME sets up a registration process which uses
the 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 various areas of extensibility. The
is described in a companion document, RFC MIME-REG. registration process for these areas 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:
(1) a name and a description of the type, including (1) a name and a description of the type, including
criteria for whether a particular type would qualify criteria for whether a particular type would qualify
skipping to change at page 5, line 38 skipping to change at page 5, line 39
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
entities 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 text containing no
special software is required to get the full meaning of formatting commands or directives of any sort. Plain
the text, aside from support for the indicated text is intended to be displayed "as-is". No special
character set. Other subtypes are to be used for software is required to get the full meaning of the
enriched text in forms where application software may text, aside from support for the indicated character
enhance the appearance of the text, but such software set. Other subtypes are to be used for enriched text in
must not be required in order to get the general idea forms where application software may enhance the
of the content. Possible subtypes thus include any appearance of the text, but such software must not be
required in order to get the general idea of the
content. Possible subtypes of text thus include any
word processor format that can be read without 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, with a further "richtext", was defined in RFC 1341, with a further
revision in RFC 1563 under the name "enriched". revision in RFC 1563 under the name "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 40 skipping to change at page 7, line 45
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 these types must be 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 text used to indicate the character set of the body text for text
subtypes, notably including the subtype "text/plain", which subtypes, notably including the subtype "text/plain", which
indicates plain (unformatted) text. indicates plain text that doesn't contain any formatting
commands or directives.
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 8, line 31 skipping to change at page 8, line 37
of line break sequences is also forbidden. of line break sequences is also forbidden.
This rule applies regardless of format or character set or This rule applies regardless of format or character set or
sets involved. sets involved.
NOTE: The proper interpretation of line breaks when a body is NOTE: The proper interpretation of line breaks when a body is
displayed depends on the media type. In particular, while it displayed depends on the media type. In particular, while it
is appropriate to treat a line break as a transition to a new is appropriate to treat a line break as a transition to a new
line when displaying a text/plain body, this treatment is line when displaying a text/plain body, this treatment is
actually incorrect for other subtypes of text like actually incorrect for other subtypes of text like
text/enriched [RFC-1563]. text/enriched [RFC-1563]. Similarly, whether or not line
breaks should be added during display operations is also a
function of the media type. It should not be necessary to add
any line breaks to display text/plain correctly, whereas
proper display of text/enriched requires the appropriate
addition of line breaks.
6.1.2. Charset Parameter 6.1.2. Charset Parameter
A critical parameter that may be specified in the Content-Type A critical parameter that may be specified in the Content-Type
field for text/plain data is the character set. This is field for text/plain data is the character set. This is
specified with a "charset" parameter, as in: specified with a "charset" parameter, as in:
Content-type: text/plain; charset=iso-8859-1 Content-type: text/plain; charset=iso-8859-1
Unlike some other parameter values, the values of the charset Unlike some other parameter values, the values of the charset
skipping to change at page 9, line 24 skipping to change at page 9, line 32
This RFC specifies the definition of the charset parameter for This RFC specifies the definition of the charset parameter for
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.
Note that if the specified character set includes 8bit data, a Note that if the specified character set includes 8bit data, 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 [RFC-821]. 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
skipping to change at page 12, line 11 skipping to change at page 12, line 19
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 entity 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 text that does not contain any formatting
type of "text/plain; charset=us-ascii" for Internet mail commands or directives. Plain text is intended to be displayed
describes existing Internet practice. That is, it is the type "as-is", that is, no formatting operations of any sort other
of body defined by RFC 822. than support for the indicated character set should be
necessary for proper display. The default media type of
"text/plain; charset=us-ascii" for Internet mail describes
existing Internet practice. That is, it is the type of body
defined by RFC 822.
No other text subtype is defined by this document. No other text subtype is defined by this document.
6.1.4. Unrecognized Subtypes 6.1.4. Unrecognized Subtypes
Unrecognized subtypes of text should be treated as subtype Unrecognized subtypes of text should be treated as subtype
"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".
skipping to change at page 14, line 43 skipping to change at page 15, line 12
a remote location and automatically run in the recipient's a remote location and automatically run in the recipient's
environment. environment.
Such applications may be defined as subtypes of the Such applications may be defined as subtypes of the
"application" media type. This document defines two subtypes: "application" media type. This document defines two subtypes:
octet-stream, and PostScript. octet-stream, and PostScript.
The subtype of application will often be the name of the The subtype of application will often be the name of the
application for which the data are intended. This does not application for which the data are intended. This does not
mean, however, that any application program name may be used mean, however, that any application program name may be used
freely as a subtype of application. Usage of any subtype freely as a subtype of application.
(other than subtypes beginning with "x-") must be registered
with IANA, as described in RFC MIME-REG.
6.5.1. Octet-Stream Subtype 6.5.1. Octet-Stream Subtype
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.
skipping to change at page 48, line 35 skipping to change at page 49, line 35
Email: ned@innosoft.com Email: ned@innosoft.com
Phone: +1 818 919 3600 Phone: +1 818 919 3600
Fax: +1 818 919 3614 Fax: +1 818 919 3614
MIME is a result of the work of the Internet Engineering Task MIME is a result of the work of the Internet Engineering Task
Force Working Group on Email Extensions. The chairman of that Force Working Group on Email Extensions. The chairman of that
group, Greg Vaudreuil, may be reached at: group, Greg Vaudreuil, may be reached at:
Gregory M. Vaudreuil Gregory M. Vaudreuil
Tigon Corporation Octel Network Services
17060 Dallas Parkway 17080 Dallas Parkway
Dallas Texas, 75248 Dallas, TX 75248-1905
USA
Email: greg.vaudreuil@ons.octel.com Email: Greg.Vaudreuil@Octel.Com
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 by By itself, however, this grammar is incomplete. It refers by
name to several syntax rules that are defined by RFC 822. name to several syntax rules that are defined by RFC 822.
Rather than reproduce those definitions here, and risk Rather than reproduce those definitions here, and risk
unintentional differences between the two, this document unintentional differences between the two, this document
simply refers the reader to RFC 822 for the remaining simply refers the reader to RFC 822 for the remaining
 End of changes. 20 change blocks. 
58 lines changed or deleted 62 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/