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


Поле заголовка Content-Description - часть 24


5.2.3. Субтип External-Body

Субтип external-body указывает, что в сообщении содержатся не данные, а ссылка на место, где эти данные находятся. В этом случае параметры описывают механизм доступа к внешним данным.

Когда объект MIME имеет тип "message/external-body", он состоит из заголовка, двух последовательностей CRLF, и заголовка для инкапсулированного сообщения. Если появится еще одна пара последовательностей CRLF, это завершит заголовок инкапсулированного сообщения. Однако так как тело инкапсулированного сообщения само является внешним, оно не появится вслед за заголовком. Например, рассмотрим следующее сообщение:

Content-type: message/external-body;

access-type=local-file;

name="/u/nsb/Me.jpeg"

Content-type: image/jpeg

Content-ID:

Content-Transfer-Encoding: binary

Это в действительности не тело!

Область в конце, которую можно назвать телом-фантомом, игнорируется для большинства сообщений с внешним телом. Однако оно может использоваться для хранения вспомогательной информации для некоторых таких сообщений, как это действительно бывает, когда тип доступа - "mail-server". Единственный тип доступа, описанный в этом документе и использующий тело-фантом, это "mail-server", но могут быть описаны другие типы в будущем.

Инкапсулированные заголовки во всех объектах "message/external-body" должны включать в себя поле заголовка Content-ID, для того чтобы предоставить уникальный идентификатор, который служит для ссылки на данные. Этот идентификатор может быть использован в процессе кэширования и для распознавания входных данных, когда типом доступа является "mail-server".

Заметим, что, как это специфицировано здесь, лексемы, которые описывают данные внешнего тела, такие как имена файлов и команды почтового сервера, должны быть записаны с использованием символьного набора US-ASCII.

Как с "message/partial", объекты MIME типа "message/external-body" MUST имеют транспортное кодирование 7-бит (по умолчанию).


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