5.1.4. Субтип Alternative
Тип "multipart/alternative" синтаксически идентичен "multipart/mixed", но имеет иную семантику. В частности, каждая часть тела является альтернативой одной и той же информации.
Системы должны распознавать, что содержимое различных частей взаимозаменяемы. Системы должны выбрать наилучший тип на основе локального окружения и в некоторых случаях с использованием диалога с пользователем. Как и для "multipart/mixed", порядок частей тела является существенным. В этом случае, альтернативы появляются в порядке возрастания правдоподобия оригинальному содержимому. Вообще наилучшим выбором является последняя часть типа, поддерживаемая локальной средой приемной системы..
"Multipart/alternative" может использоваться, например, для посылки сообщения в любом формате таким образом, чтобы его было легко отобразить:
From: Nathaniel Borenstein
To: Ned Freed
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
... здесь следует версия сообщения в виде чистого текста ...
--boundary42
Content-Type: text/enriched
... здесь следует версия сообщения RFC 1896 в виде обогащенного текста (text/enriched) ...
--boundary42
Content-Type: application/x-whatever
... здесь следует наиболее причудливая версия сообщения ...
--boundary42--
В этом примере пользователи, чья почтовая система может работать с форматом "application/x-whatever", увидят только причудливую версию сообщения, в то время как другие пользователи увидят версию с обогащенным или чистым текстом, в зависимости от возможностей их системы.
Вообще, агенты пользователя, которые формируют объекты "multipart/alternative" должны размещать части тела в порядке их предпочтения, то есть, предпочтительный формат следует последним.