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

   .... 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 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.