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
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 representation of 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.
WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-
printable, care must be taken to encode CR and LF characters as "=0D"
and "=0A", respectively. In particular, a CRLF sequence in binary
data should be encoded as "=0D=0A". Otherwise, if CRLF were
represented as a hard line break, it might be incorrectly decoded on
platforms with different line break conventions.
For formalists, the syntax of quoted-printable data is described by
the following grammar:
quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
; Maximum line length of 76 characters excluding CRLF
ptext := octet /<any ASCII character except "=", SPACE, or TAB>
; characters not listed as "mail-safe" in Appendix B
; are also not recommended.
octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; octet must be used for characters > 127, =, SPACE, or TAB,
; and is recommended for any characters not listed in
; Appendix B as "mail-safe".
5.2. Base64 Content-Transfer-Encoding
The Base64 Content-Transfer-Encoding is designed to represent
arbitrary sequences of octets in a form that need not be 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 virtually identical to the one used
in Privacy Enhanced Mail (PEM) applications, as defined in RFC1421.
The base64 encoding is adapted from RFC1421, 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.,
"-").
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. Padding at the end of
the data is performed using 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.
Because it is used only for padding at the end of the data, the
occurrence of any '=' characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets
transmitted was a multiple of three.
Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data. The same applies to any illegal sequence of
characters in the base64 encoding, such as "====="
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 must be
converted into CRLF sequences 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 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:
id := "Content-ID" ":" msg-id
Like the Message-ID values, Content-ID values must be generated to be
world-unique.
The Content-ID value may be used for uniquely identifying MIME
entities in several contexts, particularly for cacheing data
referenced by the message/external-body mechanism. Although the
Content-ID header is generally optional, its use is mandatory in
implementations which generate data of the optional MIME Content-type
"message/external-body". That is, each message/external-body entity
must have a Content-ID field to permit cacheing of such data.
It is also worth noting that the Content-ID value has special
semantics in the case of the multipart/alternative content-type.
This is explained in the section of this document dealing with
multipart/alternative.
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.
description := "Content-Description" ":" *text
The description is presumed to be given in the US-ASCII character
set, although the mechanism specified in [RFC-1522] may be used for
non-US-ASCII Content-Description values.
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
F.
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 for some text subtypes, notably including the primary
subtype, "text/plain", which 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" [RFC-1341].
7.1.1. The charset parameter
A critical parameter that may be specified in the Content-Type field
for text/plain 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.
The specification for any future subtypes of "text" must specify
whether or not they will also utilize a "charset" parameter, and may
possibly restrict its values as well. When used with a particular
body, the semantics of the "charset" parameter should be identical to
those specified here for "text/plain", i.e., the body consists
entirely of characters in the given charset. In particular, definers
of future text subtypes should pay close attention the the
implications of multibyte character sets for their subtype
definitions.
This RFCspecifies the definition of the charset parameter for the
purposes of MIME to be a unique mapping of a byte stream to glyphs, a
mapping which does not require external profiling information.
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, although the standardization of their use requires the
usual IESG [RFC-1340] 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: RFC821 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.
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.
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.
The character sets specified above are the ones that were relatively
uncontroversial during the drafting of MIME. This document does not
endorse the use of any particular character set other than US-ASCII,
and recognizes that the future evolution of world character sets
remains unclear. It is expected that in the future, additional
character sets will be registered for use in MIME.
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,
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 must always use the "lowest common
denominator" character set possible. For example, if a body contains
only US-ASCII characters, it must 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 must 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 RFC822.
No other text subtype is defined by this document.
The formal grammar for the content-type header field for text is as
follows:
text-type := "text" "/" text-subtype [";" "charset" "=" charset]
text-subtype := "plain" / extension-token
charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"
/ "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"
/ "iso-8859-8" / "iso-8859-9" / extension-token
; case insensitive
7.2. The Multipart Content-Type
In the case of multiple part entities, 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 RFC822 message in syntax, but different
in meaning.
A body part is NOT to be interpreted as actually being an RFC822
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 corresponding body 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 must 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.
NOTE: The distinction between an RFC822 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, 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 represented as 7-bit ASCII in any case (though the
header fields may encode non-ASCII header text as per [RFC-1522]),
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 RFC822 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
RFC934 encapsulations; in particular, they do not obey RFC934
quoting conventions for embedded lines that begin with hyphens.
This mechanism was chosen over the RFC934 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 RFC934 mechanism unsuitable
for use in the event that deeply-nested multipart structuring is
ever desired.
WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
type field is such that it is often necessary to enclose the
boundaries in quotes on the Content-type line. This is not always
necessary, but never hurts. Implementors should be sure to study the
grammar carefully in order to avoid producing illegal Content-type
fields. Thus, a typical multipart Content-Type header field might
look like this:
Content-Type: multipart/mixed;
boundary=gc0p4Jq0M2Yt08jU534c0p
But the following is illegal:
Content-Type: multipart/mixed;
boundary=gc0p4Jq0M:2Yt08jU534c0p
(because of the colon) and must instead be represented as
Content-Type: multipart/mixed;
boundary="gc0p4Jq0M:2Yt08jU534c0p"
This indicates that the entity consists of several parts, each itself
with a structure that is syntactically identical to an RFC822
message, except that the header area might be completely empty, and
that the parts are each preceded by the line
--gc0p4Jq0M:2Yt08jU534c0p
Note that the encapsulation boundary must occur at the beginning of a
line, i.e., following a CRLF, and that the initial CRLF is considered
to be attached to 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 conceptually
attached to 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, must 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.
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 boundary. These
areas should generally be left blank, and implementations must ignore
anything that appears before the first boundary or after the last
one.
NOTE: These "preamble" and "epilogue" areas are generally 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. However, rather than leaving the
preamble area blank, many MIME implementations have found this to
be a convenient place to insert an explanatory note for recipients
who read the message with pre-MIME software, since such notes will
be ignored by MIME-compliant software.
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 <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
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 conformant 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 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 must be deleted.) It is formally specified by the
following BNF:
boundary := 0*69<bchars> 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 body-part CRLF
delimiter := "--" boundary CRLF ; taken from Content-Type field.
; There must be no space
; between "--" and boundary.
close-delimiter := "--" boundary "--" CRLF ; Again, no space
by "--",
preamble := discard-text ; to be ignored upon receipt.
epilogue := discard-text ; to be ignored upon receipt.
discard-text := *(*text CRLF)
body-part := <"message" as defined in RFC822,
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
semantics of a part differ from the semantics
of a message, as described in the text.>
NOTE: In certain transport enclaves, RFC822 restrictions such as
the one that limits bodies to printable ASCII characters may not
be in force. (That is, the transport domains may resemble
standard Internet mail transport as specified in RFC821 and
assumed by RFC822, but without certain restrictions.) The
relaxation of these restrictions should be construed as locally
extending the definition of bodies, for example to include octets
outside of the ASCII range, as long as these extensions are
supported by the transport and adequately documented in the
Content-Transfer-Encoding header field. However, in no event are
headers (either message headers or body-part headers) allowed to
contain anything other than ASCII characters.
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 need to be bundled in a particular
order. Any multipart subtypes that an implementation does not
recognize must 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.
Systems should recognize that the content of the various parts are
interchangeable. Systems should choose the "best" type based on the
local environment and preferences, in some cases even through user
interaction. As with multipart/mixed, the order of body parts is
significant. In this case, the alternatives appear in an order of
increasing faithfulness to the original content. In general, the best
choice is the LAST part of a type supported by the recipient system's
local environment.
Multipart/alternative 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 <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
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....
--boundary42
Content-Type: text/richtext
.... RFC1341 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
must 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 multipart/alternative
entities are viewed using a non-MIME-conformant mail reader.
While this approach does impose some burden on conformant 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 be
given the choice.
NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each
part of a multipart/alternative entity represents the same data, but
the mappings between the two are not necessarily without information
loss. For example, information is lost when translating ODA to
PostScript or plain text. It is recommended that each part should
have a different Content-ID value in the case where the information
content of the two parts is not identical. However, where the
information content is identical -- for example, where several parts
of type "application/external- body" specify alternate ways to access
the identical data -- the same Content-ID field value should be used,
to optimize any cacheing mechanisms that might be present on the
recipient's end. However, it is recommended that the Content-ID
values used by the parts should not be the same Content-ID value that
describes the multipart/alternative as a whole, if there is any such
Content-ID field. That is, one Content-ID value will refer to the
multipart/alternative entity, while one or more other Content-ID
values will refer to the parts inside it.
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 RFC934.
A digest in this format might, then, look something like this:
From: Moderator-Address
To: Recipient-List
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,
the order of body parts is not significant.
A common presentation of this type is to display all of the parts
simultaneously on hardware and software that are capable of doing so.
However, composing agents should be aware that many mail readers will
lack this capability and will show the parts serially in any event.
7.2.6. Other Multipart subtypes
Other multipart subtypes are expected in the future. MIME
implementations must in general treat unrecognized subtypes of
multipart as being equivalent to "multipart/mixed".
The formal grammar for content-type header fields for multipart data
is given by:
multipart-type := "multipart" "/" multipart-subtype
";" "boundary" "=" boundary
multipart-subtype := "mixed" / "parallel" / "digest"
/ "alternative" / extension-token
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". Even stronger restrictions
apply to the subtypes "message/partial" and "message/external-body",
as specified below. 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-1522].
Mail gateways, relays, and other mail handling agents are commonly
known to alter the top-level header of an RFC822 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 RFC822 message.
However, unlike top-level RFC822 messages, it is not required that
each message/rfc822 body must include a "From", "Subject", and at
least one destination header.
It should be noted that, despite the use of the numbers "822", a
message/rfc822 entity can include enhanced information as defined in
this document. In other words, a message/rfc822 message may be a
MIME 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 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 (though
encouraged) 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 MIME entity, 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 entities. In this process the following
rules must be observed:
(1) All of the header fields from the initial enclosing entity
(part one), except those that start with "Content-" and the
specific header fields "Message-ID", "Encrypted", and "MIME-
Version", must be copied, in order, to the new message.