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:
Borenstein &
Freed
[Page
34]
--------------------------------------------------------------------------------
RFC
1521
MIME
September 1993
From: Nathaniel Borenstein <[EMAIL PROTECTED]>
To: Ned Freed <[EMAIL PROTECTED]>
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
.... RFC 1341
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
Borenstein &
Freed
[Page
35]
--------------------------------------------------------------------------------
RFC
1521
MIME
September 1993
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.
