MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies
Network Working Group N. Borenstein, Bellcore
Request for Comments: 1341 N. Freed, Innosoft
June 1992
MIME (Multipurpose Internet Mail Extensions):
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies
Status of this Memo
This RFC specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of
the "IAB Official Protocol Standards" for the
standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
RFC 822 defines a message representation protocol which
specifies considerable detail about message headers, but
which leaves the message content, or message body, as flat
ASCII text. This document redefines the format of message
bodies to allow multi-part textual and non-textual message
bodies to be represented and exchanged without loss of
information. This is based on earlier work documented in
RFC 934 and RFC 1049, but extends and revises that work.
Because RFC 822 said so little about message bodies, this
document is largely orthogonal to (rather than a revision
of) RFC 822.
In particular, this document is designed to provide
facilities to include multiple objects in a single message,
to represent body 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
fragments, and generally to facilitate later extensions
defining new types of Internet mail for use by cooperating
mail agents.
This document does NOT extend Internet mail header fields to
permit anything other than US-ASCII text data. It is
recognized that such extensions are necessary, and they are
the subject of a companion document [RFC -1342].
A table of contents appears at the end of this document.
Borenstein & Freed [Page i]
1 Introduction
Since its publication in 1982, RFC 822 [RFC-822] has defined
the standard format of textual mail messages on the
Internet. Its success has been such that the RFC 822 format
has been adopted, wholly or partially, well beyond the
confines of the Internet and the Internet SMTP transport
defined by RFC 821 [RFC-821]. As the format has seen wider
use, a number of limitations have proven increasingly
restrictive for the user community.
RFC 822 was intended to specify a format for text messages.
As such, non-text messages, such as multimedia messages that
might include audio or images, are simply not mentioned.
Even in the case of text, however, RFC 822 is inadequate for
the needs of mail users whose languages require the use of
character sets richer than US ASCII [US-ASCII]. Since RFC 822 does not specify mechanisms for mail containing audio,
video, Asian language text, or even text in most European
languages, additional specifications are needed
One of the notable limitations of RFC 821/822 based mail
systems is the fact that they limit the contents of
electronic mail messages to relatively short lines of
seven-bit ASCII. This forces users to convert any non-
textual data that they may wish to send into seven-bit bytes
representable as printable ASCII characters before invoking
a local mail UA (User Agent, a program with which human
users send and receive mail). Examples of such encodings
currently used in the Internet include pure hexadecimal,
uuencode, the 3-in-4 base 64 scheme specified in RFC 1113,
the Andrew Toolkit Representation [ATK], and many others.
The limitations of RFC 822 mail become even more apparent as
gateways are designed to allow for the exchange of mail
messages between RFC 822 hosts and X.400 hosts. X.400 [X400]
specifies mechanisms for the inclusion of non-textual body
parts within electronic mail messages. The current
standards for the mapping of X.400 messages to RFC 822
messages specify that either X.400 non-textual body parts
should be converted to (not encoded in) an ASCII format, or
that they should be discarded, notifying the RFC 822 user
that discarding has occurred. This is clearly undesirable,
as information that a user may wish to receive is lost.
Even though a user's UA may not have the capability of
dealing with the non-textual body part, the user might have
some mechanism external to the UA that can extract useful
information from the body part. Moreover, it does not allow
for the fact that the message may eventually be gatewayed
back into an X.400 message handling system (i.e., the X.400
message is "tunneled" through Internet mail), where the
non-textual information would definitely become useful
again.
Borenstein & Freed [Page 1]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
This document describes several mechanisms that combine to
solve most of these problems without introducing any serious
incompatibilities with the existing world of RFC 822 mail.
In particular, it describes:
1. A MIME-Version header field, which uses a version number
to declare a message to be conformant with this
specification and allows mail processing agents to
distinguish between such messages and those generated
by older or non-conformant software, which is presumed
to lack such a field.
2. A Content-Type header field, generalized from RFC 1049
[RFC-1049], which can be used to specify the type and
subtype of data in the body of a message and to fully
specify the native representation (encoding) of such
data.
2.a. A "text" Content-Type value, which can be used to
represent textual information in a number of
character sets and formatted text description
languages in a standardized manner.
2.b. A "multipart" Content-Type value, which can be
used to combine several body parts, possibly of
differing types of data, into a single message.
2.c. An "application" Content-Type value, which can be
used to transmit application data or binary data,
and hence, among other uses, to implement an
electronic mail file transfer service.
2.d. A "message" Content-Type value, for encapsulating
a mail message.
2.e An "image" Content-Type value, for transmitting
still image (picture) data.
2.f. An "audio" Content-Type value, for transmitting
audio or voice data.
2.g. A "video" Content-Type value, for transmitting
video or moving image data, possibly with audio as
part of the composite video data format.
3. A Content-Transfer-Encoding header field, which can be
used to specify an auxiliary encoding that was applied
to the data in order to allow it to pass through mail
transport mechanisms which may have data or character
set limitations.
4. Two optional header fields that can be used to further
describe the data in a message body, the Content-ID and
Content-Description header fields.
Borenstein & Freed [Page 2]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
MIME has been carefully designed as an extensible mechanism,
and it is expected that the set of content-type/subtype
pairs and their associated parameters will grow
significantly with time. Several other MIME fields, notably
including character set names, are likely to have new values
defined over time. In order to ensure that the set of such
values is developed in an orderly, well-specified, and
public manner, MIME defines a registration process which
uses the Internet Assigned Numbers Authority (IANA) as a
central registry for such values. Appendix F provides
details about how IANA registration is accomplished.
Finally, to specify and promote interoperability, Appendix A
of this document provides a basic applicability statement
for a subset of the above mechanisms that defines a minimal
level of "conformance" with this document.
HISTORICAL NOTE: Several of the mechanisms described in
this document may seem somewhat strange or even baroque at
first reading. It is important to note that compatibility
with existing standards AND robustness across existing
practice were two of the highest priorities of the working
group that developed this document. In particular,
compatibility was always favored over elegance.
2 Notations, Conventions, and Generic BNF Grammar
This document is being published in two versions, one as
plain ASCII text and one as PostScript. The latter is
recommended, though the textual contents are identical. An
Andrew-format copy of this document is also available from
the first author (Borenstein).
Although the mechanisms specified in this document are all
described in prose, most are also described formally in the
modified BNF notation of RFC 822. Implementors will need to
be familiar with this notation in order to understand this
specification, and are referred to RFC 822 for a complete
explanation of the modified BNF notation.
Some of the modified BNF in this document makes reference to
syntactic entities that are defined in RFC 822 and not in
this document. A complete formal grammar, then, is obtained
by combining the collected grammar appendix of this document
with that of RFC 822.
The term CRLF, in this document, refers to the sequence of
the two ASCII characters CR (13) and LF (10) which, taken
together, in this order, denote a line break in RFC 822
mail.
The term "character set", wherever it is used in this
document, refers to a coded character set, in the sense of
ISO character set standardization work, and must not be
Borenstein & Freed [Page 3]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
misinterpreted as meaning "a set of characters."
The term "message", when not further qualified, means either
the (complete or "top-level") message being transferred on a
network, or a message encapsulated in a body of type
"message".
The term "body part", in this document, means one of the
parts of the body of a multipart entity. A body part has a
header and a body, so it makes sense to speak about the body
of a body part.
The term "entity", in this document, means either a message
or a body part. All kinds of entities share the property
that they have a header and a body.
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 part.
Note : the previous four definitions are clearly circular.
This is unavoidable, since the overal structure of a MIME
message is indeed recursive.
In this document, all numeric and octet values are given in
decimal notation.
It must be noted that Content-Type values, subtypes, and
parameter names as defined in this document are case-
insensitive. However, parameter values are case-sensitive
unless otherwise specified for the specific parameter.
FORMATTING NOTE: This document has been carefully formatted
for ease of reading. The PostScript version of this
document, in particular, places notes like this one, which
may be skipped by the reader, in a smaller, italicized,
font, and indents it as well. In the text version, only the
indentation is preserved, so if you are reading the text
version of this you might consider using the PostScript
version instead. However, all such notes will be indented
and preceded by "NOTE:" or some similar introduction, even
in the text version.
The primary purpose of these non-essential notes is to
convey information about the rationale of this document, or
to place this document in the proper historical or
evolutionary context. Such information may be skipped by
those who are focused entirely on building a compliant
implementation, but may be of use to those who wish to
understand why this document is written as it is.
For ease of recognition, all BNF definitions have been
placed in a fixed-width font in the PostScript version of
this document.
Borenstein & Freed [Page 4]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
3 The MIME-Version Header Field
Since RFC 822 was published in 1982, there has really been
only one format standard for Internet messages, and there
has been little perceived need to declare the format
standard in use. This document is an independent document
that complements RFC 822. Although the extensions in this
document have been defined in such a way as to be compatible
with RFC 822, there are still circumstances in which it
might be desirable for a mail-processing agent to know
whether a message was composed with the new standard in
mind.
Therefore, this document defines a new header field, "MIME-
Version", which is to be used to declare the version of the
Internet message body format standard in use.
Messages composed in accordance with this document MUST
include such a header field, with the following verbatim
text:
MIME-Version: 1.0
The presence of this header field is an assertion that the
message has been composed in compliance with this document.
Since it is possible that a future document might extend the
message format standard again, a formal BNF is given for the
content of the MIME-Version field:
MIME-Version := text
Thus, future format specifiers, which might replace or
extend "1.0", are (minimally) constrained by the definition
of "text", which appears in RFC 822.
Note that the MIME-Version header field is required at the
top level of a message. It is not required for each body
part of a multipart entity. It is required for the embedded
headers of a body of type "message" if and only if the
embedded message is itself claimed to be MIME-compliant.
Borenstein & Freed [Page 5]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
4 The Content-Type Header Field
The purpose of the Content-Type field is to describe the
data contained in the body fully enough that the receiving
user agent can pick an appropriate agent or mechanism to
present the data to the user, or otherwise deal with the
data in an appropriate manner.
HISTORICAL NOTE: The Content-Type header field was first
defined in RFC 1049. RFC 1049 Content-types used a simpler
and less powerful syntax, but one that is largely compatible
with the mechanism given here.
The Content-Type header field is used to specify the nature
of the data in the body of an entity, by giving type and
subtype identifiers, and by providing auxiliary information
that may be required for certain types. After the type and
subtype names, the remainder of the header field is simply a
set of parameters, specified in an attribute/value notation.
The set of meaningful parameters differs for the different
types. The ordering of parameters is not significant.
Among the defined parameters is a "charset" parameter by
which the character set used in the body may be declared.
Comments are allowed in accordance with RFC 822 rules for
structured header fields.
In general, the top-level Content-Type is used to declare
the general type of data, while the subtype specifies a
specific format for that type of data. Thus, a Content-Type
of "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 format "xyz". Such information can be used,
for example, to decide whether or not to show a user the raw
data from an unrecognized subtype -- such an action might be
reasonable for unrecognized subtypes of text, but not for
unrecognized subtypes of image or audio. For this reason,
registered subtypes of audio, image, text, and video, should
not contain embedded information that is really of a
different type. Such compound types should be represented
using the "multipart" or "application" types.
Parameters are modifiers of the content-subtype, and do not
fundamentally affect the requirements of the host system.
Although most parameters make sense only with certain
content-types, others are "global" in the sense that they
might apply to any subtype. For example, the "boundary"
parameter makes sense only for the "multipart" content-type,
but the "charset" parameter might make sense with several
content-types.
An initial set of seven Content-Types is defined by this
document. This set of top-level names is intended to be
substantially complete. It is expected that additions to
the larger set of supported types can generally be
Borenstein & Freed [Page 6]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
accomplished by the creation of new subtypes of these
initial types. In the future, more top-level types may be
defined only by an extension to this standard. If another
primary type is to be used for any reason, it must be given
a name starting with "X-" to indicate its non-standard
status and to avoid a potential conflict with a future
official name.
In the Extended BNF notation of RFC 822, a Content-Type
header field value is defined as follows:
Content-Type := type "/" subtype *[";" parameter]
type := "application" / "audio"
/ "image" / "message"
/ "multipart" / "text"
/ "video" / x-token
x-token :=
subtype := token
parameter := attribute "=" value
attribute := token
value := token / quoted-string
token := 1*
tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in
/ "," / ";" / ":" / "\" / <"> ; quoted-string,
/ "/" / "[" / "]" / "?" / "." ; to use within
/ "=" ; parameter values
Note that the definition of "tspecials" is the same as the
RFC 822 definition of "specials" with the addition of the
three characters "/", "?", and "=".
Note also that a subtype specification is MANDATORY. There
are no default subtypes.
The type, subtype, and parameter names are not case
sensitive. For example, TEXT, Text, and TeXt are all
equivalent. Parameter values are normally case sensitive,
but certain parameters are interpreted to be case-
insensitive, depending on the intended use. (For example,
multipart boundaries are case-sensitive, but the "access-
type" for message/External-body is not case-sensitive.)
Beyond this syntax, the only constraint on the definition of
subtype names is the desire that their uses must not
conflict. That is, it would be undesirable to have two
Borenstein & Freed [Page 7]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
different communities using "Content-Type:
application/foobar" to mean two different things. The
process of defining new content-subtypes, then, is not
intended to be a mechanism for imposing restrictions, but
simply a mechanism for publicizing the usages. There are,
therefore, two acceptable mechanisms for defining new
Content-Type subtypes:
1. Private values (starting with "X-") may be
defined bilaterally between two cooperating
agents without outside registration or
standardization.
2. New standard values must be documented,
registered with, and approved by IANA, as
described in Appendix F. Where intended for
public use, the formats they refer to must
also be defined by a published specification,
and possibly offered for standardization.
The seven standard initial predefined Content-Types are
detailed in the bulk of this document. They are:
text -- textual information. The primary subtype,
"plain", indicates plain (unformatted) text. No
special software is required to get the full
meaning of the text, aside from support for the
indicated character set. Subtypes are to be used
for enriched text in forms where application
software may enhance the appearance of the text,
but such software must not be required in order to
get the general idea of the content. Possible
subtypes thus include any readable word processor
format. A very simple and portable subtype,
richtext, is defined in this document.
multipart -- data consisting of multiple parts of
independent data types. Four initial subtypes
are defined, including the primary "mixed"
subtype, "alternative" for representing the same
data in multiple formats, "parallel" for parts
intended to be viewed simultaneously, and "digest"
for multipart entities in which each part is of
type "message".
message -- an encapsulated message. A body of
Content-Type "message" is itself a fully formatted
RFC 822 conformant message which may contain its
own different Content-Type header field. The
primary subtype is "rfc822". The "partial"
subtype is defined for partial messages, to permit
the fragmented transmission of bodies that are
thought to be too large to be passed through mail
transport facilities. Another subtype,
"External-body", is defined for specifying large
bodies by reference to an external data source.
Borenstein & Freed [Page 8]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
image -- image data. Image requires a display device
(such as a graphical display, a printer, or a FAX
machine) to view the information. Initial
subtypes are defined for two widely-used image
formats, jpeg and gif.
audio -- audio data, with initial subtype "basic".
Audio requires an audio output device (such as a
speaker or a telephone) to "display" the contents.
video -- video data. Video requires the capability to
display moving images, typically including
specialized hardware and software. The initial
subtype is "mpeg".
application -- some other kind of data, typically
either uninterpreted binary data or information to
be processed by a mail-based application. The
primary subtype, "octet-stream", is to be used in
the case of uninterpreted binary data, in which
case the simplest recommended action is to offer
to write the information into a file for the user.
Two additional subtypes, "ODA" and "PostScript",
are defined for transporting ODA and PostScript
documents in bodies. Other expected uses for
"application" include spreadsheets, data for
mail-based scheduling systems, and languages for
"active" (computational) email. (Note that active
email entails several securityconsiderations,
which are discussed later in this memo,
particularly in the context of
application/PostScript.)
Default RFC 822 messages are typed by this protocol as plain
text in the US-ASCII character set, which can be explicitly
specified as "Content-type: text/plain; charset=us-ascii".
If no Content-Type is specified, either by error or by an
older user agent, this default is assumed. In the presence
of a MIME-Version header field, a receiving User Agent can
also assume that plain US-ASCII text was the sender's
intent. In the absence of a MIME-Version specification,
plain US-ASCII text must still be assumed, but the sender's
intent might have been otherwise.
RATIONALE: In the absence of any Content-Type header field
or MIME-Version header field, it is impossible to be certain
that a message is actually text in the US-ASCII character
set, since it might well be a message that, using the
conventions that predate this document, includes text in
another character set or non-textual data in a manner that
cannot be automatically recognized (e.g., a uuencoded
compressed UNIX tar file). Although there is no fully
acceptable alternative to treating such untyped messages as
"text/plain; charset=us-ascii", implementors should remain
aware that if a message lacks both the MIME-Version and the
Content-Type header fields, it may in practice contain
almost anything.
Borenstein & Freed [Page 9]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
It should be noted that the list of Content-Type values
given here may be augmented in time, via the mechanisms
described above, and that the set of subtypes is expected to
grow substantially.
When a mail reader encounters mail with an unknown Content-
type value, it should generally treat it as equivalent to
"application/octet-stream", as described later in this
document.
5 The Content-Transfer-Encoding Header Field
Many Content-Types which could usefully be transported via
email are represented, in their "natural" format, as 8-bit
character or binary data. Such data cannot be transmitted
over some transport protocols. For example, RFC 821
restricts mail messages to 7-bit US-ASCII data with 1000
character lines.
It is necessary, therefore, to define a standard mechanism
for re-encoding such data into a 7-bit short-line format.
This document specifies that such encodings will be
indicated by a new "Content-Transfer-Encoding" header field.
The Content-Transfer-Encoding field is used to indicate the
type of transformation that has been used in order to
represent the body in an acceptable manner for transport.
Unlike Content-Types, a proliferation of Content-Transfer-
Encoding values is undesirable and unnecessary. However,
establishing only a single Content-Transfer-Encoding
mechanism does not seem possible. There is a tradeoff
between the desire for a compact and efficient encoding of
largely-binary data and the desire for a readable encoding
of data that is mostly, but not entirely, 7-bit data. For
this reason, at least two encoding mechanisms are necessary:
a "readable" encoding and a "dense" encoding.
The Content-Transfer-Encoding field is designed to specify
an invertible mapping between the "native" representation of
a type of data and a representation that can be readily
exchanged using 7 bit mail transport protocols, such as
those defined by RFC 821 (SMTP). This field has not been
defined by any previous standard. The field's value is a
single token specifying the type of encoding, as enumerated
below. Formally:
Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
These values are not case sensitive. That is, Base64 and
BASE64 and bAsE64 are all equivalent. An encoding type of
7BIT requires that the body is already in a seven-bit mail-
ready representation. This is the default value -- that is,
Borenstein & Freed [Page 10]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
The values "8bit", "7bit", and "binary" all imply that NO
encoding has been performed. However, they are potentially
useful as indications of the kind of data contained in the
object, and therefore of the kind of encoding that might
need to be performed for transmission in a given transport
system. "7bit" means that the data is all represented as
short lines of US-ASCII data. "8bit" means that the lines
are short, but there may be non-ASCII characters (octets
with the high-order bit set). "Binary" means that not only
may non-ASCII characters be present, but also that the lines
are not necessarily short enough for SMTP transport.
The difference between "8bit" (or any other conceivable
bit-width token) and the "binary" token is that "binary"
does not require adherence to any limits on line length or
to the SMTP CRLF semantics, while the bit-width tokens do
require such adherence. If the body contains data in any
bit-width other than 7-bit, the appropriate bit-width
Content-Transfer-Encoding token must be used (e.g., "8bit"
for unencoded 8 bit wide data). If the body contains binary
data, the "binary" Content-Transfer-Encoding token must be
used.
NOTE: The distinction between the Content-Transfer-Encoding
values of "binary," "8bit," etc. may seem unimportant, in
that all of them really mean "none" -- that is, there has
been no encoding of the data for transport. However, clear
labeling will be of enormous value to gateways between
future mail transport systems with differing capabilities in
transporting data that do not meet the restrictions of RFC 821 transport.
As of the publication of this document, there are no
standardized Internet transports for which it is legitimate
to include unencoded 8-bit or binary data in mail bodies.
Thus there are no circumstances in which the "8bit" or
"binary" Content-Transfer-Encoding is actually legal on the
Internet. However, in the event that 8-bit or binary mail
transport becomes a reality in Internet mail, or when this
document is used in conjunction with any other 8-bit or
binary-capable transport mechanism, 8-bit or binary bodies
should be labeled as such using this mechanism.
NOTE: The five values defined for the Content-Transfer-
Encoding field imply nothing about the Content-Type other
than the algorithm by which it was encoded or the transport
system requirements if unencoded.
Implementors may, if necessary, define new Content-
Transfer-Encoding values, but must use an x-token, which is
a name prefixed by "X-" to indicate its non-standard status,
Borenstein & Freed [Page 11]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
e.g., "Content-Transfer-Encoding: x-my-new-encoding".
However, unlike Content-Types and subtypes, the creation of
new Content-Transfer-Encoding values is explicitly and
strongly discouraged, as it seems likely to hinder
interoperability with little potential benefit. Their use
is allowed only as the result of an agreement between
cooperating user agents.
If a Content-Transfer-Encoding header field appears as part
of a message header, it applies to the entire body of that
message. If a Content-Transfer-Encoding header field
appears as part of a body part's headers, it applies only to
the body of that body part. If an entity is of type
"multipart" or "message", the Content-Transfer-Encoding is
not permitted to have any value other than a bit width
(e.g., "7bit", "8bit", etc.) or "binary".
It should be noted that email is character-oriented, so that
the mechanisms described here are mechanisms for encoding
arbitrary byte streams, not bit streams. If a bit stream is
to be encoded via one of these mechanisms, it must first be
converted to an 8-bit byte stream using the network standard
bit order ("big-endian"), in which the earlier bits in a
stream become the higher-order bits in a byte. A bit stream
not ending at an 8-bit boundary must be padded with zeroes.
This document provides a mechanism for noting the addition
of such padding in the case of the application Content-Type,
which has a "padding" parameter.
The encoding mechanisms defined here explicitly encode all
data in ASCII. Thus, for example, suppose an entity has
header fields such as:
Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64
This should be interpreted to mean that the body is a base64
ASCII encoding of data that was originally in ISO-8859-1,
and will be in that character set again after decoding.
The following sections will define the two standard encoding
mechanisms. The definition of new content-transfer-
encodings is explicitly discouraged and should only occur
when absolutely necessary. All content-transfer-encoding
namespace except that beginning with "X-" is explicitly
reserved to the IANA for future use. Private agreements
about content-transfer-encodings are also explicitly
discouraged.
Certain Content-Transfer-Encoding values may only be used on
certain Content-Types. In particular, it is expressly
forbidden to use any encodings other than "7bit", "8bit", or
"binary" with any Content-Type that recursively includes
other Content-Type fields, notably the "multipart" and
Borenstein & Freed [Page 12]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
"message" Content-Types. All encodings that are desired for
bodies of type multipart or message must be done at the
innermost level, by encoding the actual body that needs to
be encoded.
NOTE ON ENCODING RESTRICTIONS: Though the prohibition
against using content-transfer-encodings on data of type
multipart or message may seem overly restrictive, it is
necessary to prevent nested encodings, in which data are
passed through an encoding algorithm multiple times, and
must be decoded multiple times in order to be properly
viewed. Nested encodings add considerable complexity to
user agents: aside from the obvious efficiency problems
with such multiple encodings, they can obscure the basic
structure of a message. In particular, they can imply that
several decoding operations are necessary simply to find out
what types of objects a message contains. Banning nested
encodings may complicate the job of certain mail gateways,
but this seems less of a problem than the effect of nested
encodings on user agents.
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
TRANSFER-ENCODING: It may seem that the Content-Transfer-
Encoding could be inferred from the characteristics of the
Content-Type that is to be encoded, or, at the very least,
that certain Content-Transfer-Encodings could be mandated
for use with specific Content-Types. There are several
reasons why this is not the case. First, given the varying
types of transports used for mail, some encodings may be
appropriate for some Content-Type/transport combinations and
not for others. (For example, in an 8-bit transport, no
encoding would be required for text in certain character
sets, while such encodings are clearly required for 7-bit
SMTP.) Second, certain Content-Types may require different
types of transfer encoding under different circumstances.
For example, many PostScript bodies might consist entirely
of short lines of 7-bit data and hence require little or no
encoding. Other PostScript bodies (especially those using
Level 2 PostScript's binary encoding mechanism) may only be
reasonably represented using a binary transport encoding.
Finally, since Content-Type is intended to be an open-ended
specification mechanism, strict specification of an
association between Content-Types and encodings effectively
couples the specification of an application protocol with a
specific lower-level transport. This is not desirable since
the developers of a Content-Type should not have to be aware
of all the transports in use and what their limitations are.
NOTE ON TRANSLATING ENCODINGS: The quoted-printable and
base64 encodings are designed so that conversion between
them is possible. The only issue that arises in such a
conversion is the handling of line breaks. When converting
from quoted-printable to base64 a line break must be
converted into a CRLF sequence. Similarly, a CRLF sequence
Borenstein & Freed [Page 13]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
in base64 data should be converted to a quoted-printable
line break, but ONLY when converting text data.
NOTE ON CANONICAL ENCODING MODEL: There was some
confusion, in earlier drafts of this memo, regarding the
model for when email data was to be converted to canonical
form and encoded, and in particular how this process would
affect the treatment of CRLFs, given that the representation
of newlines varies greatly from system to system. For this
reason, a canonical model for encoding is presented as
Appendix H.
5.1 Quoted-Printable Content-Transfer-Encoding
The Quoted-Printable encoding is intended to represent data
that largely consists of octets that correspond to printable
characters in the ASCII character set. It encodes the data
in such a way that the resulting octets are unlikely to be
modified by mail transport. If the data being encoded are
mostly ASCII text, the encoded form of the data remains
largely recognizable by humans. A body which is entirely
ASCII may also be encoded in Quoted-Printable to ensure the
integrity of the data should the message pass through a
character-translating, and/or line-wrapping gateway.
In this encoding, octets are to be represented as determined
by the following rules:
Rule #1: (General 8-bit representation) Any octet,
except those indicating a line break according to the
newline convention of the canonical form of the data
being encoded, may be represented by an "=" followed by
a two digit hexadecimal representation of the octet's
value. The digits of the hexadecimal alphabet, for this
purpose, are "0123456789ABCDEF". Uppercase letters must
be
used when sending hexadecimal data, though a robust
implementation may choose to recognize lowercase
letters on receipt. Thus, for example, the value 12
(ASCII form feed) can be represented by "=0C", and the
value 61 (ASCII EQUAL SIGN) can be represented by
"=3D". Except when the following rules allow an
alternative encoding, this rule is mandatory.
Rule #2: (Literal representation) Octets with decimal
values of 33 through 60 inclusive, and 62 through 126,
inclusive, MAY be represented as the ASCII characters
which correspond to those octets (EXCLAMATION POINT
through LESS THAN, and GREATER THAN through TILDE,
respectively).
Rule #3: (White Space): Octets with values of 9 and 32
MAY be represented as ASCII TAB (HT) and SPACE
characters, respectively, but MUST NOT be so
Borenstein & Freed [Page 14]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
represented at the end of an encoded line. Any TAB (HT)
or SPACE characters on an encoded line MUST thus be
followed on that line by a printable character. In
particular, an "=" at the end of an encoded line,
indicating a soft line break (see rule #5) may follow
one or more TAB (HT) or SPACE characters. It follows
that an octet with value 9 or 32 appearing at the end
of an encoded line must be represented according to
Rule #1. This rule is necessary because some MTAs
(Message Transport Agents, programs which transport
messages from one user to another, or perform a part of
such transfers) are known to pad lines of text with
SPACEs, and others are known to remove "white space"
characters from the end of a line. Therefore, when
decoding a Quoted-Printable body, any trailing white
space on a line must be deleted, as it will necessarily
have been added by intermediate transport agents.
Rule #4 (Line Breaks): A line break in a text body
part, independent of what its representation is
following the canonical representation of the data
being encoded, must be represented by a (RFC 822) line
break, which is a CRLF sequence, in the Quoted-
Printable encoding. If isolated CRs and LFs, or LF CR
and CR LF sequences are allowed to appear in binary
data according to the canonical form, they must be
represented using the "=0D", "=0A", "=0A=0D" and
"=0D=0A" notations respectively.
Note that many implementation may elect to encode the
local representation of various content types directly.
In particular, this may apply to plain text material on
systems that use newline conventions other than CRLF
delimiters. Such an implementation is permissible, but
the generation of line breaks must be generalized to
account for the case where alternate representations of
newline sequences are used.
Rule #5 (Soft Line Breaks): The Quoted-Printable
encoding REQUIRES that encoded lines be no more than 76
characters long. If longer lines are to be encoded with
the Quoted-Printable encoding, 'soft' line breaks must
be used. An equal sign as the last character on a
encoded line indicates such a non-significant ('soft')
line break in the encoded text. Thus if the "raw" form
of the line is a single unencoded line that says:
Now's the time for all folk to come to the aid of
their country.
This can be represented, in the Quoted-Printable
encoding, as
Borenstein & Freed [Page 15]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Now's the time =
for all folk to come=
to the aid of their country.
This provides a mechanism with which long lines are
encoded in such a way as to be restored by the user
agent. The 76 character limit does not count the
trailing CRLF, but counts all other characters,
including any equal signs.
Since the hyphen character ("-") is represented as itself in
the Quoted-Printable encoding, care must be taken, when
encapsulating a quoted-printable encoded body in a multipart
entity, to ensure that the encapsulation boundary does not
appear anywhere in the encoded body. (A good strategy is to
choose a boundary that includes a character sequence such as
"=_" which can never appear in a quoted-printable body. See
the definition of multipart messages later in this
document.)
NOTE: The quoted-printable encoding represents something of
a compromise between readability and reliability in
transport. Bodies encoded with the quoted-printable
encoding will work reliably over most mail gateways, but may
not work perfectly over a few gateways, notably those
involving translation into EBCDIC. (In theory, an EBCDIC
gateway could decode a quoted-printable body and re-encode
it using base64, but such gateways do not yet exist.) A
higher level of confidence is offered by the base64
Content-Transfer-Encoding. A way to get reasonably reliable
transport through EBCDIC gateways is to also quote the ASCII
characters
!"#$@[\]^`{|}~
according to rule #1. See Appendix B for more information.
Because quoted-printable data is generally assumed to be
line-oriented, it is to be expected that the breaks between
the lines of quoted printable data may be altered in
transport, in the same manner that plain text mail has
always been altered in Internet mail when passing between
systems with differing newline conventions. If such
alterations are likely to constitute a corruption of the
data, it is probably more sensible to use the base64
encoding rather than the quoted-printable encoding.
Borenstein & Freed [Page 16]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
5.2 Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to
represent arbitrary sequences of octets in a form that is
not humanly readable. The encoding and decoding algorithms
are simple, but the encoded data are consistently only about
33 percent larger than the unencoded data. This encoding is
based on the one used in Privacy Enhanced Mail applications,
as defined in RFC 1113. The base64 encoding is adapted
from RFC 1113, with one change: base64 eliminates the "*"
mechanism for embedded clear text.
A 65-character subset of US-ASCII is used, enabling 6 bits
to be represented per printable character. (The extra 65th
character, "=", is used to signify a special processing
function.)
NOTE: This subset has the important property that it is
represented identically in all versions of ISO 646,
including US ASCII, and all characters in the subset are
also represented identically in all versions of EBCDIC.
Other popular encodings, such as the encoding used by the
UUENCODE utility and the base85 encoding specified as part
of Level 2 PostScript, do not share these properties, and
thus do not fulfill the portability requirements a binary
transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits
as output strings of 4 encoded characters. Proceeding from
left to right, a 24-bit input group is formed by
concatenating 3 8-bit input groups. These 24 bits are then
treated as 4 concatenated 6-bit groups, each of which is
translated into a single digit in the base64 alphabet. When
encoding a bit stream via the base64 encoding, the bit
stream must be presumed to be ordered with the most-
significant-bit first. That is, the first bit in the stream
will be the high-order bit in the first byte, and the eighth
bit will be the low-order bit in the first byte, and so on.
Each 6-bit group is used as an index into an array of 64
printable characters. The character referenced by the index
is placed in the output string. These characters, identified
in Table 1, below, are selected so as to be universally
representable, and the set excludes characters with
particular significance to SMTP (e.g., ".", "CR", "LF") and
to the encapsulation boundaries defined in this document
(e.g., "-").
Borenstein & Freed [Page 17]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value
Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
The output stream (encoded bytes) must be represented in
lines of no more than 76 characters each. All line breaks
or other characters not found in Table 1 must be ignored by
decoding software. In base64 data, characters other than
those in Table 1, line breaks, and other white space
probably indicate a transmission error, about which a
warning message or even a message rejection might be
appropriate under some circumstances.
Special processing is performed if fewer than 24 bits are
available at the end of the data being encoded. A full
encoding quantum is always completed at the end of a body.
When fewer than 24 input bits are available in an input
group, zero bits are added (on the right) to form an
integral number of 6-bit groups. Output character positions
which are not required to represent actual input data are
set to the character "=". Since all base64 input is an
integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an
integral multiple of 24 bits; here, the final unit of
encoded output will be an integral multiple of 4 characters
with no "=" padding, (2) the final quantum of encoding input
is exactly 8 bits; here, the final unit of encoded output
will be two characters followed by two "=" padding
characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will
be three characters followed by one "=" padding character.
Care must be taken to use the proper octets for line breaks
if base64 encoding is applied directly to text material that
has not been converted to canonical form. In particular,
text line breaks should be converted into CRLF sequences
Borenstein & Freed [Page 18]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
prior to base64 encoding. The important thing to note is
that this may be done directly by the encoder rather than in
a prior canonicalization step in some implementations.
NOTE: There is no need to worry about quoting apparent
encapsulation boundaries within base64-encoded parts of
multipart entities because no hyphen characters are used in
the base64 encoding.
6 Additional Optional Content- Header Fields
6.1 Optional Content-ID Header Field
In constructing a high-level user agent, it may be desirable
to allow one body to make reference to another.
Accordingly, bodies may be labeled using the "Content-ID"
header field, which is syntactically identical to the
"Message-ID" header field:
Content-ID := msg-id
Like the Message-ID values, Content-ID values must be
generated to be as unique as possible.
6.2 Optional Content-Description Header Field
The ability to associate some descriptive information with a
given body is often desirable. For example, it may be useful
to mark an "image" body as "a picture of the Space Shuttle
Endeavor." Such text may be placed in the Content-
Description header field.
Content-Description := *text
The description is presumed to be given in the US-ASCII
character set, although the mechanism specified in [RFC-
1342] may be used for non-US-ASCII Content-Description
values.
Borenstein & Freed [Page 19]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7 The Predefined Content-Type Values
This document defines seven initial Content-Type values and
an extension mechanism for private or experimental types.
Further standard types must be defined by new published
specifications. It is expected that most innovation in new
types of mail will take place as subtypes of the seven types
defined here. The most essential characteristics of the
seven content-types are summarized in Appendix G.
7.1 The Text Content-Type
The text Content-Type is intended for sending material which
is principally textual in form. It is the default Content-
Type. A "charset" parameter may be used to indicate the
character set of the body text. The primary subtype of text
is "plain". This indicates plain (unformatted) text. The
default Content-Type for Internet mail is "text/plain;
charset=us-ascii".
Beyond plain text, there are many formats for representing
what might be known as "extended text" -- text with embedded
formatting and presentation information. An interesting
characteristic of many such representations is that they are
to some extent readable even without the software that
interprets them. It is useful, then, to distinguish them,
at the highest level, from such unreadable data as images,
audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, it is
reasonable to show subtypes of text to the user, while it is
not reasonable to do so with most nontextual data.
Such formatted textual data should be represented using
subtypes of text. Plausible subtypes of text are typically
given by the common name of the representation format, e.g.,
"text/richtext".
7.1.1 The charset parameter
A critical parameter that may be specified in the Content-
Type field for text data is the character set. This is
specified with a "charset" parameter, as in:
Content-type: text/plain; charset=us-ascii
Unlike some other parameter values, the values of the
charset parameter are NOT case sensitive. The default
character set, which must be assumed in the absence of a
charset parameter, is US-ASCII.
An initial list of predefined character set names can be
found at the end of this section. Additional character sets
may be registered with IANA as described in Appendix F,
although the standardization of their use requires the usual
Borenstein & Freed [Page 20]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
IAB review and approval. Note that if the specified
character set includes 8-bit data, a Content-Transfer-
Encoding header field and a corresponding encoding on the
data are required in order to transmit the body via some
mail transfer protocols, such as SMTP.
The default character set, US-ASCII, has been the subject of
some confusion and ambiguity in the past. Not only were
there some ambiguities in the definition, there have been
wide variations in practice. In order to eliminate such
ambiguity and variations in the future, it is strongly
recommended that new user agents explicitly specify a
character set via the Content-Type header field. "US-ASCII"
does not indicate an arbitrary seven-bit character code, but
specifies that the body uses character coding that uses the
exact correspondence of codes to characters specified in
ASCII. National use variations of ISO 646 [ISO-646] are NOT
ASCII and their use in Internet mail is explicitly
discouraged. The omission of the ISO 646 character set is
deliberate in this regard. The character set name of "US-
ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
The character set name "ASCII" is reserved and must not be
used for any purpose.
NOTE: RFC 821 explicitly specifies "ASCII", and references
an earlier version of the American Standard. Insofar as one
of the purposes of specifying a Content-Type and character
set is to permit the receiver to unambiguously determine how
the sender intended the coded message to be interpreted,
assuming anything other than "strict ASCII" as the default
would risk unintentional and incompatible changes to the
semantics of messages now being transmitted. This also
implies that messages containing characters coded according
to national variations on ISO 646, or using code-switching
procedures (e.g., those of ISO 2022), as well as 8-bit or
multiple octet character encodings MUST use an appropriate
character set specification to be consistent with this
specification.
The complete US-ASCII character set is listed in [US-ASCII].
Note that the control characters including DEL (0-31, 127)
have no defined meaning apart from the combination CRLF
(ASCII values 13 and 10) indicating a new line. Two of the
characters have de facto meanings in wide use: FF (12) often
means "start subsequent text on the beginning of a new
page"; and TAB or HT (9) often (though not always) means
"move the cursor to the next available column after the
current position where the column number is a multiple of 8
(counting the first column as column 0)." Apart from this,
any use of the control characters or DEL in a body must be
part of a private agreement between the sender and
recipient. Such private agreements are discouraged and
should be replaced by the other capabilities of this
document.
Borenstein & Freed [Page 21]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
NOTE: Beyond US-ASCII, an enormous proliferation of
character 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 would prefer to specify a single character
set that can be used universally for representing all of the
world's languages in electronic mail. Unfortunately,
existing practice in several communities seems to point to
the continued use of multiple character sets in the near
future. For this reason, we define names for a small number
of character sets for which a strong constituent base
exists. It is our hope that ISO 10646 or some other
effort will eventually define a single world character set
which can then be specified for use in Internet mail, but in
the advance of that definition we cannot specify the use of
ISO 10646, Unicode, or any other character set whose
definition is, as of this writing, incomplete.
The defined charset values are:
US-ASCII -- as defined in [US-ASCII].
ISO-8859-X -- where "X" is to be replaced, as
necessary, for the parts of ISO-8859 [ISO-
8859]. Note that the ISO 646 character sets
have deliberately been omitted in favor of
their 8859 replacements, which are the
designated character sets for Internet mail.
As of the publication of this document, the
legitimate values for "X" are the digits 1
through 9.
Note that the character set used, if anything other than
US-ASCII, must always be explicitly specified in the
Content-Type field.
No other character set name may be used in Internet mail
without the publication of a formal specification and its
registration with IANA as described in Appendix F, or by
private agreement, in which case the character set name must
begin with "X-".
Implementors are discouraged from defining new character
sets for mail use unless absolutely necessary.
The "charset" parameter has been defined primarily for the
purpose of textual data, and is described in this section
for that reason. However, it is conceivable that non-
textual data might also wish to specify a charset value for
some purpose, in which case the same syntax and values
should be used.
In general, mail-sending software should always use the
"lowest common denominator" character set possible. For
example, if a body contains only US-ASCII characters, it
Borenstein & Freed [Page 22]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
should be marked as being in the US-ASCII character set, not
ISO-8859-1, which, like all the ISO-8859 family of character
sets, is a superset of US-ASCII. More generally, if a
widely-used character set is a subset of another character
set, and a body contains only characters in the widely-used
subset, it should be labeled as being in that subset. This
will increase the chances that the recipient will be able to
view the mail correctly.
7.1.2 The Text/plain subtype
The primary subtype of text is "plain". This indicates
plain (unformatted) text. The default Content-Type for
Internet mail, "text/plain; charset=us-ascii", describes
existing Internet practice, that is, it is the type of body
defined by RFC 822.
7.1.3 The Text/richtext subtype
In order to promote the wider interoperability of simple
formatted text, this document defines an extremely simple
subtype of "text", the "richtext" subtype. This subtype was
designed to meet the following criteria:
1. The syntax must be extremely simple to parse,
so that even teletype-oriented mail systems can
easily strip away the formatting information and
leave only the readable text.
2. The syntax must be extensible to allow for new
formatting commands that are deemed essential.
3. The capabilities must be extremely limited, to
ensure that it can represent no more than is
likely to be representable by the user's primary
word processor. While this limits what can be
sent, it increases the likelihood that what is
sent can be properly displayed.
4. The syntax must be compatible with SGML, so
that, with an appropriate DTD (Document Type
Definition, the standard mechanism for defining a
document type using SGML), a general SGML parser
could be made to parse richtext. However, despite
this compatibility, the syntax should be far
simpler than full SGML, so that no SGML knowledge
is required in order to implement it.
The syntax of "richtext" is very simple. It is assumed, at
the top-level, to be in the US-ASCII character set, unless
of course a different charset parameter was specified in the
Content-type field. All characters represent themselves,
with the exception of the "<" character (ASCII 60), which is
used to mark the beginning of a formatting command.
Borenstein & Freed [Page 23]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Formatting instructions consist of formatting commands
surrounded by angle brackets ("<>", ASCII 60 and 62). Each
formatting command may be no more than 40 characters in
length, all in US-ASCII, restricted to the alphanumeric and
hyphen ("-") characters. Formatting commands may be preceded
by a forward slash or solidus ("/", ASCII 47), making them
negations, and such negations must always exist to balance
the initial opening commands, except as noted below. Thus,
if the formatting command "" appears at some point,
there must later be a "" to balance it. There are
only three exceptions to this "balancing" rule: First, the
command "" is used to represent a literal "<" character.
Second, the command "" is used to represent a required
line break. (Otherwise, CRLFs in the data are treated as
equivalent to a single SPACE character.) Finally, the
command "" is used to represent a page break. (NOTE:
The 40 character limit on formatting commands does not
include the "<", ">", or "/" characters that might be
attached to such commands.)
Initially defined formatting commands, not all of which will
be implemented by all richtext implementations, include:
Bold -- causes the subsequent text to be in a bold
font.
Italic -- causes the subsequent text to be in an italic
font.
Fixed -- causes the subsequent text to be in a fixed
width font.
Smaller -- causes the subsequent text to be in a
smaller font.
Bigger -- causes the subsequent text to be in a bigger
font.
Underline -- causes the subsequent text to be
underlined.
Center -- causes the subsequent text to be centered.
FlushLeft -- causes the subsequent text to be left
justified.
FlushRight -- causes the subsequent text to be right
justified.
Indent -- causes the subsequent text to be indented at
the left margin.
IndentRight -- causes the subsequent text to be
indented at the right margin.
Outdent -- causes the subsequent text to be outdented
at the left margin.
OutdentRight -- causes the subsequent text to be
outdented at the right margin.
SamePage -- causes the subsequent text to be grouped,
if possible, on one page.
Subscript -- causes the subsequent text to be
interpreted as a subscript.
Borenstein & Freed [Page 24]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
Superscript -- causes the subsequent text to be
interpreted as a superscript.
Heading -- causes the subsequent text to be interpreted
as a page heading.
Footing -- causes the subsequent text to be interpreted
as a page footing.
ISO-8859-X (for any value of X that is legal as a
"charset" parameter) -- causes the subsequent text
to be interpreted as text in the appropriate
character set.
US-ASCII -- causes the subsequent text to be
interpreted as text in the US-ASCII character set.
Excerpt -- causes the subsequent text to be interpreted
as a textual excerpt from another source.
Typically this will be displayed using indentation
and an alternate font, but such decisions are up
to the viewer.
Paragraph -- causes the subsequent text to be
interpreted as a single paragraph, with
appropriate paragraph breaks (typically blank
space) before and after.
Signature -- causes the subsequent text to be
interpreted as a "signature". Some systems may
wish to display signatures in a smaller font or
otherwise set them apart from the main text of the
message.
Comment -- causes the subsequent text to be interpreted
as a comment, and hence not shown to the reader.
No-op -- has no effect on the subsequent text.
lt -- is replaced by a literal "<" character. No
balancing is allowed.
nl -- causes a line break. No balancing is
allowed.
np -- causes a page break. No balancing is
allowed.
Each positive formatting command affects all subsequent text
until the matching negative formatting command. Such pairs
of formatting commands must be properly balanced and nested.
Thus, a proper way to describe text in bold italics is:
the-text
or, alternately,
the-text
but, in particular, the following is illegal
richtext:
the-text
NOTE: The nesting requirement for formatting commands
imposes a slightly higher burden upon the composers of
Borenstein & Freed [Page 25]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
richtext bodies, but potentially simplifies richtext
displayers by allowing them to be stack-based. The main
goal of richtext is to be simple enough to make multifont,
formatted email widely readable, so that those with the
capability of sending it will be able to do so with
confidence. Thus slightly increased complexity in the
composing software was deemed a reasonable tradeoff for
simplified reading software. Nonetheless, implementors of
richtext readers are encouraged to follow the general
Internet guidelines of being conservative in what you send
and liberal in what you accept. Those implementations that
can do so are encouraged to deal reasonably with improperly
nested richtext.
Implementations must regard any unrecognized formatting
command as equivalent to "No-op", thus facilitating future
extensions to "richtext". Private extensions may be defined
using formatting commands that begin with "X-", by analogy
to Internet mail header field names.
It is worth noting that no special behavior is required for
the TAB (HT) character. It is recommended, however, that, at
least when fixed-width fonts are in use, the common
semantics of the TAB (HT) character should be observed,
namely that it moves to the next column position that is a
multiple of 8. (In other words, if a TAB (HT) occurs in
column n, where the leftmost column is column 0, then that
TAB (HT) should be replaced by 8-(n mod 8) SPACE
characters.)
Richtext also differentiates between "hard" and "soft" line
breaks. A line break (CRLF) in the richtext data stream is
interpreted as a "soft" line break, one that is included
only for purposes of mail transport, and is to be treated as
white space by richtext interpreters. To include a "hard"
line break (one that must be displayed as such), the ""
or " formatting constructs should be used. In
general, a soft line break should be treated as white space,
but when soft line breaks immediately follow a or a
tag they should be ignored rather than treated
as white space.
Putting all this together, the following "text/richtext"
body fragment:
Now is the time for
all good men
(and women>) to
come
to the aid of their
Borenstein & Freed [Page 26]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
beloved country. Stupid
quote! -- the end
represents the following formatted text (which will, no
doubt, look cryptic in the text-only version of this
document):
Now is the time for all good men (and ) to
come to the aid of their
beloved
country. -- the end
Richtext conformance: A minimal richtext implementation is
one that simply converts "" to "<", converts CRLFs to
SPACE, converts to a newline according to local newline
convention, removes everything between a command
and the next balancing command, and removes all
other formatting commands (all text enclosed in angle
brackets).
NOTE ON THE RELATIONSHIP OF RICHTEXT TO SGML: Richtext is
decidedly not SGML, and must not be used to transport
arbitrary SGML documents. Those who wish to use SGML
document types as a mail transport format must define a new
text or application subtype, e.g., "text/sgml-dtd-whatever"
or "application/sgml-dtd-whatever", depending on the
perceived readability of the DTD in use. Richtext is
designed to be compatible with SGML, and specifically so
that it will be possible to define a richtext DTD if one is
needed. However, this does not imply that arbitrary SGML
can be called richtext, nor that richtext implementors have
any need to understand SGML; the description in this
document is a complete definition of richtext, which is far
simpler than complete SGML.
NOTE ON THE INTENDED USE OF RICHTEXT: It is recognized that
implementors of future mail systems will want rich text
functionality far beyond that currently defined for
richtext. The intent of richtext is to provide a common
format for expressing that functionality in a form in which
much of it, at least, will be understood by interoperating
software. Thus, in particular, software with a richer
notion of formatted text than richtext can still use
richtext as its basic representation, but can extend it with
new formatting commands and by hiding information specific
to that software system in richtext comments. As such
systems evolve, it is expected that the definition of
richtext will be further refined by future published
specifications, but richtext as defined here provides a
platform on which evolutionary refinements can be based.
IMPLEMENTATION NOTE: In some environments, it might be
impossible to combine certain richtext formatting commands,
Borenstein & Freed [Page 27]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
whereas in others they might be combined easily. For
example, the combination of and might
produce bold italics on systems that support such fonts, but
there exist systems that can make text bold or italicized,
but not both. In such cases, the most recently issued
recognized formatting command should be preferred.
One of the major goals in the design of richtext was to make
it so simple that even text-only mailers will implement
richtext-to-plain-text translators, thus increasing the
likelihood that multifont text will become "safe" to use
very widely. To demonstrate this simplicity, an extremely
simple 35-line C program that converts richtext input into
plain text output is included in Appendix D.
Borenstein & Freed [Page 28]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.2 The Multipart Content-Type
In the case of multiple part messages, in which one or more
different sets of data are combined in a single body, a
"multipart" Content-Type field must appear in the entity's
header. The body must then contain one or more "body parts,"
each preceded by an encapsulation boundary, and the last one
followed by a closing boundary. Each part starts with an
encapsulation boundary, and then contains a body part
consisting of 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 meaning.
A body part is NOT to be interpreted as actually being an
RFC 822 message. To begin with, NO header fields are
actually required in body parts. A body part that starts
with a blank line, therefore, is allowed and is a body part
for which all default values are to be assumed. In such a
case, the absence of a Content-Type header field implies
that the encapsulation is plain US-ASCII text. The only
header fields that have defined meaning for body parts are
those the names of which begin with "Content-". All other
header fields are generally to be ignored in body parts.
Although they should generally be retained in mail
processing, they may be discarded by gateways if necessary.
Such other fields are permitted to appear in body parts but
should not be depended on. "X-" fields may be created for
experimental or private purposes, with the recognition that
the information they contain may be lost at some gateways.
The distinction between an RFC 822 message and a body part
is subtle, but important. A gateway between Internet and
X.400 mail, for example, must be able to tell the difference
between a body part that contains an image and a body part
that contains an encapsulated message, the body of which is
an image. In order to represent the latter, the body part
must have "Content-Type: message", and its body (after the
blank line) must be the encapsulated message, with its own
"Content-Type: image" header field. The use of similar
syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which
all parts actually are messages, a "digest" subtype is also
defined.)
As stated previously, each body part is preceded by an
encapsulation boundary. The encapsulation boundary MUST NOT
appear inside any of the encapsulated parts. Thus, it is
crucial that the composing agent be able to choose and
specify the unique boundary that will separate the parts.
All present and future subtypes of the "multipart" type must
use an identical syntax. Subtypes may differ in their
semantics, and may impose additional restrictions on syntax,
Borenstein & Freed [Page 29]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
but must conform to the required syntax for the multipart
type. This requirement ensures that all conformant user
agents will at least be able to recognize and separate the
parts of any multipart entity, even of an unrecognized
subtype.
As stated in the definition of the Content-Transfer-Encoding
field, no encoding other than "7bit", "8bit", or "binary" is
permitted for entities of type "multipart". The multipart
delimiters and header fields are always 7-bit ASCII in any
case, and data within the body parts can be encoded on a
part-by-part basis, with Content-Transfer-Encoding fields
for each appropriate body part.
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the body part headers embedded in the bodies
of messages of type "multipart."
7.2.1 Multipart: The common syntax
All subtypes of "multipart" share a common syntax, defined
in this section. A simple example of a multipart message
also appears in this section. An example of a more complex
multipart message is given in Appendix C.
The Content-Type field for multipart entities requires one
parameter, "boundary", which is used to specify the
encapsulation boundary. The encapsulation boundary is
defined as a line consisting entirely of two hyphen
characters ("-", decimal code 45) followed by the boundary
parameter value from the Content-Type header field.
NOTE: The hyphens are for rough compatibility with the
earlier RFC 934 method of message encapsulation, and for
ease of searching for the boundaries in some
implementations. However, it should be noted that multipart
messages are NOT completely compatible with RFC 934
encapsulations; in particular, they do not obey RFC 934
quoting conventions for embedded lines that begin with
hyphens. This mechanism was chosen over the RFC 934
mechanism because the latter causes lines to grow with each
level of quoting. The combination of this growth with the
fact that SMTP implementations sometimes wrap long lines
made the RFC 934 mechanism unsuitable for use in the event
that deeply-nested multipart structuring is ever desired.
Thus, a typical multipart Content-Type header field might
look like this:
Content-Type: multipart/mixed;
Borenstein & Freed [Page 30]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
boundary=gc0p4Jq0M2Yt08jU534c0p
This indicates that the entity consists of several parts,
each itself with a structure that is syntactically identical
to an RFC 822 message, except that the header area might be
completely empty, and that the parts are each preceded by
the line
--gc0p4Jq0M2Yt08jU534c0p
Note that the encapsulation boundary must occur at the
beginning of a line, i.e., following a CRLF, and that that
initial CRLF is considered to be part of the encapsulation
boundary rather than part of the preceding part. The
boundary must be followed immediately either by another CRLF
and the header fields for the next part, or by two CRLFs, in
which case there are no header fields for the next part (and
it is therefore assumed to be of Content-Type text/plain).
NOTE: The CRLF preceding the encapsulation line is
considered part of the boundary so that it is possible to
have a part that does not end with a CRLF (line break).
Body parts that must be considered to end with line breaks,
therefore, should have two CRLFs preceding the encapsulation
line, the first of which is part of the preceding body part,
and the second of which is part of the encapsulation
boundary.
The requirement that the encapsulation boundary begins with
a CRLF implies that the body of a multipart entity must
itself begin with a CRLF before the first encapsulation line
-- that is, if the "preamble" area is not used, the entity
headers must be followed by TWO CRLFs. This is indeed how
such entities should be composed. A tolerant mail reading
program, however, may interpret a body of type multipart
that begins with an encapsulation line NOT initiated by a
CRLF as also being an encapsulation boundary, but a
compliant mail sending program must not generate such
entities.
Encapsulation boundaries must not appear within the
encapsulations, and must be no longer than 70 characters,
not counting the two leading hyphens.
The encapsulation boundary following the last body part is a
distinguished delimiter that indicates that no further body
parts will follow. Such a delimiter is identical to the
previous delimiters, with the addition of two more hyphens
at the end of the line:
--gc0p4Jq0M2Yt08jU534c0p--
There appears to be room for additional information prior to
the first encapsulation boundary and following the final
Borenstein & Freed [Page 31]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
boundary. These areas should generally be left blank, and
implementations should ignore anything that appears before
the first boundary or after the last one.
NOTE: These "preamble" and "epilogue" areas are not used
because of the lack of proper typing of these parts and the
lack of clear semantics for handling these areas at
gateways, particularly X.400 gateways.
NOTE: Because encapsulation boundaries must not appear in
the body parts being encapsulated, a user agent must
exercise care to choose a unique boundary. The boundary in
the example above could have been the result of an algorithm
designed to produce boundaries with a very low probability
of already existing in the data to be encapsulated without
having to prescan the data. Alternate algorithms might
result in more 'readable' boundaries for a recipient with an
old user agent, but would require more attention to the
possibility that the boundary might appear in the
encapsulated part. The simplest boundary possible is
something like "---", with a closing boundary of "-----".
As a very simple example, the following multipart message
has two parts, both of them plain text, one of them
explicitly typed and one of them implicitly typed:
From: Nathaniel Borenstein
To: Ned Freed
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple
boundary"
This is the preamble. It is to be ignored, though it
is a handy place for mail composers to include an
explanatory note to non-MIME compliant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.
The use of a Content-Type of multipart in a body part within
another multipart entity is explicitly allowed. In such
cases, for obvious reasons, care must be taken to ensure
that each nested multipart entity must use a different
boundary delimiter. See Appendix C for an example of nested
Borenstein & Freed [Page 32]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
multipart entities.
The use of the multipart Content-Type with only a single
body part may be useful in certain contexts, and is
explicitly permitted.
The only mandatory parameter for the multipart Content-Type
is the boundary parameter, which consists of 1 to 70
characters from a set of characters known to be very robust
through email gateways, and NOT ending with white space.
(If a boundary appears to end with white space, the white
space must be presumed to have been added by a gateway, and
should be deleted.) It is formally specified by the
following BNF:
boundary := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
"_"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
Overall, the body of a multipart entity may be specified as
follows:
multipart-body := preamble 1*encapsulation
close-delimiter epilogue
encapsulation := delimiter CRLF body-part
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There must be no space
; between "--" and boundary.
close-delimiter := delimiter "--" ; Again, no space before
"--"
preamble := *text ; to be ignored upon
receipt.
epilogue := *text ; to be ignored upon
receipt.
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere. Note that the
Borenstein & Freed [Page 33]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
semantics of a part differ from the semantics
of a message, as described in the text.>
NOTE: Conspicuously missing from the multipart type is a
notion of structured, related body parts. In general, it
seems premature to try to standardize interpart structure
yet. It is recommended that those wishing to provide a more
structured or integrated multipart messaging facility should
define a subtype of multipart that is syntactically
identical, but that always expects the inclusion of a
distinguished part that can be used to specify the structure
and integration of the other parts, probably referring to
them by their Content-ID field. If this approach is used,
other implementations will not recognize the new subtype,
but will treat it as the primary subtype (multipart/mixed)
and will thus be able to show the user the parts that are
recognized.
7.2.2 The Multipart/mixed (primary) subtype
The primary subtype for multipart, "mixed", is intended for
use when the body parts are independent and intended to be
displayed serially. Any multipart subtypes that an
implementation does not recognize should be treated as being
of subtype "mixed".
7.2.3 The Multipart/alternative subtype
The multipart/alternative type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, each of the parts is an "alternative" version of
the same information. User agents should recognize that the
content of the various parts are interchangeable. The user
agent should either choose the "best" type based on the
user's environment and preferences, or offer the user the
available alternatives. In general, choosing the best type
means displaying only the LAST part that can be displayed.
This may be used, for example, to send mail in a fancy text
format in such a way that it can easily be displayed
anywhere:
From: Nathaniel Borenstein
To: Ned Freed
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
...plain text version of message goes here....
Borenstein & Freed [Page 34]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
--boundary42
Content-Type: text/richtext
.... richtext version of same message goes here ...
--boundary42
Content-Type: text/x-whatever
.... fanciest formatted version of same message goes here
...
--boundary42--
In this example, users whose mail system understood the
"text/x-whatever" format would see only the fancy version,
while other users would see only the richtext or plain text
version, depending on the capabilities of their system.
In general, user agents that compose multipart/alternative
entities should place the body parts in increasing order of
preference, that is, with the preferred format last. For
fancy text, the sending user agent should put the plainest
format first and the richest format last. Receiving user
agents should pick and display the last format they are
capable of displaying. In the case where one of the
alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to
show that alternative, an earlier alternative, or both.
NOTE: From an implementor's perspective, it might seem more
sensible to reverse this ordering, and have the plainest
alternative last. However, placing the plainest alternative
first is the friendliest possible option when
mutlipart/alternative entities are viewed using a non-MIME-
compliant mail reader. While this approach does impose some
burden on compliant mail readers, interoperability with
older mail readers was deemed to be more important in this
case.
It may be the case that some user agents, if they can
recognize more than one of the formats, will prefer to offer
the user the choice of which format to view. This makes
sense, for example, if mail includes both a nicely-formatted
image version and an easily-edited text version. What is
most critical, however, is that the user not automatically
be shown multiple versions of the same data. Either the
user should be shown the last recognized version or should
explicitly be given the choice.
Borenstein & Freed [Page 35]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.2.4 The Multipart/digest subtype
This document defines a "digest" subtype of the multipart
Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, in a digest, the default Content-Type value for
a body part is changed from "text/plain" to
"message/rfc822". This is done to allow a more readable
digest format that is largely compatible (except for the
quoting convention) with RFC 934.
A digest in this format might, then, look something like
this:
From: Moderator-Address
MIME-Version: 1.0
Subject: Internet Digest, volume 42
Content-Type: multipart/digest;
boundary="---- next message ----"
------ next message ----
From: someone-else
Subject: my opinion
...body goes here ...
------ next message ----
From: someone-else-again
Subject: my different opinion
... another body goes here...
------ next message ------
7.2.5 The Multipart/parallel subtype
This document defines a "parallel" subtype of the multipart
Content-Type. This type is syntactically identical to
multipart/mixed, but the semantics are different. In
particular, in a parallel entity, all of the parts are
intended to be presented in parallel, i.e., simultaneously,
on hardware and software that are capable of doing so.
Composing agents should be aware that many mail readers will
lack this capability and will show the parts serially in any
event.
Borenstein & Freed [Page 36]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
7.3 The Message Content-Type
It is frequently desirable, in sending mail, to encapsulate
another mail message. For this common operation, a special
Content-Type, "message", is defined. The primary subtype,
message/rfc822, has no required parameters in the Content-
Type field. Additional subtypes, "partial" and "External-
body", do have required parameters. These subtypes are
explained below.
NOTE: It has been suggested that subtypes of message might
be defined for forwarded or rejected messages. However,
forwarded and rejected messages can be handled as multipart
messages in which the first part contains any control or
descriptive information, and a second part, of type
message/rfc822, is the forwarded or rejected message.
Composing rejection and forwarding messages in this manner
will preserve the type information on the original message
and allow it to be correctly presented to the recipient, and
hence is strongly encouraged.
As stated in the definition of the Content-Transfer-Encoding
field, no encoding other than "7bit", "8bit", or "binary" is
permitted for messages or parts of type "message". The
message header fields are always US-ASCII in any case, and
data within the body can still be encoded, in which case the
Content-Transfer-Encoding header field in the encapsulated
message will reflect this. Non-ASCII text in the headers of
an encapsulated message can be specified using the
mechanisms described in [RFC-1342].
Mail gateways, relays, and other mail handling agents are
commonly known to alter the top-level header of an RFC 822
message. In particular, they frequently add, remove, or
reorder header fields. Such alterations are explicitly
forbidden for the encapsulated headers embedded in the
bodies of messages of type "message."
7.3.1 The Message/rfc822 (primary) subtype
A Content-Type of "message/rfc822" indicates that the body
contains an encapsulated message, with the syntax of an RFC 822 message.
7.3.2 The Message/Partial subtype
A subtype of message, "partial", is defined in order to
allow large objects to be delivered as several separate
pieces of mail and automatically reassembled by the
receiving user agent. (The concept is similar to IP
fragmentation/reassembly in the basic Internet Protocols.)
This mechanism can be used when intermediate transport
agents limit the size of individual messages that can be
sent. Content-Type "message/partial" thus indicates that
Borenstein & Freed [Page 37]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
the body contains a fragment of a larger message.
Three parameters must be specified in the Content-Type field
of type message/partial: The first, "id", is a unique
identifier, as close to a world-unique identifier as
possible, to be used to match the parts together. (In
general, the identifier is essentially a message-id; if
placed in double quotes, it can be any message-id, in
accordance with the BNF for "parameter" given earlier in
this specification.) The second, "number", an integer, is
the part number, which indicates where this part fits into
the sequence of fragments. The third, "total", another
integer, is the total number of parts. This third subfield
is required on the final part, and is optional on the
earlier parts. Note also that these parameters may be given
in any order.
Thus, part 2 of a 3-part message may have either of the
following header fields:
Content-Type: Message/Partial;
number=2; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
Content-Type: Message/Partial;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2
But part 3 MUST specify the total number of parts:
Content-Type: Message/Partial;
number=3; total=3;
id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
Note that part numbering begins with 1, not 0.
When the parts of a message broken up in this manner are put
together, the result is a complete RFC 822 format message,
which may have its own Content-Type header field, and thus
may contain any other data type.
Message fragmentation and reassembly: The semantics of a
reassembled partial message must be those of the "inner"
message, rather than of a message containing the inner
message. This makes it possible, for example, to send a
large audio message as several partial messages, and still
have it appear to the recipient as a simple audio message
rather than as an encapsulated message containing an audio
message. That is, the encapsulation of the message is
considered to be "transparent".
When generating and reassembling the parts of a
message/partial message, the headers of the encapsulated
message must be merged with the headers of the enclosing
Borenstein & Freed [Page 38]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
entities. In this process the following rules must be
observed:
(1) All of the headers from the initial enclosing
entity (part one), except those that start with
"Content-" and "Message-ID", must be copied, in
order, to the new message.
(2) Only those headers in the enclosed message
which start with "Content-" and "Message-ID" must
be appended, in order, to the headers of the new
message. Any headers in the enclosed message
which do not start with "Content-" (except for
"Message-ID") will be ignored.
(3) All of the headers from the second and any
subsequent messages will be ignored.
For example, if an audio message is broken into two parts,
the first part might look something like this:
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: id1@host.com
MIME-Version: 1.0
Content-type: message/partial;
id="ABC@host.com";
number=1; total=2
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID: anotherid@foo.com
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
and the second half might look something like this:
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
MIME-Version: 1.0
Message-ID: id2@host.com
Content-type: message/partial;
id="ABC@host.com"; number=2; total=2
... second half of encoded audio data goes here...
Then, when the fragmented message is reassembled, the
resulting message to be displayed to the user should look
something like this:
Borenstein & Freed [Page 39]
RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992
X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Subject: Audio mail
Message-ID: anotherid@foo.com
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
... second half of encoded audio data goes here...
It should be noted that, because some message transfer
agents may choose to automatically fragment large messages,
and because such agents may use different fragmentation
thresholds, it is possible that the pieces of a partial
message, upon reassembly, may prove themselves to comprise a
partial message. This is explicitly permitted.
It should also be noted that the inclusion of a "References"
field in the headers of the second and subsequent pieces of
a fragmented message that references the Message-Id on the
previous piece may be of benefit to mail readers that
understand and track references. However, the generation of
such "References" fields is entirely optional.
7.3.3 The Message/External-Body subtype
The external-body subtype indicates that the actual body
data are not included, but merely referenced. In this case,
the parameters describe a mechanism for accessing the
external data.
When a message body or body part is of type
"message/external-body", it consists of a header, two
consecutive CRLFs, and