RFC: 1521
Оригинал: MIME - Multipurpose Internet Mail Extensions
Другие версии: RFC 1341, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049
Категория: Проект стандарта
Дата публикации:
Авторы: ,
Перевод: Антон Воронин

7.2.2. Основной подтип "multipart/mixed"

Это основной подтип для типа 'multipart', он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу 'mixed'.

7.2.3. Подтип "multipart/alternative"

Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику.

Почтовые системы должны распознавать, что данные из разных частей взаимозаменяемы. Системы должны выбрать наиболее подходящий вариант для локальной платформы и других условий, в некоторых случаях, с согласия пользователя. Как и в предыдущем случае, порядок частей в письме существенен. В этом случае альтернативы располагаются в порядке уменьшения отличия от оригинала. Обычно, выбирается последняя часть (альтернатива) из тех, которые имеют тип, поддерживаемый локальной системой получателя.

Multipart/alternative может быть использована, к примеру, для пересылки текста в некотором гипотетическом формате:

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

   ... Здесь содержится версия простым текстом ....
--boundary42
Content-Type: text/richtext

   .... Здесь содержится версия с разметкой RFC 1341 ...
--boundary42
Content-Type: text/x-whatever

   .... Здесь содержится версия в гипотетическом формате ...
--boundary42--

В этом примере пользователь, чья система понимает этот гипотетический формат, увидят именно эту версию, в то время как остальные будут видеть размеченный либо простой текст в зависимости от возможностей их системы.

Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных (иначе зачем было бы его изобретать?), пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив. В случае, если одна из альтернатив сама имеет тип 'multipart' и содержит подчасти неизвестных типов, пользовательский агент может выбрать, показывать ли эту альтернативу, предыдущую или обе.

Замечание: С точки зрения программиста, может показаться более удобным располагать альтернативы в обратном порядке, но данный порядок позволяет устаревшим не-MIME'овским почтовым программам отобразить в первую очередь наиболее понятный вариант.

Замечание по семантике поля 'content-id' в письме multipart/alternative: Рекомендуется, чтобы каждая часть имела уникальное значение поля Content-ID в случае, если содержимое этих частей не является идентичным. Однако, там, где содержащаяся информация идентична (например, если несколько частей типа "application/external- body" определяют альтернативные пути доступа к одним и тем же внешним по отношению к письму данным), должно использоваться одно и то же значение Content-ID, чтобы оптимизировать работу кэширующего механизма на системе получателя. Однако, не рекомендуется, чтобы значения Content-ID, использующиеся для частей, отличались от значения Content-ID, использующегося в заголовке верхнего уровня, если такое поле в нем присутствует.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.