Многоцелевое расширение почты Интернет

         

Совместимость с MIME


Механизмы, описанные в данном разделе являются открытыми для дальнейшего расширения. Не предполагается, что все реализации будут поддерживать все существующие типы среды. Для того чтобы обеспечить наибольшую область применимости полезно определить концепцию "MIME-совместимости", которая позволит обмениваться сообщениями, содержащими данные в формате, отличном от US-ASCII.

Почтовый агент пользователя, совместимый с MIME должен:

(1)

Всегда генерировать поле заголовка "MIME-Version: 1.0" в любом формируемом сообщении. (2)Распознавать поле заголовка Content-Transfer-Encoding и декодировать все получаемые данные, кодированные в формате закавыченных последовательностей печатных символов или в base64. Должна идентифицироваться также форма преобразования (7-бит, 8-бит или двоичная).
Любые не 7-битовые данные, посланные без кодирования, должны быть соответствующим образом помечены в поле content-transfer-encoding как 8-битовые или двоичные в зависимости от реального формата. Если транспортная система не поддерживает 8-битовый или двоичный формат (как, например, SMTP [RFC-821]), отправитель должен выполнить кодирование и пометить данные, как закодированные в формате base64 или закавыченных последовательностей печатных символов. (3)Должен обрабатывать любые нераспознанные транспортные кодирования как тип содержимого "application/octet-stream", вне зависимости от того, распознан или нет действительный тип содержимого. (4)Распознавать и интерпретировать поле заголовка Content-Type, и избегать отображения исходных данных со значением поля Content-Type, отличным от text. Реализации должны быть способны посылать, по крайней мере, сообщения text/plain, с символьным набором, специфицированным с помощью параметра charset, если это не US-ASCII. (5) Игнорировать любые параметры типа содержимого с не распознанными именами. (6) Работать с ниже приведенными значениями типов среды.

Текст:

-

Распознавать и отображать "текст" почтового сообщения с символьным набором "US-ASCII." - Распознавать другие символьные наборы, по крайней мере, на таком уровне, чтобы информировать пользователя о том, какой символьный набор использован. -Распознавать символьные наборы "ISO-8859-*" на таком уровне, чтобы быть способным отобразить те символы, которые являются общими для ISO-8859-* и US-ASCII, то есть все символы с кодами в диапазоне 1-127. -Для нераспознанных субтипов в рамках известного символьного набора показать или предложить показать версию исходных данных после преобразования содержимого из канонической формы в локальную. - Обрабатывать материал с неизвестным символьным набором так, как если бы это был "application/octet-stream".
Изображение, аудио и видео:

- На минимальном уровне предоставить возможность обрабатывать любой не узнанный субтип, как если бы он был "application/octet-stream".
Применение:
- Предложить возможность удаления кодирования base64 или закавыченных последовательностей печатных символов, определенных в данном документе, если они были применены, и положить результат в файл пользователя.
Составное сообщение:
-
Распознается составной субтип. Отображает всю информацию на уровне сообщения и на уровне заголовка тела, а затем отображает или предлагает отобразить каждую из составляющих частей индивидуально. - Распознается cубтип "alternative", и исключается отображение лишних частей сообщения multipart/alternative. - Распознается субтип "multipart/digest", используя формат "message/RFC-822" а не "text/plain" в качестве типа среды по умолчанию для частей тела внутри объектов "multipart/digest". - Любые не узнанные субтипы обрабатываются, как если бы они были типа "mixed". Сообщение:
-
Распознаются и отображаются, по крайней мере, инкапсулированные данные сообщения RFC-822 (message/RFC-822) таким образом, чтобы сохранить любую рекурсивную структуру, то есть, отображая или предлагая отобразить инкапсулированные данные с учетом типа среды. - Любые не распознанные субтипы обрабатывается как если бы они имели тип "application/octet-stream".
(7)
При встрече нераспознанного поля Content-Type, программная реализация должна воспринимать ее как если бы она имела тип "application/octet-stream" без каких либо параметров субаргументов. Как обрабатывать эти данные зависит исключительно от конкретной реализации, но желательны опции, предлагающие пользователю после декодирования транспортного формата записать данные в файл или предложить пользователю ввести имя файла, который преобразует содержимое в приемлемый формат. (8)Нужны адаптирующиеся агенты пользователя, если они предоставляют нестандартную поддержку для сообщений, не следующих протоколу MIME, и использующих символьный набор отличный от US-ASCII. Адаптирующиеся агенты пользователя не должны посылать сообщения, которые не следуют протоколу MIME и в то же время содержат текст отличный от US-ASCII.
В частности, использование текста не US-ASCII в почтовом сообщении без поля MIME-Version категорически не рекомендуется, так как это уменьшает коммуникационные возможности. Адаптирующиеся агенты пользователя должны содержать корректные метки MIME при посылке чего-либо отличного от чистого текста с символьным набором US-ASCII.
Кроме того, агенты пользователя, не поддерживающие MIME, должны модифицироваться, если это возможно, чтобы включить соответствующую информацию заголовка MIME в отправляемое сообщение, даже если ничего более из протокола MIME не поддерживается. Эта модификация произведет малое, если вообще какое-либо влияние на получателей, не поддерживающих MIME, но поможет MIME корректно отобразить текст сообщения. (9) Адаптирующиеся агенты пользователя должны гарантировать, что любая строка печатных US-ASCII-символов (без WS) в пределах "*text" или "*ctext", которая начинается с "=?" и завершается "?=", является корректным кодировочным словом. Слово "начинается" здесь означает - в начале поля тела или сразу после LWS, а "завершается" означает - в конце поля-тела или сразу перед LWS. Кроме того любое "слово" в пределах "фразы", которое начинается с "=?" и завершается "?=", должно быть корректным кодировочным словом. (10)Адаптирующиеся агенты пользователя должны быть способны отделит кодировочные слова от "text", "ctext" или "word", в соответствии с правилами секции 4, где бы они не встретились в заголовках сообщения. Они должны поддерживать как "B"- так и "Q"-кодирование для любого поддерживаемого символьного набора. Программа должна быть способна отобразить не кодированный текст, если символьным набором является "US-ASCII". Для символьных наборов ISO-8859-*, программа, читающая почтовые сообщения должна быть способна, по крайней мере, отобразить символы, которые входят также и в набор US-ASCII. Агент пользователя, который отвечает данным условиям, считается адаптированным к MIME.

Есть и другое соображение, почему всегда безопасно посылать данные в формате, согласованным с MIME, ведь такая форма не вступит в конфликт с промежуточными почтовыми серверами, работающими в соответствие со стандартами RFC-821 и RFC-822. Агенты пользователя, которые адаптированы к MIME имеют дополнительную гарантию, что пользователю не будет представлена информация, не воспринимаемая как текст.


Содержание раздела