< draft-ietf-822ext-mime-imb-02.txt   draft-ietf-822ext-mime-imb-03.txt >
Network Working Group Nathaniel Borenstein Network Working Group Nathaniel Borenstein
Internet Draft Ned Freed Internet Draft Ned Freed
<draft-ietf-822ext-mime-imb-02.txt> <draft-ietf-822ext-mime-imb-03.txt>
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
(MIME) Part One: (MIME) Part One:
Format of Internet Message Bodies Format of Internet Message Bodies
April 11, 1995 May 5, 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 3, line 10 skipping to change at page 3, line 10
These documents are revisions of RFCs 1521, 1522, and 1590, These documents are revisions of RFCs 1521, 1522, and 1590,
which themselves were revisions of RFCs 1341 and 1342. An which themselves were revisions of RFCs 1341 and 1342. An
appendix in RFC MIME-CONF describes differences and changes appendix in RFC MIME-CONF describes differences and changes
from previous versions. from previous versions.
2. Table of Contents 2. Table of Contents
1 Abstract .............................................. 1 1 Abstract .............................................. 1
2 Table of Contents ..................................... 3 2 Table of Contents ..................................... 3
3 Introduction .......................................... 4 3 Introduction .......................................... 4
4 Notations, Conventions, and Generic BNF Grammar ....... 6 4 Definitions, Conventions, and Generic BNF Grammar ..... 6
4.1 CRLF ................................................ 7 4.1 CRLF ................................................ 7
4.2 Character Set ....................................... 7 4.2 Character Set ....................................... 7
4.3 Message ............................................. 8 4.3 Message ............................................. 8
4.4 Body Part ........................................... 8 4.4 Body Part ........................................... 8
4.5 Entity .............................................. 8 4.5 Entity .............................................. 8
4.6 Body ................................................ 8 4.6 Body ................................................ 8
4.7 7bit Data ........................................... 8 4.7 7bit Data ........................................... 8
4.8 8bit Data ........................................... 9 4.8 8bit Data ........................................... 9
4.9 Binary Data ......................................... 9 4.9 Binary Data ......................................... 9
4.10 Lines .............................................. 9 4.10 Lines .............................................. 9
skipping to change at page 6, line 24 skipping to change at page 6, line 24
Please refer to the current edition of the "IAB Official Please refer to the current edition of the "IAB Official
Protocol Standards" for the standardization state and status Protocol Standards" for the standardization state and status
of this protocol. RFC 822 and RFC 1123 [RFC-1123] also of this protocol. RFC 822 and RFC 1123 [RFC-1123] also
provide essential background for MIME since no conforming provide essential background for MIME since no conforming
implementation of MIME can violate them. In addition, several implementation of MIME can violate them. In addition, several
other informational RFC documents will be of interest to the other informational RFC documents will be of interest to the
MIME implementor, in particular RFC 1344 [RFC-1344], RFC 1345 MIME implementor, in particular RFC 1344 [RFC-1344], RFC 1345
[RFC-1345], and RFC 1524 [RFC-1524]. [RFC-1345], and RFC 1524 [RFC-1524].
4. Notations, Conventions, and Generic BNF Grammar 4. Definitions, Conventions, and Generic BNF Grammar
Although the mechanisms specified in this document are all Although the mechanisms specified in this document are all
described in prose, most are also described formally in the described in prose, most are also described formally in the
augmented BNF notation of RFC 822. Implementors will need to augmented BNF notation of RFC 822. Implementors will need to
be familiar with this notation in order to understand this be familiar with this notation in order to understand this
specification, and are referred to RFC 822 for a complete specification, and are referred to RFC 822 for a complete
explanation of the augmented BNF notation. explanation of the augmented BNF notation.
Some of the augmented BNF in this document makes reference to Some of the augmented BNF in this document makes reference to
syntactic entities that are defined in RFC 822 and not in this syntactic entities that are defined in RFC 822 and not in this
skipping to change at page 8, line 15 skipping to change at page 8, line 15
4.3. Message 4.3. Message
The term "message", when not further qualified, means either The term "message", when not further qualified, means either
the (complete or "top-level") message being transferred on a the (complete or "top-level") message being transferred on a
network, or a message encapsulated in a body part of type network, or a message encapsulated in a body part of type
"message". "message".
4.4. Body Part 4.4. Body Part
The term "body part", in this document, refers to either a The term "body part", in this document, refers to content
single part message or one of the parts in the body of a headers and contents of either a message or one of the parts
multipart entity. A body part has a header and a body, so it in the body of a multipart entity. A body part has a header
makes sense to speak about the body of a body part. and a body, so it makes sense to speak about the body of a
body part.
4.5. Entity 4.5. Entity
The term "entity", in this document, means either a message or The term "entity", in this document, means either a message or
a body part. All kinds of entities share the property that a body part. All kinds of entities share the property that
they have a header and a body. they have a header and a body.
4.6. Body 4.6. Body
The term "body", when not further qualified, means the body of The term "body", when not further qualified, means the body of
an entity, that is the body of either a message or of a body an entity, that is the body of either a message or of a body
part. part.
NOTE: The previous four definitions are clearly circular. NOTE: The previous four definitions are clearly circular.
This is unavoidable, since the overall structure of a MIME This is unavoidable, since the overall structure of a MIME
message is indeed recursive. message is indeed recursive.
4.7. 7bit Data 4.7. 7bit Data
"7bit data" refers to data that is all represented as "7bit data" refers to data that is all represented as
relatively short lines (e.g. 1000 octets or less between CRLF relatively short lines with 998 octets or less between CRLF
line separation sequences [RFC821]). No octets with decimal line separation sequences [RFC821]. No octets with decimal
values greater than 127 are allowed and neither are NULs values greater than 127 are allowed and neither are NULs
(octets with decimal value 0). CR (decimal value 13) and LF (octets with decimal value 0). CR (decimal value 13) and LF
(decimal value 10) octets only occur as part of CRLF line (decimal value 10) octets only occur as part of CRLF line
separation sequences. separation sequences.
4.8. 8bit Data 4.8. 8bit Data
"8bit data" refers to data that is all represented as "8bit data" refers to data that is all represented as
relatively short lines (e.g. 1000 octets or less between CRLF relatively short lines with 998 octets or less between CRLF
line separation sequences [RFC821]), but characters with line separation sequences [RFC821]), but octets with decimal
decimal values greater than 127 may be used. As with "7bit values greater than 127 may be used. As with "7bit data" CR
data" CR and LF octets only occur as part of CRLF line and LF octets only occur as part of CRLF line separation
separation sequences and no NULs are allowed. sequences and no NULs are allowed.
4.9. Binary Data 4.9. Binary Data
"Binary data" refers to data where any sequence of octets "Binary data" refers to data where any sequence of octets
whatsoever is allowed. whatsoever is allowed.
4.10. Lines 4.10. Lines
"Lines" are defined as sequences of octets separated by a CRLF "Lines" are defined as sequences of octets separated by a CRLF
sequences. This is consistent with both RFC 821 and RFC 822. sequences. This is consistent with both RFC 821 and RFC 822.
"Lines" only refers to a unit of text in a message, which may
or may not correspond to something that is actually displayed
by a user agent.
5. MIME Header Fields 5. MIME Header Fields
MIME defines a number of new RFC 822 header fields that are MIME defines a number of new RFC 822 header fields that are
used to describe the content of messages. These header fields used to describe the content of messages. These header fields
occur in two contexts: occur in two contexts:
(1) As part of a regular RFC 822 message header. (1) As part of a regular RFC 822 message header.
(2) In a MIME body part header within a multipart (2) In a MIME body part header within a multipart
skipping to change at page 14, line 10 skipping to change at page 14, line 10
For example, the "charset" parameter is applicable to any For example, the "charset" parameter is applicable to any
subtype of "text", while the "boundary" parameter is required subtype of "text", while the "boundary" parameter is required
for any subtype of the "multipart" media type. for any subtype of the "multipart" media type.
There are NO globally-meaningful parameters that apply to all There are NO globally-meaningful parameters that apply to all
media types. Truly global mechanisms are best addressed, in media types. Truly global mechanisms are best addressed, in
the MIME model, by the definition of additional Content-* the MIME model, by the definition of additional Content-*
header fields. header fields.
An initial set of seven top-level media types is defined by An initial set of seven top-level media types is defined in
this document. Five of these are discrete types whose content MIME-IMT. Five of these are discrete types whose content is
is essentially opaque as far as MIME processing is concerned. essentially opaque as far as MIME processing is concerned.
The remaining two are composite types whose contents require The remaining two are composite types whose contents require
additional handling by MIME processors. additional handling by MIME processors.
This set of top-level media types is intended to be This set of top-level media types is intended to be
substantially complete. It is expected that additions to the substantially complete. It is expected that additions to the
larger set of supported types can generally be accomplished by larger set of supported types can generally be accomplished by
the creation of new subtypes of these initial types. In the the creation of new subtypes of these initial types. In the
future, more top-level types may be defined only by a future, more top-level types may be defined only by a
standards-track extension to this standard. If another top- standards-track extension to this standard. If another top-
level type is to be used for any reason, it must be given a level type is to be used for any reason, it must be given a
skipping to change at page 17, line 12 skipping to change at page 17, line 12
assumed in the absence of a MIME-Version specification, but assumed in the absence of a MIME-Version specification, but
the sender's intent might have been otherwise. the sender's intent might have been otherwise.
8. Content-Transfer-Encoding Header Field 8. Content-Transfer-Encoding Header Field
Many media types which could be usefully transported via email Many media types which could be usefully transported via email
are represented, in their "natural" format, as 8-bit character are represented, in their "natural" format, as 8-bit character
or binary data. Such data cannot be transmitted over some or binary data. Such data cannot be transmitted over some
transfer protocols. For example, RFC 821 (SMTP) restricts transfer protocols. For example, RFC 821 (SMTP) restricts
mail messages to 7-bit US-ASCII data with lines no longer than mail messages to 7-bit US-ASCII data with lines no longer than
1000 characters. 1000 characters including any trailing CRLF line separator.
It is necessary, therefore, to define a standard mechanism for It is necessary, therefore, to define a standard mechanism for
encoding such data into a 7-bit short line format. Proper encoding such data into a 7-bit short line format. Proper
labelling of unencoded material in less restrictive formats labelling of unencoded material in less restrictive formats
for direct use over less restrictive transports is also for direct use over less restrictive transports is also
desireable. This document specifies that such encodings will desireable. This document specifies that such encodings will
be indicated by a new "Content-Transfer-Encoding" header be indicated by a new "Content-Transfer-Encoding" header
field. This field has not been defined by any previous field. This field has not been defined by any previous
standard. standard.
skipping to change at page 18, line 12 skipping to change at page 18, line 12
transformation the body was subjected to, and it specifies transformation the body was subjected to, and it specifies
what the domain of the result is. what the domain of the result is.
Three transformations are currently defined: identity, the Three transformations are currently defined: identity, the
"quoted-printable" encoding, and the "base64" encoding. The "quoted-printable" encoding, and the "base64" encoding. The
domains are "binary", "8bit" and "7bit". domains are "binary", "8bit" and "7bit".
The Content-Transfer-Encoding values "7bit", "8bit", and The Content-Transfer-Encoding values "7bit", "8bit", and
"binary" all mean that the identity (i.e. NO) encoding "binary" all mean that the identity (i.e. NO) encoding
transformation has been performed. As such, they serve simply transformation has been performed. As such, they serve simply
as indicators of the domain of the body part data, and provide as indicators of the domain of the body data, and provide
useful information about the sort of encoding that might be useful information about the sort of encoding that might be
needed for transmission in a given transport system. The needed for transmission in a given transport system. The
terms "7bit data", "8bit data", and "binary data" are all terms "7bit data", "8bit data", and "binary data" are all
defined in Section 4. defined in Section 4.
The quoted-printable and base64 encodings transform their The quoted-printable and base64 encodings transform their
input from an arbitrary domain into material in the "7bit" input from an arbitrary domain into material in the "7bit"
range, thus making it safe to carry over restricted range, thus making it safe to carry over restricted
transports. The specific definition of the transformations transports. The specific definition of the transformations
are given below. are given below.
skipping to change at page 24, line 43 skipping to change at page 24, line 43
character limit does not count the trailing CRLF, but counts character limit does not count the trailing CRLF, but counts
all other characters, including any equal signs. all other characters, including any equal signs.
Since the hyphen character ("-") is represented as itself in Since the hyphen character ("-") is represented as itself in
the Quoted-Printable encoding, care must be taken, when the Quoted-Printable encoding, care must be taken, when
encapsulating a quoted-printable encoded body inside one or encapsulating a quoted-printable encoded body inside one or
more multipart entities, to ensure that the boundary delimiter more multipart entities, to ensure that the boundary delimiter
does not appear anywhere in the encoded body. (A good does not appear anywhere in the encoded body. (A good
strategy is to choose a boundary that includes a character strategy is to choose a boundary that includes a character
sequence such as "=_" which can never appear in a quoted- sequence such as "=_" which can never appear in a quoted-
printable body. See the definition of multipart messages printable body. See the definition of multipart messages in
later in this document.) MIME-IMT.)
NOTE: The quoted-printable encoding represents something of a NOTE: The quoted-printable encoding represents something of a
compromise between readability and reliability in transport. compromise between readability and reliability in transport.
Bodies encoded with the quoted-printable encoding will work Bodies encoded with the quoted-printable encoding will work
reliably over most mail gateways, but may not work perfectly reliably over most mail gateways, but may not work perfectly
over a few gateways, notably those involving translation into over a few gateways, notably those involving translation into
EBCDIC. A higher level of confidence is offered by the base64 EBCDIC. A higher level of confidence is offered by the base64
Content-Transfer-Encoding. A way to get reasonably reliable Content-Transfer-Encoding. A way to get reasonably reliable
transport through EBCDIC gateways is to also quote the US- transport through EBCDIC gateways is to also quote the US-
ASCII characters ASCII characters
skipping to change at page 27, line 27 skipping to change at page 27, line 27
That is, the first bit in the stream will be the high-order That is, the first bit in the stream will be the high-order
bit in the first 8-bit byte, and the eighth bit will be the bit in the first 8-bit byte, and the eighth bit will be the
low-order bit in the first 8-bit byte, and so on. low-order bit in the first 8-bit byte, and so on.
Each 6-bit group is used as an index into an array of 64 Each 6-bit group is used as an index into an array of 64
printable characters. The character referenced by the index printable characters. The character referenced by the index
is placed in the output string. These characters, identified is placed in the output string. These characters, identified
in Table 1, below, are selected so as to be universally in Table 1, below, are selected so as to be universally
representable, and the set excludes characters with particular representable, and the set excludes characters with particular
significance to SMTP (e.g., ".", CR, LF) and to the multipart significance to SMTP (e.g., ".", CR, LF) and to the multipart
boundary delimiters defined in this document (e.g., "-"). boundary delimiters defined in MIME-IMT (e.g., "-").
Table 1: The Base64 Alphabet Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z 0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0 1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1 2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2 3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3 4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4 5 F 22 W 39 n 56 4
skipping to change at page 29, line 34 skipping to change at page 29, line 34
entities in several contexts, particularly for caching data entities in several contexts, particularly for caching data
referenced by the message/external-body mechanism. Although referenced by the message/external-body mechanism. Although
the Content-ID header is generally optional, its use is the Content-ID header is generally optional, its use is
MANDATORY in implementations which generate data of the MANDATORY in implementations which generate data of the
optional MIME media type "message/external-body". That is, optional MIME media type "message/external-body". That is,
each message/external-body entity must have a Content-ID field each message/external-body entity must have a Content-ID field
to permit caching of such data. to permit caching of such data.
It is also worth noting that the Content-ID value has special It is also worth noting that the Content-ID value has special
semantics in the case of the multipart/alternative media type. semantics in the case of the multipart/alternative media type.
This is explained in the section of this document dealing with This is explained in the section of MIME-IMT dealing with
multipart/alternative. multipart/alternative.
10. Content-Description Header Field 10. Content-Description Header Field
The ability to associate some descriptive information with a The ability to associate some descriptive information with a
given body is often desirable. For example, it may be useful given body is often desirable. For example, it may be useful
to mark an "image" body as "a picture of the Space Shuttle to mark an "image" body as "a picture of the Space Shuttle
Endeavor." Such text may be placed in the Content-Description Endeavor." Such text may be placed in the Content-Description
header field. This header field is always optional. header field. This header field is always optional.
 End of changes. 14 change blocks. 
24 lines changed or deleted 28 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/