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

         

Поле заголовка Content-Description


7. Поле заголовка Content-Description



Часто оказывается желательным установить соответствие между описательной информацией и данным телом. Например, может быть полезным пометить тело типа "image" как "изображение старта космического корабля". Такой текст может быть помещен в поле заголовка Content-Description. Это поле всегда является опционным.

description := "Content-Description" ":" *text

Предполагается, что описание дается с использованием символьного набора US-ASCII, хотя механизм, специфицированный в RFC 2047, может быть использован и для значений Content-Description, не соответствующих стандарту US-ASCII.

8. Дополнительные поля заголовка MIME

Будущие документы могут содержать дополнительные поля заголовков MIME для различных целей. Любое новое поле заголовка, которое описывает содержимое сообщения должно начинаться со строки "Content-", для того чтобы такие поля можно было с гарантией отличить от обычных полей заголовков сообщения, следующих стандарту RFC-822.

MIME-extension-field :=

Используя поля заголовка MIME-Version, Content-Type и Content-Transfer-Encoding, можно подключить стандартным образом произвольные типы данных и добиться совместимости с требованиями документа RFC-822. Никакие ограничения введенные документами RFC-821 или RFC-822 не нарушаются, были приняты меры, чтобы исключить проблемы, связанные с дополнительными ограничениями из-за свойств некоторых механизмов пересылки почты по Интернет (см. RFC-2049).

Приложение A -- обзор грамматики

Это приложение содержит грамматические описания всех конструкций, содержащихся в протоколе MIME.



attribute := token Распознавание атрибутов не зависит от регистра, в котором написаны их имена.
composite-type := "message" / "multipart" / extension-token  
Content := "Content-Type" ":" type "/" subtype *(";" parameter) Распознавание типов среды и субтипов не зависит от регистра, в котором написаны их имена.
description := "Content-Description" ":" *text  
discrete-type := "text" / "image" / "audio" / "video" / "application" / extension-token  
encoding := "Content-Transfer-Encoding" ":" mechanism  
entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF )  
extension-token := ietf-token / x-token  
hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") Октет должен использоваться для символов > 127, =, пробелов или TAB в конце строк, и рекомендуется для любого символа вне списка "mail-safe" RFC 2049.
iana-token :=  
ietf-token :=  
Id := "Content-ID" ":" msg-id  
mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token  
MIME-extension-field :=  
MIME-message-headers := entity-headers fields version CRLF Порядок полей заголовка, заданный в BNF-определении не играет никакой роли.
MIME-part-headers := Заголовки объекта [поля] Любое поле, начинающееся с "content-", не имеет строго заданного значения и может игнорироваться.
parameter := атрибут "=" значение  
Ptext := hex-octet / safe-char  
qp-line := *(qp-segment transport-padding CRLF) транспортный заполнитель qp-части  
qp-part := qp-секция Максимальная длина 76 символов
qp-section := [*(ptext / SPACE / TAB) ptext]  
qp-segment := qp-секция *(SPACE / TAB) "=" Максимальная длина 76 символов
Quoted-printable := qp-line *(CRLF qp-line)  
safe-char := Символы вне списка "mail-safe" в RFC 2049 не рекомендуются.
subtype := Лексема расширения / лексема iana  
Token := 1*  
transport-padding := *LWSP-char Программа-отправитель не должна формировать транспортное заполнение ненулевой длины, но получатели должны быть способны обрабатывать такие транспортные заполнители.
tspecials := "(" / ")" / "" / "@" / "," / ";" / ":" / "\" / "/" / "[" / "]" / "?" / "=" При использовании в значениях параметров они должны иметь формат закавыченных строк.
Type := discretetype / compositetype  
Value := лексема / закавыченная строка  
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT  
x-token :=  
<
/p> II. Типы среды

1. Введение



Поле Content- Type используется для спецификации природы информации в теле MIME-объекта путем присвоения идентификаторов типа и субтипа среды и предоставления дополнительной информации, которая может быть необходима для данной разновидности среды. За именами типа и субтипа среды в поле следует набор параметров, заданных в нотации атрибут/значение. Порядок следования параметров не существенен.

Тип среды верхнего уровня используется для декларации общего типа данных, в то время как субтип определяет специфический формат данного типа информации. Таким образом, тип среды "image/xyz" говорит агенту пользователя, что данные характеризуют изображение и имеют формат "xyz". Такая информация может использоваться, для того чтобы решить, отображать ли пользователю исходные данные нераспознанного субтипа. Такие действия могут быть разумными для нераспознанного фрагмента субтипа "text", но не для субтипов "image" или "audio". По этой причине, зарегистрированные субтипы "text", "image", "audio" и "video" не должны содержать встроенных фрагментов другого типа. Такие составные форматы должны использовать типы "multipart" или "application".

Параметры являются модификаторами субтипа среды, и как таковые не оказывают никакого влияния на содержимое. Набор параметров зависит от типа и субтипа среды. Большинство параметров связано с одним специфическим субтипом. Однако определенный тип среды высшего уровня может определить параметры, которые приложимы к любому субтипу данного типа. Параметры могут быть обязательными или опционными. MIME игнорирует любые параметры, имена которых нераспознаны.

Поле заголовка Content-Type и механизм типа среды спроектированы так, чтобы сохранить масштабируемость, обеспечивая постепенный рост со временем числа пар тип/субтип и сопряженных с ними параметров. Транспортное кодирование MIME, а также типы доступа "message/external-body" со временем могут обрести новые значения.


Для того чтобы гарантировать то, что такие значения разработаны и специфицированы корректно, в MIME предусмотрен процесс регистрации, который использует IANA (Internet Assigned Numbers Authority) в качестве главного органа контролирующего данный процесс (см. RFC 2048). В данном разделе описаны семь стандартизованных типов среды верхнего уровня.



2. Определение типов среды верхнего уровня



Определение типа среды верхнего уровня состоит из:

(1) Имя и описание типа, включая критерии, согласно которым можно решить, относится ли данная среда к указанному типу.
(2) Имена и определения параметров, если таковые имеются, которые определены для всех субтипов данного типа, включая то, является ли данный параметр обязательным или опционным.
(3) Как агент пользователя и/или шлюз должен обрабатывать не узнанный субтип данного типа.
(4) Общие соображения о шлюзовании объектов данного типа, если таковые имеются.
(5) Любые ограничения на транспортное кодирование объектов данного типа.


3. Обзор базовых типов среды верхнего уровня



Имеется пять дискретных типов среды высокого уровня.

(1) text – текстовая информация. Субтип "plain" в частности указывает, что текст не содержит команд форматирования или каких-либо директив. Такой текст нужно отображать, так как он есть. Не нужно никакого специального программного обеспечения для восприятия такого текста, помимо поддержки указанного символьного набора. Другие субтипы должны использоваться для обогащенного текста (enriched) в форме, где прикладное программное обеспечение может улучшить представление текста. Но такая программа не нужна для общей обработки содержимого. Возможные субтипы "text" включают в себя любые форматы, которые могут быть прочитаны без обращения к программе, которая понимает этот формат. В частности, форматы, которые используют встроенное двоичное форматирование, не считаются непосредственно читаемыми. Очень простой и портативный субтип, "richtext", был определен в документе RFC 1341, и позднее пересмотрен в RFC 1896 под именем "enriched".
(2) image - графические данные. "Image" требует устройства отображения (такого как графический дисплей, графический принтер, или факс) для того чтобы просмотреть информацию. Первичный субтип определен для широко используемого формата изображения JPEG. Субтипы определены для двух широко используемых форматов изображения jpeg и gif.
(3) audio - звуковые данные. "Audio" требует выходного устройства (такого как громкоговоритель или телефон) для воспроизведения содержимого.
(4) video – видео данные. "Video" требует выходного устройства, способного воспроизвести движущееся изображение. В данном документе определен первичный субтип "mpeg".
(5) application – некоторые другие типы данных, обычно не интерпретированные двоичные данные или информация, которая должна быть обработана приложением. Субтип "octet-stream" следует использовать в случае не интерпретируемых двоичных данных, в этом случае простейшей рекомендацией может служить передача этой информации в файл пользователя. Субтип "PostScript" определен для транспортировки PostScript текстов.
<


/p> Существует два составных типа среды высшего уровня.

(1) multipart – данные, состоящие из нескольких объектов с различными типами данных. Определены четыре первичных субтипов, включая базовый субтип "mixed", специфицирующий смешанный набор частей, "alternative" - для представления одних и тех же данных в различных форматах, "parallel" - для частей, которые должны представляться одновременно и "digest" - для составных объектов, в которых каждая часть имеет тип по умолчанию "message/rfc822".
(2) message - инкапсулированное сообщение. Тело типа среды "message" составляет часть или весь объект сообщения некоторого типа. Такие объекты могут содержать в свою очередь другие объекты. Субтип "rfc822" используется, когда инкапсулированное содержимое само является сообщением RFC 822. Субтип "partial" определен для частичных сообщений вида RFC 822, чтобы разрешить по-фрагментную передачу слишком длинных тел сообщения. Другой субтип "external-body" определен для спецификации протяженных тел с помощью ссылок на внешние источники информации.


4. Дискретные значения типа среды



Пять из семи базовых значений типа среды относятся к дискретным телам. Содержимое этих типов должно обрабатываться с использование механизмов за пределами MIME, они непрозрачны для MIME-процессоров.



4.1. Тип среды Text



Тип среды "text" предназначен для посылки материала, который имеет принципиально текстуальную форму. Параметр "charset" можно использовать для указания символьного набора тела субтипов "text", включая субтип "text/plain", который является общим субтипом для чистого текста. Чистый текст не содержит форматирующих команд, спецификаций атрибутов шрифтов, инструкций обработки, директив интерпретации или разметки. Чистый текст представляет собой последовательность символов, которая может содержать разрывы строк или страниц.

Помимо чистого текста существует много форматов, называемых "богатый" текст ("rich text").


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



4.1.1. Представление разрывов строк



Каноническая форма любого субтипа MIME "text" должна всегда оформлять разрыв строки с помощью последовательности CRLF. Аналогично, любое появление CRLF в тексте MIME должно означать разрыв строки. Использование CR и LF по отдельности вне обозначения разрыва строки запрещено. Это правило работает вне зависимости от используемого символьного набора.

Правильная интерпретация разрывов строк при отображении текста зависит от типа среды. Следует учитывать, что одно и то же оформление разрывов строк при отображении "text/plain" может восприниматься корректно, в то время как для других субтипов "text", например, "text/enriched" [RFC-1896] аналогичные разрывы строк будут восприниматься как неверные. Нет необходимости в добавлении каких-либо разрывов строк при отображении "text/plain", в то время как отображение "text/enriched" требует введения соответствующего оформления разрывов строк.

Некоторые протоколы определяют максимальную длину строки. Например, SMTP [RFC-821] допускает максимум 998 октетов перед последовательностью CRLF. Для того чтобы реализовать транспортировку посредством такого протокола, данные, содержащие слишком длинные сегменты без CRLF, должны быть закодированы с применением соответствующего content-transfer-encoding.



4.1.2. Параметр Charset



Критическим параметром, который может быть специфицирован в поле Content-Type для данных "text/plain", является символьный набор.


Он специфицируется параметром "charset", например, как:

Content-type: text/plain; charset=iso-8859-1

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

Для других субтипов "text", семантика параметра "charset" должна быть определена аналогично параметрам, заданным для "text/plain", т.e., тело состоит полностью из символов данного набора. В частности, авторы будущих определений субтипов "text" должны обратить особое внимание мультиоктетным символьным наборам. Параметр charset для субтипов "text" дает имя символьному набору, как это определено в RFC 2045.

Заметим, что специфицированный символьный набор включает в себя 8-битовые коды и эти символы используются в теле, поле заголовка Content-Transfer-Encoding и для передачи данных с помощью транспортных протоколов (например, SMTP) необходима соответствующая кодировка, такая как [RFC-821].

Значение символьного набора по умолчанию, равное US-ASCII, являлось причиной многих неурядиц в прошлом. Для того чтобы исключить какие-либо неопределенности в будущем, настоятельно рекомендуется новым агентам пользователя задавать символьный набор в явном виде в качестве параметра типа среды в поле заголовка Content-Type. "US-ASCII" не указывает на произвольный 7-битовый символьный набор, а говорит о том, что все октеты в теле должны интерпретироваться как символы US-ASCII. Национальные и ориентированные на приложения версии ISO 646 [ISO-646] обычно не идентичны US-ASCII, и их непосредственное применение в электронной почте может вызвать проблемы. Имя символьного набора "US-ASCII" относится к кодам, заданным в документе ANSI X3.4-1986 [US- ASCII].

Полный набор символов US-ASCII представлен в ANSI X3.4-1986. Заметим, что управляющие символы, включая DEL (0-31, 127) не имеют определенного значения, исключение составляет комбинация CRLF (US-ASCII значения 13 и 10) обозначающая разрыв строки.


Два символа имеют широко используемые функции, это: FF (12) – продолжить последующий текст с начала новой страницы, и TAB или HT (9) часто (хотя и не всегда) означает "переместить курсор в следующую колонку. Колонки нумеруются, начиная с нуля и их позиции кратны 8. Помимо этих случаев любые управляющие символы или DEL в теле объекта могут появиться при следующих условиях.

(1) по причине того, что субтип текста, отличающийся от "plain", приписывает им некоторые дополнительные значения, или
(2) в рамках контекста частного соглашения между отправителем и получателем.
Определены следующие значения charset:

(1) US-ASCII – как это определено в ANSI X3.4-1986 [US-ASCII].
(2) ISO-8859-X -- где "X" следует замещать как это требуется для частей ISO-8859 [ISO-8859]. Допустимыми подменами "X" являются цифры от 1 до 10.
Символы с кодами в диапазоне 128-159 не имеют стандартизованных значений в рамках ISO-8859-X. Символы с кодами меньше 128 в ISO-8859-X имеют те же значения, что и в US-ASCII.

Значения символьных наборов "ISO-8859-6" и "ISO-8859-8" специфицируют применение визуального метода [RFC-1556].

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

Никакие символьные наборы, отличные от определенных выше, не могут использоваться в электронной почте без публикации и формальной регистрации в IANA. Допустимы частные соглашения, в этом случае имя символьного набора должно начинаться с "X-".

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

Если широко используемый символьный набор А является подмножеством другого символьного набора Б, а тело содержит только символы из набора А, он должен быть помечен как А.





4.1.3. Субтип Subtype



Простейшим и наиболее важным субтипом "text" является "plain". Он указывает, что текст не содержит форматирующих команд или директив. Чистый текст может отображаться непосредственно без какой-либо обработки. По умолчанию для электронной почты предполагается тип среды "text/plain; charset=us-ascii".



4.1.4. Не распознанные субтипы



Не распознанные субтипы "text" должны обрабатываться как чистый текст ("plain"), поскольку реализация MIME знает, как работать с данным символьным набором. Не распознанные субтипы, которые также специфицируют нераспознаваемый символьный набор, должны обрабатываться как "application/octet- stream".



4.2. Тип среды Image



Тип среды "image" указывает, что тело содержит изображение. Субтип называет имя специфического формата изображения. Эти имена не чувствительны к регистру. Исходным субтипом является "jpeg", который использует кодировку JFIF для формата JPEG [JPEG]. Не распознанные субтипы "image" должны обрабатываться как "application/octet-stream".



4.3. Тип среды Audio



Исходный субтип "basic" специфицирован, для того чтобы удовлетворить требованиям, которые соответствуют самому нижнему в иерархии аудио-форматов. Предполагается, что форматы для более высококачественного воспроизведения и/или низко полосной передачи будут определены позднее.

Содержимое субтипа "audio/basic" представляет собой моноканальное звуковое кодирование, использующее 8-битоый ISDN-стандарт с m-функцией преобразования [PCM] с частотой стробирования 8000 Hz. Не распознанные субтипы "audio" должны обрабатываться как "application/octet-stream".



4.4. Тип среды Type



Тип среды "video" указывает, что тело содержит движущееся изображение, возможно цветное и в сопровождении звука. Термин 'video' используется в самом общем значении, и не подразумевает какого-то конкретного формата. Субтип "mpeg" относится к видео закодированного согласно стандарту MPEG [MPEG].


Не распознанные субтипы "video" должны обрабатываться как "application/octet-stream".



4.5. Тип среды Application



Тип среды "application" следует использовать для дискретных данных, которые не могут быть отнесены ни к какой другой категории, в частности для данных, которые должны быть обработаны какой-то прикладной программой. Это информация, которая должна обрабатываться приложением до того как она станет доступной для просмотра пользователем. К предполагаемым применениям типа среды "application" относится файловый обмен, электронные таблицы, диспетчерские системы, базирующиеся на электронной почте.

Такие приложения могут быть определены как субтипы типа среды "application". В данном документе определены два субтипа:

octet-stream и PostScript.



4.5.1. Субтип Octet-Stream (поток октетов)



Субтип "octet-stream" используется для индикации того, что тело содержит произвольные двоичные данные. В настоящее время определены следующие параметры:

(1) TYPE – общий тип или категория двоичных данных. Это параметр предназначен для оператора-получателя, а не для программы обработки.
(2) PADDING – число бит заполнителя, добавленного к потоку бит, представляющему действительное содержимое, для того чтобы получить байт-ориентированный поток. Используется, когда число бит в теле не кратно 8
Оба эти параметра являются опционными.



4.5.2. Субтип PostScript



Тип среды "application/postscript" указывает на программу PostScript. В настоящее время допускается два варианта языка PostScript. Исходный вариант уровня 1 описан в [POSTSCRIPT], а более новый вариант уровня 2 рассмотрен в [POSTSCRIPT2].

Описания языка PostScript предоставляет возможности внутренней пометки специфических возможностей данного приложения. Эта пометка, называемая DSC (document structuring conventions) PostScript, предоставляет существенно больше информации, чем уровень языка. Использование DSC рекомендуется даже тогда, когда это непосредственно не требуется, так как обеспечивает более широкую совместимость.


Документы, которые недостаточно структурированы, не могут быть проверены с целью выяснения того, могут ли они работать в данной среде.

Работа универсальных интерпретаторов PostScript представляет серьезную угрозу безопасности, разработчикам не рекомендуется просто посылать тела PostScript имеющимся ("off-the-shelf") интерпретаторам. В то время как посылка PostScript-файла на принтер обычно безопасна, программисты должны рассмотреть все возможные последствия, прежде чем ввести интерактивное отображение тел типа PostScript на их читающих средствах MIME.

Ниже перечислены возможные проблемы, связанные с транспортировкой объектов PostScript.

(1) В список опасных операций языка PostScript входят "deletefile", "renamefile", "filenameforall" и "file". "File" является единственной опасной процедурой, которая применяется для входных/выходных потоков не стандартных данных. Конкретные реализации могут определить не стандартные файловые операторы, которые могут также представлять угрозу безопасности. "Filenameforall", - оператор поиска файлов, может показаться на первый взгляд безобидным.

Заметим, что этот оператор может раскрыть информацию о том, к каким файлам имеет доступ пользователь, а эти данные могут облегчить задачу хакеру. Отправители сообщений должны избегать использования потенциально опасных файловых операторов, так как такие операторы, скорее всего, недоступны в PostScript приложениях, где приняты меры по обеспечению безопасности. Программное обеспечение, которое используется для приема и отображения, должно блокировать потенциально опасные файловые операторы или принять меры по ограничению их возможностей.
(2) Язык PostScript предоставляет возможность для выхода из цикла интерпретатора или сервера. Операторы, сопряженные с выходом интерпретатора из цикла могут интерферировать с процедурами последующей обработки документов. Операторы PostScript, которые выводят интерпретатор из цикла, включают в себя серверы выхода и начала задания. Программе отправки сообщения не следует генерировать PostScript, который зависит от функционирования выхода интерпретатора из цикла, так как такая процедура может отсутствовать в реализациях с повышенной безопасностью. Программа приема сообщений должна полностью блокировать работу операторов "startjob" и "exitserver", также какие-либо изменения в среде PostScript на постоянной основе. Если эти операции не могут быть полностью исключены, для их выполнения должен быть организован контролируемый доступ с необходимостью ввода пароля.
(3) PostScript предоставляет операторы для установки системных параметров и специфических параметров внешних устройств. Эти установки параметров могут влиять неблагоприятным образом на работу интерпретатора. Процедуры PostScript, которые устанавливают системные параметры, могут включать в себя операторы "setsystemparams" и "setdevparams". Программа отправки не должна генерировать PostScript-сообщений, которые зависят от установки системных параметров. Программа приема и отображения сообщений должна блокировать изменение системных параметров. Если блокировка по каким-либо причинам невозможна, процедура установки параметров должна требовать специфического пароля.
(4) Некоторые реализации PostScript предоставляют нестандартные возможности для прямой загрузки и исполнения машинных кодов. Такие возможности чреваты злоупотреблениями. Программа отправки сообщений не должна использовать такие возможности. Программа приема и отображения сообщений не должна позволять применение таких операторов, если они имеются.
(5) PostScript является расширяемым языком, и многое, если не большинство, его реализаций предоставляют большое число расширений. Программа отправки сообщений не должна использовать нестандартные расширения. Программа приема и отображения сообщений должна быть уверена, что эти нестандартные расширения не представляют угрозы.
(6) Имеется возможность написания такой PostScript-программы, которая потребует огромных системных ресурсов. Можно также написать PostScript-фрагмент, который реализует бесконечный цикл. Оба варианта представляют угрозу для ничего не подозревающего получателя. Программа отправки сообщений должна избегать создания и распространения таких кодов. Программа приема и отображения сообщений должна предоставлять подходящий механизм для блокировки исполнения и удаления таких программ по истечении некоторого заданного времени.
(7) Существует возможность включения двоичной информации в PostScript-текст. Это не рекомендуется в электронной почте, так как это не поддерживается всеми PostScript-интерпретаторами, потому что сильно усложняет использование транспортного кодирования MIME.
(8) Наконец, в некоторых интерпретаторах PostScript вполне возможны ошибки, которые могут использоваться для получения не авторизованного доступа к системе получателя.
<


/p>

4.5.3. Другие субтипы приложений



Ожидается, что в будущем будут определены многие другие субтипы "application". Реализации MIME должны уметь обрабатывать нераспознанные субтипы как "application/octet-stream".



5. Значения типа среды Composite (составной)



Оставшиеся два из семи исходных значений Content-Type относятся к составным объектам. Составные объекты обрабатываются с использованием механизмов MIME -- процессор MIME обрабатывает тело объекта непосредственно.



5.1. Тип среды Multipart



В случае составных объектов, когда один или более различных наборов данных объединяется в одном теле, в заголовке объекта должно присутствовать поле типа среды "multipart". Тело должно тогда содержать одну или более частей, каждая из которых начинается с разделительной строки. За разделительной строкой следует заголовок, пустая строка и тело объекта. Таким образом, часть тела по своему синтаксису аналогична сообщению в RFC-822, но имеет другое назначение.

Часть тела является объектом и, следовательно, не должна интерпретироваться как сообщение RFC-822. Начнем с того, что части тела должны иметь заголовки. Допустимы части тела, которые начинаются с пустой строки. В таком случае отсутствие заголовка Content-Type обычно указывает, что соответствующее тело имеет тип содержимого "text/plain; charset=US-ASCII".

Единственные поля заголовка, которые определяют назначение частей тела, имеют имена, начинающиеся с "Content-". Все другие поля в заголовке части тела могут игнорироваться. Для экспериментальных или частных назначений могут создаваться поля, с именами, начинающимися с "X-". Информация, содержащаяся в этих полях может теряться в некоторых шлюзах.

Различие между сообщением RFC-822 и частью тела не велико, но существенно. Шлюз между Интернет и почтовым сервером X.400, например, должен быть способен различать части тела, содержащие изображение и инкапсулированное сообщение, тело которого представляет собой JPEG-образ.


Для того чтобы представить последнее, часть тела должна иметь "Content-Type: message/rfc822", и ее тело после пустой строки должно представлять собой инкапсулированное сообщение со своим собственным полем заголовка "Content-Type: image/jpeg". Применение подобного синтаксиса способствует преобразованию сообщений в части тела и обратно.

Как было заявлено ранее, каждая часть тела начинается со строки-разграничителя. Разграничитель не должен появляться внутри любой инкапсулированной части, или в качестве префикса любой строки. Это подразумевает, что генерирующий агент способен специфицировать уникальное значение пограничного параметра, которое не содержит в качестве префикса значения разграничительного параметра вкладываемой части.

Все существующие и будущие субтипы типа "multipart" должны использовать идентичный синтаксис. Субтипы могут отличаться по своей семантике и могут вводить дополнительные ограничения на синтаксис, но должны согласовываться с базовым синтаксисом типа "multipart". Это требование гарантирует, что все агенты пользователя будут, по крайней мере, способны распознать и разделить части составного объекта, даже если они относятся к нераспознанным субтипам.

Как задано в определении поля Content-Transfer-Encoding [RFC-2045], никакие кодировки кроме "7bit", "8bit" или "binary" не разрешены для объектов типа "multipart". Граничные разделители и поля заголовков "multipart" всегда представляются как 7-битовые коды US-ASCII, а данные внутри частей тела могут быть закодированы по-разному и иметь свои поля Content-Transfer-Encoding для каждой из частей.



5.1.1. Общий синтаксис



Поле Content-Type для составных объектов требует одного параметра - "boundary". Строка-разделитель определяется как строка, содержащая два символа дефис ("-", десятичный код 45), за которыми следует значение пограничного параметра из поля заголовка Content-Type, опционный строчный пробел и заключительные CRLF.



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

Грамматика для параметров поля Content-type такова, что в строке Content-type часто необходимо помещать пограничный параметр в кавычки. Это необходимо не всегда, но никогда не повредит. Программисты должны тщательно изучить грамматику, для того чтобы избежать генерации некорректных полей Content-type. Таким образом, типичное поле заголовка "multipart" Content-Type может выглядеть как:

Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p

Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"

Это значение Content-Type указывает, что содержимое состоит из одной или более частей со структурой, которая синтаксически идентична сообщению RFC-822, за исключением того, что область заголовка может быть совершенно пустой, а каждая из частей начинается со строки

--gc0pJq0M:08jU534c0p

Пограничный разделитель должен размещаться в начале строки, т.e., следовать за CRLF, а начальный CRLF рассматривается объединенным со строкой пограничного разделителя, а не частью предшествующей секции. За границей может следовать нуль или более символов строчного пробела (HT, SP). Далее следует еще один CRLF и поля заголовка следующей части, или два CRLF, что означает отсутствие полей заголовка следующей части. Если поле Content-Type отсутствует, предполагается объект типа "message/rfc822" в сообщении "multipart/digest", в противном случае "text/plain".



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

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

--gc0pJq0M:08jU534c0p--

Сравнение пограничной строки должно сопоставлять значение пограничного параметра с началом каждой строки-кандидата. Полного совпадения всей строки-кандидата не требуется, достаточно наличия разграничителя, следующего за CRLF.

Имеется место для дополнительной информации перед пограничным разделителем и после оконечного разграничителя. Эти области следует в норме оставлять пустыми, а программные реализации должны игнорировать размещенную там информацию. Некоторые реализации используют эти "ниши" для пересылки сообщений принимающим программам.

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

Ниже представлен простой пример составного сообщения, имеющего две части, каждая из которых содержит чистый текст, введенный явно и неявно:

From: Nathaniel Borenstein

To: Ned Freed

Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)

Subject: Sample message

MIME-Version: 1.0

Content-type: multipart/mixed; boundary="simple boundary"

Это преамбула. Она будет проигнорирована, но, тем не менее, это удобное место, чтобы отправитель мог поместить сообщение для принимающей стороны, которая не поддерживает MIME.



простая граница Это неявно введенный чистый US-ASCII-текст. Он не завершается на данной строке
простая граница Content-type: text/plain; charset=us-ascii. Это явно введенный чистый US-ASCII-текст. Он завершается на данной строке
простая граница Это эпилог. Он также игнорируется
Использование типа среды "multipart" в части тела в пределах другого составного объекта вполне допустимо. В таких случаях следует позаботиться о том, чтобы каждый из последовательно вложенных объектов использовал свой уникальный пограничный разделитель. Применение типа среды "multipart" при наличии только одной части тела может быть полезным в определенном контексте и вполне допустимо.

Практика показала, что тип "multipart" с единственной составной частью полезен для посылки сообщений с нетекстовым типом среды. Он имеет возможность формирования преамбулы, как места, где можно поместить инструкции по декодированию. Кроме того, многие шлюзы SMTP перемещают или удаляют заголовки MIME, и хороший MIME-декодер таким путем может получить необходимую информацию даже в отсутствие заголовка Content-Type и корректно декодировать сообщение.

Единственным обязательным глобальным параметром для типа среды "multipart" является граничный параметр, который состоит из 1 - 70 кодов из символьного набора, который надежен по отношению преобразований, осуществляемых почтовыми шлюзами. Значение параметра не должно завершаться пробелом. Формально это записывается в BNF-представлении следующим образом.

boundary := 0*69 bcharsnospace

bchars := bcharsnospace / " "

bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"

Вообще тело объекта "multipart" может быть специфицировано как:

dash-boundary := "--" boundary

; boundary берется из значения граничного параметра поля Content-Type.



multipart-body := [preamble CRLF]

dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
transport-padding := *LWSP-char Отправители не должны генерировать транспортные

; заполнители ненулевой длины, но получатели

; должны уметь обрабатывать заполнители, введенные

; при транспортировке.
encapsulation := delimiter transport-padding CRLF body-part

delimiter := CRLF dash-boundary

close-delimiter := delimiter "--"
epilogue := discard-text

; не должен появляться где-либо в теле секции. Заметим, что семантика части тела

; отличается от семантики сообщения, как это описано в тексте.

OCTET :=

Введение пробелов (HT, SP) и комментариев RFC 822 между элементами, показанными выше, не допустимо, так как эти BNF не специфицируют структурированное поле заголовка.

В определенных транспортных зонах регламентации RFC 822, такие как ограничение применения каких-либо символов, помимо печатных кодов US-ASCII могут не действовать. Ослабление этих ограничений может рассматриваться как локальное расширение определения тел, например, чтобы включить октеты вне набора US-ASCII, постольку, поскольку эти расширения поддерживаются системой передачи и соответствующим образом документированы в поле заголовка Content-Transfer-Encoding. Однако заголовки ни в коем случае не могут содержать чего-либо помимо кодов US-ASCII.



5.1.2. Обработка вложенных и составных сообщений



Субтип "message/rfc822" не имеет других условий завершения кроме окончания массива данных. Аналогично, некорректно укороченный составной объект не будет иметь завершающего разделителя, что может вызвать нарушение работы почтовой системы.

Существенно, чтобы такие объекты обрабатывались корректно, когда они сами вложены в другие составные структуры. Реализации MIME должны уметь распознавать граничные маркеры на любом уровне вложения.



5.1.3. Субтип Mixed



Субтип "mixed" типа "multipart" предназначен для использования в условиях, когда части тела независимы и должны объединяться в определенном порядке.


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



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


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

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

Каждая часть объекта "multipart/alternative" представляет одну и ту же информацию, версии не необязательно тождественны. Например, информация теряется, когда осуществляется трансляция ODA в PostScript или в чистый текст. Рекомендуется, чтобы каждая часть имела свое значение Content-ID в тех случаях, когда содержимое частей неэквивалентно. Например, там, где несколько частей типа "message/external-body" специфицируют способы доступа к идентичной информации, следует использовать одни и те же значения поля Content-ID. Возможен вариант, когда одно значение Content-ID может относиться к объекту "multipart/alternative", в то время как одно или более других значений Content-ID будут относиться к частям внутри объекта.



5.1.5. Субтип Digest



Этот документ определяет субтип "digest" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в дайджесте, значение по умолчанию Content-Type для части тела меняется с "text/plain" на "message/rfc822". Это сделано, для того чтобы допустить более читаемый формат дайджеста, совместимый с RFC-934.



Хотя можно специфицировать значение Content-Type для части тела в дайджесте, который отличается от "message/rfc822", такая часть как "text/plain", содержащая описание материала в дайджесте, делает это нежелательным. Тип содержимого "multipart/digest" предназначен для использования при посылке группы сообщений. Если необходима часть "text/plain", она должна быть включена как отдельная компонента сообщения "multipart/mixed". Дайджест в этом формате может выглядеть как.

From: Moderator-Address

To: Recipient-List

Date: Mon, 22 Mar 1994 13:34:51 +0000

Subject: Internet Digest, volume 42

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="---- главный разделитель ----"

------ главный разделитель ----

...Вводный текст или содержимое таблицы...

------ главный разделитель ----

Content-Type: multipart/digest;

boundary="---- следующее сообщение ----"

------ следующее сообщение ----

From: someone-else

Date: Fri, 26 Mar 1993 11:13:32 +0200

Subject: my opinion

... здесь размещается тело...

------ следующее сообщение ----

From: someone-else-again

Date: Fri, 26 Mar 1993 10:07:13 -0500

Subject: my different opinion

... здесь размещается следующее тело ...

------ следующее сообщение ------

------ главный разделитель ------



5.1.6. Субтип Parallel



Этот документ определяет субтип "parallel" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в параллельном объекте, порядок частей тела не играет роли.

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



5.1.7. Прочие субтипы Multipart



В будущем ожидается появление новых субтипов "multipart".


Реализации MIME должны уметь работать с нераспознанными субтипами "multipart" как с "multipart/mixed".



5.2. Тип среды Message



Часто желательно при посылке почты вложить туда какое-то другое сообщение. Для решения этой задачи определен специальный тип среды "message”. В частности, для вложения в сообщения RFC-822 служит субтип "rfc822"

Субтип "message" часто накладывает ограничения на допустимые типы кодирования. Эти ограничения описаны для каждого специфического субтипа. Почтовые шлюзы, системы транспортировки и другие почтовые агенты иногда изменяют заголовки верхнего уровня в сообщениях RFC 822. В частности, они часто добавляют, удаляют и меняют порядок полей заголовков. Эти операции запрещены для заголовков, вложенных в тело сообщения типа "message."



5.2.1. Субтип RFC822



Тип среды "message/rfc822" указывает, что тело содержит инкапсулированное сообщение. Однако в отличие от сообщений верхнего уровня RFC-822, ограничение, связанное с обязательным присутствием в теле "message/rfc822" заголовков "From", "Date", и, по крайней мере, одного адреса места назначения, здесь удалено. Необходимо лишь присутствие одного из заголовков "From", "Subject" или "Date". Следует заметить, что, несмотря на использование чисел "822", объект "message/rfc822" не должен абсолютно следовать регламентациям RFC-822. Более того, сообщение "message/rfc822" может быть статьей новостей или сообщением MIME.

В теле объекта "message/rfc822" не разрешены никакие кодировки помимо "7bit", "8bit" или "binary". Поля заголовка сообщения содержат только US-ASCII в любом регистре, а информация в теле может быть закодирована. Не-US-ASCII-текст в заголовках инкапсулированного сообщения может быть специфицирован с использованием механизма, описанного в документе RFC-2047.



5.2.2. Субтип Partial



Субтип "partial" определен, для того чтобы разрешить разделять на части слишком большие объекты, которые затем доставляются в виде отдельных почтовых сообщений и автоматически восстанавливаются как единое целое принимающим агентом пользователя.


Этот механизм может использоваться, когда промежуточный транспортный агент ограничивает максимальный размер почтового сообщения. Тип среды "message/partial", таким образом, указывает, что тело содержит фрагмент некоторого большого объекта.

Так как данные типа "message" могут не быть закодированны в виде base64 или закавыченной строки печатных символов, может возникнуть проблема, если объекты "message/partial" созданы в среде, которая поддерживает двоичный или 8-битовый обмен. Проблема возникает из-за того, что двоичные данные надо будет разбить на несколько сообщений "message/partial", каждое из которых требует двоичного транспорта. Если такие сообщения встретят по пути шлюз с 7-битовой передачей, не будет никакой возможности перекодировать эти фрагменты для 7-битовой среды. Можно конечно дождаться прихода всех составных частей, собрать исходный объект, закодировать его с помощью, например, base64, после чего начать все с начала. Но даже такой сложный сценарий может оказаться неосуществимым из-за того, что фрагменты могут транспортироваться разными путями. По этой причине, было специфицировано, что объекты типа "message/partial" должны всегда иметь транспортное кодирование “7bit” (по умолчанию). В частности, даже для сред, которые поддерживают двоичный или 8-битовый обмен, использование транспортного кодирования "8bit" или "binary" для MIME-объектов типа "message/partial" запрещено. Это в свою очередь предполагает, что внутреннее сообщение не должно использовать кодирование "8bit" или "binary". Так как некоторые агенты пересылки сообщений могут выбрать автоматическую фрагментацию длинных сообщений, а также из-за того, что эти агенты могут использовать разные пороги фрагментации, может так получиться, что фрагменты после сборки в свою очередь окажутся частями сообщения. Это вполне допустимо.

В поле Content-Type типа "message/partial" необходимо специфицировать три параметра. "id" - уникальный идентификатор, который должен использоваться для привязки фрагментов друг к другу. "number" - целое число, которое является номером фрагмента. "total" - целое число, характеризующее полное число фрагментов.


Число фрагментов является опционным и обязательно присутствует только в последнем фрагменте. Заметим также, что эти параметры могут быть заданы в любом порядке. Таким образом, второй сегмент 3-фрагментного сообщения может иметь поля заголовка одного из следующих видов.

ontent-Type: Message/Partial; number=2; total=3;

id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
ontent-Type: Message/Partial;

id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2
Но в третьем сегменте должно быть специфицировано полное число фрагментов.

Content-Type: Message/Partial; number=3; total=3;

id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Заметьте, что нумерация фрагментов начинается с 1, а не 0.

Когда фрагменты объекта, разорванные таким способом, складываются вместе, результатом всегда будет исходный MIME-объект, который может иметь свое собственное поле заголовка Content-Type, и, следовательно, иметь любой другой тип данных.



5.2.2.1. Фрагментация и сборка сообщений



Семантика восстановленных фрагментов сообщений должна соответствовать "внутреннему" сообщению, а не сообщению, в которое оно вложено. Это делает возможным, например, посылку большого аудио-сообщения в виде нескольких сообщений-фрагментов таким образом, что получатель воспримет его как простое аудио-сообщение, а не инкапсулированное сообщение, содержащее аудио-сообщение. Такая инкапсуляция рассматривается как прозрачная. Когда формируются фрагменты и осуществляется сборка составных частей сообщения "message/partial", заголовки инкапсулированного сообщения должны объединяться с заголовками вложенных объектов. При реализации этой процедуры должны выполняться следующие правила:

(1) Фрагментирующие агенты должны разделять сообщения только по границам строк. Это ограничение вводится из-за того, что при несоблюдении данного правила возникнет транспортная проблема сохранения семантики сообщения, не заканчивающегося последовательностью CRLF. Многие виды транспорта не способны решить такую задачу.
(2) Все поля заголовка исходного вложенного сообщения, за исключением тех, чьи имена начинаются с "Content-", и специфических полей заголовка "Subject", "Message-ID", "Encrypted" и "MIME-Version", должны копироваться в новое сообщение.
(3) Поля заголовка вложенного сообщения, начинающиеся с "Content-", плюс поля "Subject", "Message-ID", "Encrypted" и "MIME-Version" fields, должны быть добавлены в порядке к полям нового сообщения. Любые поля заголовка, которые не начинаются с "Content-" (за исключением полей "Subject", "Message-ID", "Encrypted" и "MIME-Version") будут проигнорированы и отброшены.
(4) Все поля заголовка второго и любых последующих вложенных сообщений отбрасываются принимающей программой в процессе сборки.
<


/p>

5.2.2.2. Пример фрагментации и сборки



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

X-Weird-Header-1: Foo

From: Bill@host.com

Subject: Audio mail (part 1 of 2)

Message-ID:

MIME-Version: 1.0

Content-type: message/partial; id="ABC@host.com";

number=1; total=2

X-Weird-Header-1: Bar

X-Weird-Header-2: Hello

Message-ID:

Subject: Audio mail

Content-transfer-encoding: base64

... здесь помещается первая половина закодированных аудио-данных ...

а вторая часть может выглядеть следующим образом:

From: Bill@host.com

>To: joe@otherhost.com

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)

Subject: Audio mail (part 2 of 2)

MIME-Version: 1.0

Message-ID:

Content-type: message/partial;

id="ABC@host.com"; number=2; total=2

... здесь помещается вторая половина закодированных аудио-данных ...

Затем, когда фрагментируемое сообщение оказывается собрано, результат, отображаемый для пользователя, должен выглядеть как:

X-Weird-Header-1: Foo

From: Bill@host.com

To: joe@otherhost.com

Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)

Subject: Audio mail

Message-ID:

MIME-Version: 1.0

Content-type: audio/basic

Content-transfer-encoding: base64

... здесь помещается первая половина закодированных аудио-данных ...

... здесь помещается вторая половина закодированных аудио-данных ...

Включение в заголовки второго и последующих секций фрагментированного сообщения поля "References" (ссылка), которое указывает на Message-Id (идентификатор сообщения) предшествующей секции, может быть полезно для системы чтения почты, которая умеет отслеживать ссылки. Однако генерация полей "References" является опционной.

Наконец, следует заметить, что поле "Encrypted" заголовка является устаревшим из-за внедрения конфиденциальной почты PEM (Privacy Enhanced Messaging; RFC-1421, RFC-1422, RFC-1423, RFC-1424), но правила описанные выше, несмотря ни на что, описывают правильный путь его обработки, если оно встретится в контексте прямого и обратного преобразования фрагментов "message/partial".





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-бит (по умолчанию).


В частности, даже в среде, которая поддерживает 8- битовую транспортировку, использование транспортного кодирования "8bit" или "binary" категорически запрещено для объектов типа "message/external-body".



5.2.3.1. Общие параметры External-Body



С "message/external- body" могут использоваться следующие параметры:

(1) ACCESS-TYPE (тип доступа). Слово, характеризующее поддерживаемый механизм доступа, с помощью которого можно получить файл или данные. Это слово не чувствительно к регистру, в котором напечатано. Параметр может принимать следующие значения "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE" и "MAIL-SERVER". Будущие значения, за исключением экспериментальных, начинающихся с "X-", должны регистрироваться IANA, как это описано в RFC-2048. Данный параметр является обязательным и должен присутствовать в каждом "message/external-body".
(2) EXPIRATION (конец срока действия). Дата (имеет синтаксис "date-time" как в RFC-822, документ RFC-1123 разрешил 4 цифры для обозначения года), после которой существование внешних данных не гарантируется. Этот параметр может использоваться с любым типом доступа и является опционным.
(3) SIZE (размер). Число октетов данных. Этот параметр предназначен, для того чтобы помочь получателю решить, достаточно ли ресурсов памяти для приема этих внешних данных. Заметим, что параметр описывает размер данных в канонической форме, то есть, до использования какого-либо транспортного кодирования или после декодирования. Этот параметр может использоваться с любым типом доступа и является опционным.
(4) PERMISSION (разрешение). Не чувствительное к регистру поле, которое указывает, предполагается ли возможность для клиента переписать данные. По умолчанию или, если разрешение соответствует "read", считается, что это запрещено и что, если данные однажды извлечены, они не потребуются никогда. Если PERMISSION соответствует "read-write", такое предположение не верно. "Read" и "Read-write" являются единственными определенными значениями параметра разрешения. Этот параметр используется с любым типом доступа и является опционным.
<


/p>

5.2.3.2. Типы доступа 'ftp' и 'tftp'



Тип доступа FTP или TFTP указывают, что тело сообщения доступно в виде файла с помощью протоколов FTP [RFC-959] или TFTP [RFC- 783], соответственно. Для этих типов доступа необходимы следующие параметры:

(1) NAME (имя). Имя файла, который содержит тело данных.
(2) SITE (узел). ЭВМ, с которой может быть получен файл с помощью данного протокола. Это должно быть официально зарегистрированное имя, а не псевдоним.
(3) Прежде чем какие-либо данные будут извлечены с помощью FTP, пользователь должен выполнить процедуру аутентификации (ввести имя и пароль) на машине, указанной в параметре SITE. По соображениям безопасности имя и пароль не специфицируются параметрами типа доступа, они должны быть получены непосредственно от пользователя.
Кроме того, следующие параметры являются опционными:

(1) DIRECTORY (каталог). Каталог, из которого должен быть взят файл с именем, заданным параметром NAME.
(2) MODE (режим). Строка символов, не зависящая от регистра ввода и указывающая на режим, который должен использоваться при извлечении информации. Допустимыми значениями параметра для типа доступа "TFTP" являются "NETASCII", "OCTET" и "MAIL", как это определено для протокола TFTP [RFC- 783]. Допустимыми значениями параметра для типа доступа "FTP" являются "ASCII", "EBCDIC", "IMAGE" и "LOCALn", где "n" - целое число, обычно 8. Они соответствуют типам представления "A" "E" "I" и "L n", как это задано протоколом FTP [RFC-959]. Заметим, что "BINARY" и "TENEX" не являются корректными значениями для MODE и что вместо этого следует использовать "OCTET", "IMAGE" или "LOCAL8". Если параметр MODE не задан, значением по умолчанию является "NETASCII" для TFTP и "ASCII" во всех прочих случаях.


5.2.3.3. Тип доступа 'anon-ftp'



Тип доступа "anon-ftp" идентичен варианту "ftp", за исключением того, что пользователю не нужно предоставлять имя и пароль.


Вместо этого протокол ftp воспользуется именем "anonymous" и паролем, равным почтовому адресу пользователя.



5.2.3.4. Тип доступа 'local-file'



Тип доступа "local-file" указывает, что тело данных доступно в виде файла на локальной ЭВМ. Для этого типа доступа определены два дополнительные параметра:

(1) NAME (имя). Имя файла, который содержит тело данных. Этот параметр является обязательным для типа доступа "local-file".
(2) SITE (узел). Спецификатор домена для данной ЭВМ или набора машин, которые имеют доступ к данному информационному файлу. Этот опционный параметр используется для описания локального указателя на данные, т.е., узел или группа узлов, откуда данный файл доступен. В качестве символов подмены в имени домена могут использоваться звездочки, как, например, в "*.bellcore.com", чтобы указать на группу ЭВМ, откуда данные доступны непосредственно.
5.2.3.5. Тип доступа 'mail-server' Access-Type



Тип доступа "mail-server" указывает, что тело данных доступно на почтовом сервере. Для этого типа доступа определены два дополнительные параметра:

(1) SERVER (сервер). Спецификация адреса почтового сервера, с которого может быть получены данные. Этот параметр является обязательным для типа доступа "mail-server".
(2) SUBJECT (тема сообщения). Тема сообщения (subject), которая используется в почтовом сообщении с целью получения данных. Этот параметр является опционным.
Так как почтовые сервера воспринимают разнообразные синтаксисы, некоторые из которых являются многострочными, полная команда, которая должна быть послана почтовому серверу, не включается в качестве параметра с поле заголовка content-type. Вместо этого, она заносится как тело-фантом, когда тип среды соответствует "message/external-body", а тип доступа - mail-server.

Заметим, что MIME не определяет синтаксис почтового сервера. Скорее, оно позволяет включение произвольных команд почтового сервера в тело-фантом. Программные реализации должны включать тело-фантом в тело сообщения, которое посылается по адресу почтового сервера для получения нужных данных.



В отличие от других типов доступа, доступ к почтовому серверу является асинхронным и происходит в произвольный момент времени. По этой причине важно, чтобы существовал механизм, с помощью которого полученные данные могли быть сопоставлены с исходным объектом "message/external-body". Почтовые серверы MIME должны использовать то же поле Content-ID в сообщении-отклике, которое было использовано в исходных объектах "message/external-body", для того чтобы облегчить такое сопоставление.



5.2.3.6. Соображения безопасности External-Body



Объекты "Message/external-body" подводят к следующим важным соображениям безопасности:

(1) Доступ к данным через указатель "message/external-body" эффективно приводит к тому, что получатель сообщения выполняет операцию, которую специфицировал отправитель. Следовательно, отправитель сообщения может заставить получателя выполнить нечто, что тот бы в противном случае не сделал. Например, отправитель может специфицировать процедуру, которая попытается извлечь данные, для получения которых тот не имеет авторизации, принуждая получателя помимо его воли нарушить некоторые правила безопасности. По этой причине агенты пользователя, способные работать с внешними указателями, должны сначала описать процедуру, которую ни хотят предложить выполнить получателю, попросить разрешения и только после этого запускать этот процесс.
(2) Иногда MIME используется в среде, которая предоставляет некоторые гарантии целостности и аутентичности сообщений. В этой ситуации такие гарантии можно отнести только к собственно содержимому сообщения. Что касается механизма MIME "message/external-body", здесь такие гарантии, вообще говоря, могут быть и не реализованы. В частности, имеется возможность разрушить определенные механизмы доступа, даже если сама система доставки сообщений вполне безопасна.


5.2.3.7. Примеры и дальнейшие расширения



Когда используется механизм внешнего тела в сочетании с типом среды "multipart/alternative", это расширяет функциональность "multipart/alternative", так как включает случай, когда один и тот же объект может быть получен через разные механизмы доступа.


Когда это сделано, отправитель сообщения должен упорядочить части по предпочтительности формата, а затем по механизму доступа.

Для распределенных файловых систем очень трудно знать заранее группу машин, где файл может быть доступен непосредственно. Следовательно, имеет смысл предоставить как имя файла на случай его прямой доступности, так имена одного или нескольких узлов, где может быть доступен этот файл. Программные реализации могут пытаться извлечь удаленные файлы, используя FTP или другой протокол. Если внешнее тело доступно за счет нескольких механизмов, отправитель может включить несколько объектов типа "message/external-body" в секции тела объекта "multipart/alternative".

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

Поля заголовка вложенного сообщения, которые появляются в теле "message/external-body" должны использоваться для декларации типа среды внешнего тела, если оно представляет собой нечто отличное от чистого текста US-ASCII, так как внешнее тело не имеет секции заголовка, чтобы декларировать тип. Аналогично здесь должно быть также декларировано любое транспортное кодирование, отличное от "7bit". Таким образом, полное сообщение "message/external-body", относящееся к объекту в формате PostScript, может выглядеть как:

From: От кого-то

To: Кому-то

Date: Когда-то

Subject: Нечто

MIME-Version: 1.0

Message-ID:

Content-Type: multipart/alternative; boundary=42

Content-ID:

--42

Content-Type: message/external-body; name="BodyFormats.ps";

site="thumper.bellcore.com"; mode="image";
access-type=ANON-FTP; directory="pub";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript

Content-ID:

--42

Content-Type: message/external-body; access-type=local-file;



name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript

Content-ID:

--42

Content-Type: message/external-body;

access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript

Content-ID:

get RFC-MIME.DOC

--42--

Заметим, что в вышеприведенных примерах в качестве транспортного кодирования для Postscript данных предполагается "7bit".

Подобно типу "message/partial", тип среды "message/external-body" предполагается прозрачным, т.е. передается тип данных внешнего тела, а не сообщение с телом данного типа. Таким образом, заголовки внешней и внутренней частей должны быть объединены с использованием правил, изложенных выше для "message/partial". В частности, это означает, что поля Content-type и Subject переписываются, а поле From сохраняется в неизменном виде.

Заметьте, что, так как внешние тела не передаются вместе с указателем, они не должны удовлетворять транспортным ограничениям, которые налагаются на сам указатель. В частности, почтовая транспортная среда Интернет может реализовать 7-битовый обмен и накладывать ограничение на длину строк, но они не распространяются на указатели на двоичное внешнее тело. Таким образом, транспортное кодирование не обязательно, но допустимо.

Заметим, что тело сообщения типа "message/external-body" регламентируется базовым синтаксисом сообщения RFC 822. В частности, все, что размещено перед первой парой CRLF является заголовком, в то время как все, что следует после заголовка, представляет собой данные, которые игнорируются для большинства типов доступа.



6. Экспериментальные значения типа среды



Значение типа среды, начинающееся с символов "X-" представляет собой частное значение, предназначенное для применения системами, которые согласились между собой работать в таком режиме.


Любой формат, не являющийся стандартным, должен иметь имя, начинающееся с префикса "X-", а утвержденные стандартные имена никогда не начинаются с "X-".

Вообще, использование "X-" для типов верхнего уровня категорически не рекомендуется. Разработчики должны придумывать субтипы существующих типов. Во многих случаях субтип "application" будет более уместен, чем новый тип верхнего уровня.



Приложение A -- обзор грамматики



Данное приложение содержит все синтаксические конструкции, описанные в разделе MIME. Сама по себе данная грамматика не может считаться полной. Она базируется на нескольких правилах, определенных в документе RFC 822. Если какой-то термин не определен, его значение предполагается заданным в RFC 822. Сами правила RFC 822 здесь не представлены.

boundary := 0*69 bcharsnospace

bchars := bcharsnospace / " "

bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"

body-part :=

close-delimiter := delimiter "--"

dash-boundary := "--" boundary

boundary берется из значения пограничного параметра из поля Content-Type.
delimiter := CRLF dash-boundary

discard-text := *(*text CRLF); Может игнорироваться или отбрасываться.

encapsulation := delimiter transport-padding CRLF body-part

epilogue := discard-text

multipart-body := [preamble CRLF]

Dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
preamble := discard-text

transport-padding := *LWSP-char

; Отправители не должны генерировать транспортных заполнителей не нулевой

; длины, но получатели должны уметь обрабатывать заполнители, добавленные в

; сообщение при транспортировке.



III. Расширения для заголовков сообщений с не-ASCII текстом



В этом разделе описывается техника кодирования не-ASCII-текста в различных частях заголовка сообщения RFC-822 [2].



Подобно тому, как это рассказано в первом разделе описания MIME, методика сконструирована так, чтобы допустить использование не-ASCII символов в заголовках сообщения так, чтобы даже специфические) удаляют некоторые поля заголовков, сохраняя другие, (b) меняет содержимое адресов в полях To или Cc, (c) меняют вертикальный порядок размещения полей заголовка. Кроме того, некоторые почтовые программы не всегда способны корректно интерпретировать заголовки сообщений, в которых встречаются некоторые редко используемые рекомендации документа RFC 822, например, символы обратной косой черты для выделения специальных символов типа "

Расширения, описанные здесь, не базируются на редко используемых возможностях RFC-822. Вместо этого, определенные последовательности "обычных" печатных ASCII символов (известных как "encoded-words" – кодировочные слова) зарезервированы для использования в качестве кодированных данных. Синтаксис кодированных слов таков, что они вряд ли могут появиться в нормальном тексте заголовков сообщений. Более того, символы, используемые в кодировочных словах, не могут иметь специального назначения в контексте, где появляются эти слова.

Вообще, "encoded-word>" представляет собой последовательность печатных ASCII-символов, которая начинается с "=?", завершается "?=" и имеет два "?" между ними. Оно специфицирует символьный набор и метод кодирования, а также включает в себя оригинальный текст в виде графических ASCII-символов, созданный согласно правилам данного метода кодирования.

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

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

Данный документ в заметной мере базируется на нотации и терминах RFC-822 и RFC-2045. В частности, синтаксис для ABNF, используемый здесь, определен в RFC-822. Среди терминов, определенных в RFC-822 и использованных в данном документе: 'addr-spec' (спецификация адреса), 'атом', 'CHAR', 'комментарий', 'CTL', 'ctext', 'linear-white-space' (HT| SP|CRLF), 'фраза', 'quoted-pair', 'закавыченная строка', 'пробел' и 'слово'. Успешная реализация расширения этого протокола требует тщательного внимания к определениям этих терминов в RFC-822.

Когда в данном документе встречается термин "ASCII", он относится к "7-битовому стандарту, ANSI X3.4-1986. Имя этого символьного набора в MIME "US-ASCII".




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