Интегрированные сети ISDN


Совместимость с MIME - часть 2


/p>

Изображение, аудио и видео:

-

На минимальном уровне предоставить возможность обрабатывать любой не узнанный субтип, как если бы он был "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 имеют дополнительную гарантию, что пользователю не будет представлена информация, не воспринимаемая как текст.




Начало  Назад  Вперед



Книжный магазин