Previous: 4.4.14.3 Протокол Интернет для работы с сообщениями IMAP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет
    Next: 4.4.14.5 Программа Sendmail

Формат тела Интернет сообщений

Стандарт STD 11, RFC 822 определяет протокол представления сообщений, структуру их заголовков. При этом предполагается, что текст сообщения построен исключительно из кодов US-ASCII. Набор документов MIME (Multipurpose Internet Mail Extensions; RFC-2045-49) задает формат сообщений, который предоставляет следующие возможности.

1. Передача текстовых сообщений с символьным набором, отличным от US-ASCII.
2. Передача сообщений нетекстового формата (например, звукового письма).
3. Использование комбинированных сообщений, содержащих разнородные части.
4. Размещение в заголовке информации в символьном наборе, отличном от US-ASCII.

Документ RFC-2045 характеризует различные заголовки, которые служат для описания структуры MIME-сообщений. RFC 2046 определяет общую структуру MIME и исходный набор типов среды. RFC 2047 описывает расширения документа RFC 822, позволяя применение в полях заголовков символьных наборов, отличных US-ASCII. RFC 2048 специфицирует различные ограничения, вводимые IANA, для процедур, сопряженных с MIME. RFC 2049 характеризует критерии соответствия требованиям MIME, содержит примеры допустимых форматов и библиографию.

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

Одним из существенных ограничений традиционной электронной почты, базирующейся на RFC 821-822, является установка предельного размера строки (1000 7-битовых US-ASCII символов). Это вынуждало пользователей конвертировать текст различными методами в последовательность US-ASCII-кодов (например, процедура uuencode или преобразование в коды Base-64).

Существенные проблемы возникали при почтовом обмене между узлами, поддерживающими протоколы RFC 822 и X.400. Протокол X.400 [X400] определяет механизм включения нетекстовых материалов в почтовые сообщения. Существующие протоколы согласования работы X.400 и RFC 822 предполагают, что X.400 осуществляет преобразование нетекстовых вставок в формат IA5Text, или такие сообщения просто выбрасываются. Отправитель сообщения часто не знает о возможностях получателя, что может привести к тому, что последний, получив сообщения, попросту не сможет его прочесть. Таким образом, нужен механизм согласования возможностей отправителя и получателя на начальной стадии их взаимодействия до начала передачи тела сообщения.

В протоколе MIME регламентируется следующее:

1. Поле заголовка MIME-Version, которое характеризует версию протокола и позволяет почтовым агентам согласовать свои возможности и исключить конфликты с устаревшим программным обеспечением.
2. Поле заголовка Content-Type, которое используется для спецификации типа среды и субтипа данных в теле сообщения, а также для описания канонической формы этих данных.
3. Поле заголовка Content-Transfer-Encoding, которое может использоваться для задания типа преобразования.
4. Два дополнительные поля заголовка, предусмотренные для уточнения описания данных в теле сообщения (Content-ID и Content-Description).

Важно заметить, что основополагающими принципами при создании MIME была совместимость с существующими стандартами и надежность работы. Для тех, кто попытается реализовать протокол MIME, определенный интерес могут представлять документы RFC 1344, RFC 1345 и RFC 1524.

Далее все цифровые величины и октеты приводятся в десятичном представлении. Все значения типа среды, субтипы и имена параметров безразличны к регистру их написания. Значения параметров, напротив, зависимы от того строчными или прописными буквами они записаны.

Терм CRLF в данном описании относится к последовательности октетов, соответствующих ASCII-символам CR (десятичный код 13) и LF (десятичный код 10), которые обозначают разрыв строки.

Терм "символьный набор" используется в MIME для того, чтобы обозначить метод преобразования последовательности октетов в последовательность символов. Заметим, что безусловное и однозначное преобразование в обратном направлении не требуется, то есть не все символы могут быть представлены через данный символьный набор (более чем одна последовательность октетов может соответствовать одной и той же последовательности символов).

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

Термин "символьный набор" был первоначально введен для описания прямых схем преобразования, таких как ASCII и ISO-8859-1, для которых характерна однозначная связь символов и кодовых октетов. Многооктетные кодированные символьные наборы и методики переключения несколько осложнили ситуацию.

Термин "сообщение", обозначает сообщение типа RFC 822, передаваемое по сети, или сообщение, инкапсулированное в тело типа "message/rfc822" или "message/partial".

Термин "объект" (entity) относится к полям заголовка MIME и содержимому сообщения или его части в случае, если оно составное. Спецификация таких объектов определяется исключительно MIME. Так как содержимое объекта часто называется "тело", имеет смысл говорить о теле объекта. Любой вид поля может быть представлен в заголовке объекта, но только поля, имена которых начинаются с "content-" имеют значение, связанное с протоколом MIME.

Выражение "7-битовые данные" относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Октеты с кодом больше чем 127 или равные нулю не допустимы. Октеты CR (десятичный код 13) и LF (десятичный код 10) могут встречаться только в виде последовательности, отмечающей конец строки.

Выражение "8-битовые данные " относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Но здесь допустимы октеты с десятичными значениями кодов, превышающими 127 (нулевые коды не допускаются).

"Строки" в данном контексте представляют собой последовательности октетов, завершающиеся CRLF. Это согласуется с документами RFC 821 и RFC 822.

MIME определяет ряд новых полей заголовков по сравнению с RFC 822. Они описывают содержимое MIME-объекта. Эти поля заголовков используются в двух контекстах:

1. В качестве части стандартного заголовка RFC 822.
2. В MIME-заголовке в рамках составной конструкции сообщения.

Ниже представлено формальное описание этих полей заголовка.

entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-headers fields version CRLF

; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.

MIME-part-headers := entity-headers [ fields ]

; Любое поле, не начинающееся с "content-" не может иметь какого-либо значения и может игнорироваться.

; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.

Так как документ RFC 822 был опубликован в 1982, там имелся только один формат для сообщений, передаваемых по каналам Интернет, и по этой причине не было необходимости декларировать тип такого стандарта. MIME является независимым дополнением документа RFC 822. Хотя протокол MIME строился так, чтобы обеспечить совместимость с RFC 822, бывают обстоятельства, когда почтовому агенту желательно выяснить, составлено ли сообщение с учетом нового стандарта. Поле заголовка "MIME-Version" служит как раз для того, чтобы можно было определить, какому стандарту соответствует тело сообщения. Сообщения, соответствующие MIME обязаны содержать такое поле заголовка со следующим текстом:

MIME-Version: 1.0

Присутствие этого поля заголовка означает, что сообщение подготовлено согласно требованиям MIME. Так как существует возможность того, что в будущем формат документов может быть изменен, формальное BNF-представление поля MIME-Version следует записать следующим образом:

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Таким образом, будущие спецификаторы формата, которые могут заменить версию "1.0", ограничены двумя цифровыми полями, разделенными точкой. Если сообщение получено со значением поля MIME-version, отличным от "1.0", оно может не соответствовать данному описанию.

Заметим, что поле заголовка MIME-Version должно располагаться в самом начале сообщения. При составном сообщении не требуется, чтобы каждая из частей начиналась с поля версии. Это необходимо лишь в случае, когда заголовки встроенных сообщений типа "message/rfc822" или "message/partial" объявляют о совместимости со стандартом MIME.

Для некоторых приложений согласование версий должно проводиться независимо. Некоторые форматы (такие как application/postscript) имеют внутреннюю систему нумерации версий для каждого типа среды. Там где имеет место такое соглашение, MIME не предпринимает попыток подменить эту систему. Там где такого соглашения нет, тип среды MIME может использовать параметр "version" в поле типа содержимого. При проверке значений MIME-Version любые строки комментария RFC 822 должны игнорироваться. В частности, следующие четыре записи поля MIME-Version эквивалентны.

MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0

В отсутствии поля MIME-Version, принимающий почтовый агент (следующий стандарту MIME или нет) может опционно интерпретировать сообщения согласно локальным соглашениям.

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

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

Поле заголовка Content-Type было первым, определенным в документе RFC-1049. В RFC-1049 использовался более простой и менее мощный синтаксис, который, в прочем, вполне согласуется с регламентациями MIME.

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

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

Например, параметр "charset" применим к любому субтипу "текста", в то время как параметр "boundary" необходим для любого субтипа типа среды "multipart". Не существует параметров, применимых для всех типов среды.

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

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

В нотации BNF, значение поля заголовка Content-Type определяется следующим образом:

Заметим, что определение "tspecials" совпадает с определением "specials" в RFC 822 с добавлением трех символов "/", "?" и "=" и удалением "." (точка).

Заметим также, что спецификация субтипа является MANDATORY - она не может быть удалена из поля заголовка Content-Type. Не существует субтипов по умолчанию. Тип, субтип и имена параметров не зависят от регистра, в которых они напечатаны. Например, TEXT, Text и TeXt являются эквивалентными типами среды верхнего уровня. Значения же параметров в норме чувствительны к регистру, в котором они напечатаны, но иногда интерпретируются без учета регистра в зависимости от приложения. (Например, границы типа multipart являются чувствительными к регистру, а параметр "access-type" для сообщения message/External-body не чувствителен.)

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

Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii".

Предполагается, что имена субтипов при их применении не вызовут конфликтов. Так недопустимо, чтобы в различных приложениях "Content-Type: application/foobar" означало различные вещи. Существует два приемлемых механизма определения новых субтипов среды.

1. Частные значения (начинающиеся с "X-") могут быть определены для двух взаимодействующих агентов без официальной регистрации или стандартизации.
2. Новые стандартные значения должны регистрироваться IANA, как это описано в RFC 2048.

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

Content-type: text/plain; charset=us-ascii

Это значение подразумевается, если не специфицировано поле заголовка Content-Type. Рекомендуется, чтобы это значение по умолчанию использовалось в случае, когда встретилась нераспознанное значение поля заголовка Content-Type. В присутствии поля заголовка MIME-Version и отсутствии поля Content-Type, принимающий агент пользователя может также предположить, что отправитель предлагает простой текст в ASCII-кодировке. Простой ASCII-текст может предполагаться в отсутствии MIME-Version или в присутствии синтаксически некорректного поля заголовка Content-Type, хотя это может и не совпадать с намерениями отправителя.

Многие типы среды, которые могут передаваться посредством электронной почты, представляются в своем естественном формате, таком как 8-битовые символы или двоичные данные. Такие данные не могут быть переданы посредством некоторых транспортных протоколов. Например, RFC 821 (SMTP) ограничивает почтовые сообщения 7-битовым символьным набором ASCII со строками короче 1000 символов, включая строчные разделители CRLF.

Таким образом, необходимо определить стандартный механизм кодировки таких данных в 7-битный формат с короткими строками. В MIME для этой цели используется поле заголовка "Content-Transfer-Encoding". Это поле не было определено каким-либо прежним стандартом.

Значения полей Content-Transfer-Encoding представляют собой лексему, характеризующую тип кодирования, как это описано ниже.

Эти значения не чувствительны к регистру, в котором напечатаны. - Base64, BASE64 и bAsE64 эквивалентны. Тип кодировки 7BIT требует, чтобы тело уже имело 7-битовое представление, пригодное для передачи. Это значение по умолчанию, означает, что в отсутствии поля Transfer-Encoding предполагается "Content-Transfer-Encoding: 7BIT".

Лексема Content-Transfer-Encoding предоставляет два вида информации. Она специфицирует, какому виду кодового преобразования подвергнуто тело сообщения и, следовательно, какая процедура декодирования должна использоваться при восстановлении исходного вида сообщения.

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

В настоящее время определены три преобразования: тождественное (никакого преобразования), преобразование в последовательность печатных символов и в последовательность кодов "base64".

Значения Content-Transfer-Encoding "7bit", "8bit" и "binary" означают, что никакого преобразования не произведено. Они указывают на тип тела сообщения, и позволяют предполагать, какое кодирование может потребоваться при передаче данных.

Кодирование в последовательность печатных символов или в кодовую последовательность base64 предполагает преобразование из произвольного исходного формата в представление "7bit", что позволяет передачу через любые транспортные среды.

Всегда должна использоваться корректная метка Content-Transfer-Encoding. Пометка данных, преобразованных программой UUENCODE и содержащих 8-битовые символы, как "7bit" не допустима, такие данные должны помечаться только как "binary".

При прочих равных условиях предпочтительным представлением является последовательность печатных символов или кодов base64.

Передача почтовых сообщений закодированных программой uuencode описана в документе RFC 1652. Но следует иметь в виду, что ни при каких обстоятельствах Content-Transfer-Encoding "binary" нельзя считать приемлемым для e-mail. Однако когда используется MIME, двоичное тело сообщение может быть помечено как таковое.

Программисты могут, если необходимо, определить частные значения Content-Transfer-Encoding. При этом должны использоваться x-лексемы, которые представляют собой имена с префиксом "X-", что указывает на нестандартный статус, например, "Content-Transfer- Encoding: x-my-new-encoding". Дополнительные стандартизованные значения Content-Transfer-Encoding должны быть специфицированы в официальных документах RFC.

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

Если поле заголовка Content-Transfer-Encoding появляется как часть заголовка сообщения, оно относится ко всему телу сообщения. Если поле заголовка Content-Transfer-Encoding появляется в качестве части заголовка объекта, то зоной его действия будет тело этого объекта. Если объект имеет тип "multipart", то Content-Transfer-Encoding не может иметь значение "7bit", "8bit" или "binary". Следует заметить, что большинство типов среды определены в терминах октетов, а не бит, поэтому описываемые механизмы относятся к кодировке произвольных потоков октетов, а не бит. Если необходимо закодировать битовую последовательность, она должна быть преобразована в последовательность октетов с сетевой последовательностью бит ("big-endian"), в которой более ранние биты становятся старшими битами октетов. Битовые потоки, длина которых не кратна 8, должны быть дополнены нулями.

Механизмы кодировки, определенные здесь, осуществляют преобразование любых данных в ASCII. Таким образом, предположим, например, что объект имеет следующие поля заголовка:

Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64

Это должно интерпретироваться так, что тело имеет кодировку base64, а исходные данные имели представление в ISO-8859-1.

Определенные значения Content-Transfer-Encoding могут использоваться только с определенными типами среды. В частности, категорически запрещено использовать любую кодировку отличную от "7bit", "8bit" или "binary" с любым составным типом среды, т.e. включающим и другие поля Content-Type. В настоящее время допустимы составные типы среды "multipart" и "message". Все кодировки, допустимые для тел типа multipart или message должны использоваться на самом внутреннем уровне.

Следует также заметить, что по определению, если составной объект имеет значение transfer-encoding равное "7bit", но один из составляющих объектов имеет менее регламентирующее значение, например, "8bit", тогда либо внешняя метка "7bit" является ошибкой, или внутренняя метка "8bit" устанавливает слишком высокое требование к транспортной системе (следовало проставить 7bit).

Хотя запрет использования content-transfer-encodings для составного тела может показаться чрезмерно регламентирующим, следует избегать вложенных кодирований, в которых данные подвергаются последовательно обработке несколькими алгоритмами. Вложенные кодирования заметно повышают сложность агентов пользователя. Помимо очевидных проблем эффективности при множественном кодировании они могут затемнить базовую структуру сообщения. В частности они могут подразумевать, что необходимо несколько операций декодирования, чтобы определить, какие типы тел содержит сообщение. Запрет вложенных кодировок может осложнить работу некоторых почтовых шлюзов, но это представляется меньшей бедой, чем осложнение жизни агентов пользователя при вложенном кодировании.

Любой объект с нераспознанным значением Content-Transfer-Encoding должен рассматриваться, как если бы он имел код Content-type "application/octet-stream", вне зависимости оттого, что утверждается полем заголовка Content-Type.

Может показаться, что Content-Transfer-Encoding может быть выяснено из характеристик среды, для которой нужно осуществить кодирование или, по крайней мере, что определенное Content-Transfer-Encodings может быть предназначено для использования с определенными типами среды. Есть несколько причин, почему это не так. Во-первых, существующие различные типы транспорта, используемые для почты, некоторые кодирования могут годиться для определенных комбинаций типов среды и транспорта, но быть непригодными для других. Например, при 8-битовой передаче, при определенном символьном наборе для текста не потребуется никакого кодирования, в то время как такое кодирование очевидно необходимо для 7-битового SMTP.

Во-вторых, определенные типы среды могут требовать различного транспортного кодирования при разных обстоятельствах. Например, многие PostScript-тела могут целиком состоять из коротких строк 7-битовых кодов, и, следовательно, совсем не требуют кодирования. Другие тела PostScript (в особенности те, что используют механизм двоичного кодирования уровня 2 PostScript) могут быть представлены с использованием двоичного транспортного кодирования. Наконец, так как поле Content-Type ориентировано на то, чтобы предоставлять открытые механизмы спецификации, строгие ассоциации типов среды и кодирования эффективно соединяют спецификацию прикладного протокола с определенным транспортом нижнего уровня. Это нежелательно, так как разработчики типа среды не должны заботиться обо всех видах транспорта и их особенностях.

Кодирование с использованием закавыченных строк печатных символов и кодов base64 устроено так, чтобы позволить взаимные преобразования. Единственная проблема, которая здесь возникает, это обработка принудительных разрывов строк для закавыченных последовательностей печатных символов. При преобразовании закавыченных строк в коды base64 принудительные разрывы строк отображаются последовательностями CRLF. Аналогично, последовательность CRLF в канонической форме данных, полученной после декодирования из base64, должна преобразоваться в принудительный разрыв строки в случае представления текста в виде закавыченной строки печатных символов. Каноническая модель кодирования представлена в документе RFC 2049.

Кодирование Quoted-Printable имеет целью представление данных, состоящих по большей части из октетов, которые соответствуют печатным символам ASCII-набора. Оно преобразует данные таким образом, что результирующие октеты не будут видоизменены при транспортировке почты. Если преобразуемые данные представляют собой ASCII-текст, то после кодирования они сохранят читабельность. Тело, которое целиком состоит из ASCII-кодов, может быть также представлено в виде закавыченной строки печатных символов. При этом сохраняется целостность текста в процессе прохождении через шлюз, который осуществляет трансляцию символов и/или обработку разрывов строк. При этом кодировании октеты должны определяться согласно изложенным ниже правилам:

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

Now's the time for all folk to come to the aid of their country.

Это может быть представлено следующим образом с помощью закавыченных строк печатных символов:

Now's the time =
to the aid of their country.

Это предоставляет механизм, с помощью которого длинные строки преобразуются таким образом, как они должны быть запомнены агентом пользователя. Ограничение в 76 символов не учитывает завершающие строку CRLF, но включают все прочие символы, включая знаки равенства. Так как символ дефис ("-") может отображаться в закавыченных строках самим собой, нужно следить за тем, чтобы при инкапсуляции закодированного так фрагмента, в одном или более составных объектов пограничные разделители не появились в закодированном теле. Хорошей стратегией является выбор в качестве границы последовательности символов "=_", которая не может встретиться в закавыченной строке печатных символов.

Преобразование в закавыченные строки печатных символов представляет собой компромисс между читабельностью и надежностью при транспортировке. Тела, закодированные с помощью закавыченных строк печатных символов, пропускаются без проблем большинством почтовых шлюзов. Проблемы могут возникать только со шлюзами, осуществляющими трансляцию в коды EBCDIC. Кодирование с помощью base64 обеспечивает более высокий уровень надежности. Методом получения разумно высокой надежности транспортировки через шлюзы EBCDIC является представление символов !"#$@[\]^`{|}~ согласно правилу #1.

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

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

Если двоичные данные закодированы в виде закавыченных последовательностей печатных символов, следует позаботиться о том, чтобы символы CR и LF были представлены в виде "=0D" и "=0A", соответственно. В частности, последовательность CRLF в двоичных данных должна кодироваться как "=0D=0A". В противном случае, если CRLF была бы представлена как "жесткий" разрыв строки, она может декодироваться некорректно на платформах с различными способами обработки разрывов строки. С формальной точки зрения, закавыченные последовательности печатных символов подчиняются следующей грамматике.

Добавление LWSP между элементами, показанное в данном BNF-представлении, не допустимо, так как данное BNF не специфицирует структурированных полей заголовка.

Транспортное кодирование на основе Base64 создано для представления произвольной последовательности октетов в форме, которая не обязательно должна быть приемлемой для прочтения человеком. Алгоритмы кодирования и декодирования просты. Это кодирование сходно с тем что используется в почтовом приложении PEM (Privacy Enhanced Mail), как это определено в RFC-1421.

Здесь используется 65-символьный субнабор ASCII, для каждого печатного символа выделено по 6 бит. Дополнительный 65-ый символ "=", используется для обозначения специальных функций обработки.

Этот субнабор имеет важное свойство, которое заключается в том, что он представляется идентично во всех версиях ISO 646, включая US-ASCII, и все символы субнабора имеют аналоги во всех версиях EBCDIC. Другие популярные кодировки, такие как применение утилиты uuencode, Macintosh binhex 4.0 [RFC-1741] и base85, специфицированная как часть уровня 2 PostScript, имеют отличающиеся свойства и, следовательно, не выполняют условий переносимости, которым должна удовлетворять двоичное транспортное кодирование электронной почты.

При кодировании входные 24-битовые группы преобразуют в 4 символа. Входная группа формируется из трех 8-битовых кодов и обрабатывается слева направо. Эти 24 бита рассматриваются в дальнейшем как 4 6-битовые группы, каждая из которых транслируется в одно число из алфавита base64. Когда кодируется битовый поток с использованием base64, предполагается, что старший бит передается первым. То есть, первый бит потока станет старшим битом первого 8-битового байта, а 8-ой бит станет его последним битом.

Каждая 6-битовая группа используется как индекс массива из 64 печатных символов. Символ, на который указывает индекс, берется из массива и помещается в выходной поток. Эти символы представлены в таблице .1., из их перечня исключены коды, имеющие особое значение для протокола SMTP (например, ".", CR, LF), а также разграничитель секций составного сообщения "-" (RFC-2046).

Таблица .1. Коды Base64

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

Если число бит в группе меньше 24, используется специальная обработка. Неполная битовая группа дополняется нулями справа до 24. Заполнение в конце информационной группы осуществляется с использованием символа "=". Так как последовательность кодов base64 представляет собой поток октетов, возможны следующие случаи:

1. последний блок кодируемых данных кратен 24 битам; здесь, завершающий выходной блок будет содержать в себе 4 символа и никакого заполнителя,
2. завершающий блок кодируемых данных содержит ровно 8 бит; здесь, оконечный выходной блок будет содержать два символа, за которыми будут следовать два символа заполнителя, или
3. последний блок кодируемой информации содержит ровно 16 бит; здесь, оконечный блок на выходе будет иметь три символа плюс один символ заполнителя "=".

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

Следует позаботиться о том, чтобы использовались корректные октеты в качестве разделителей строк при работе с base64. В частности, разрывы строк должны быть преобразованы в последовательности CRLF до выполнения кодирования base64.

При создании агента пользователя высокого уровня, может быть желательно, допустить одному телу ссылаться на другое. Тела могут быть помечены с помощью поля заголовка "Content-ID", которое синтаксически идентично полю "Message-ID":

id := "Content-ID" ":" msg-id

Подобно значениям Message-ID, значения Content-ID должны генерироваться уникальными.

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

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

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

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

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

MIME-extension-field := <Любое поле заголовка RFC-822, которое начинается со строки "Content-">

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

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

Поле 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). В данном разделе описаны семь стандартизованных типов среды верхнего уровня.

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

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

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

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

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

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

Каноническая форма любого субтипа 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.

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

Определены следующие значения charset:

Символы с кодами в диапазоне 128-159 не имеют стандартизованных значений в рамках ISO-8859-X. Символы с кодами меньше 128 в ISO-8859-X имеют те же значения, что и в US-ASCII.

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

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

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

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

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

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

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

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

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

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

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

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

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

octet-stream и PostScript.

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

Оба эти параметра являются опционными.

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

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

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

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

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

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

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

Поле 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: 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.

Использование типа среды "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]

encapsulation := delimiter transport-padding CRLF body-part
delimiter := CRLF dash-boundary
close-delimiter := delimiter "--"
>epilogue := discard-text
; Строки части тела не должны начинаться с дефис-границы, а разделитель
; не должен появляться где-либо в теле секции. Заметим, что семантика части тела
; отличается от семантики сообщения, как это описано в тексте.
OCTET := <любое значение октета 0-255 >

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

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

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

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

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

Тип "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 будут относиться к частям внутри объекта.

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

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

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

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

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

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

Тип среды "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.

Субтип "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;

Но в третьем сегменте должно быть специфицировано полное число фрагментов.

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

Заметьте, что нумерация фрагментов начинается с 1, а не 0.

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

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

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

X-Weird-Header-1: Foo
From: Bill@host.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
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-type: audio/basic
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".

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

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

Content-type: message/external-body;

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".

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

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

Кроме того, следующие параметры являются опционными:

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

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

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

Так как почтовые сервера воспринимают разнообразные синтаксисы, некоторые из которых являются многострочными, полная команда, которая должна быть послана почтовому серверу, не включается в качестве параметра с поле заголовка content-type. Вместо этого, она заносится как тело-фантом, когда тип среды соответствует "message/external-body", а тип доступа - mail-server.

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

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

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

Когда используется механизм внешнего тела в сочетании с типом среды "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";

Content-type: application/postscript
Content-ID:
--42
Content-Type: message/external-body; access-type=local-file;

Content-type: application/postscript
Content-ID:

--42
Content-Type: message/external-body;

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

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

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

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

boundary := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
body-part := <"сообщение" как это определено в RFC-822, со всеми опционными полями заголовка, не начинающимися со специфицированных дефис-границ, и без разделителей в пределах тела сообщения. Заметим, что семантика секции отличается от семантики сообщения, как это описано в тексте.>

close-delimiter := delimiter "--"
dash-boundary := "--" boundary

delimiter := CRLF dash-boundary
discard-text := *(*text CRLF); Может игнорироваться или отбрасываться.
encapsulation := delimiter transport-padding CRLF body-part
epilogue := discard-text
multipart-body := [preamble CRLF]

preamble := discard-text
transport-padding := *LWSP-char
; Отправители не должны генерировать транспортных заполнителей не нулевой
; длины, но получатели должны уметь обрабатывать заполнители, добавленные в
; сообщение при транспортировке.

В этом разделе описывается техника кодирования не-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".

'Кодировочное слово' определено согласно следующей ABNF-грамматике. Используется нотация RFC-822, за исключением того, что символы "white space" (HT и SP) не должны появляться между компонентами кодировочного слова.

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

token = 1*
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = 1*<Любой печатный ASCII-символ, отличный от "?" или пробела (SP)>

Слова 'encoding' и 'charset' не зависят от регистра, в котором напечатаны. Таким образом символьный набор с именем "ISO-8859-1" эквивалентен "ISO-8859-1", а кодирование с именем "Q" может записываться как "Q" или "q".

'Кодировочное слово' (encoded-word) не может быть длиннее 75 символов, включая 'charset', 'encoding', 'encoded-text' и разделители. Если желательно закодировать текст больший, чем 75 символов, можно использовать несколько кодировочных слов, разделенных CRLF SP.

Хотя ограничений на длину многострочного поля заголовка, каждая строка поля заголовка, которая содержит одно или более кодировочных слов, ограничена 76 символами.

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

'Кодировочные слова' сконструированы так, чтобы быть узнаваемыми как "атомы" программой грамматического разбора RFC-822. Как следствие, незакодированные символы SP и HT в пределах кодировочных слов запрещены. Например, символьная последовательность

=?iso-8859-1?q?this is some text?=

будет воспринята программой разборки RFC-822 как четыре атома, а не как один атом, или как ''кодировочное слово" (в случае программы разборки, воспринимающей кодировочные слова). Правильный способ закодировать строку "this is some text" - это кодировать и сами пробелы, например:

=?iso-8859-1?q?this=20is=20some=20text?=

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

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

Когда имеется возможность использования более одного символьного набора для представления текста в кодировочном слове и в отсутствии частного соглашения между отправителем и получателем сообщения, рекомендуется, чтобы предпочтительно использовались члены символьного семейства ISO-8859-*.

Первоначально легальными значениями кодирования являются "Q" и "B". Эти кодировки описаны ниже. Кодирование "Q" рекомендуется для использования, когда большинство символов, которые нужно преобразовать, представлены в наборе ASCII; в противном случае, следует использовать "B"-кодирование. Несмортя ни на что программа, читающая почту, которая воспринимает кодировочные слова, должна быть способна обрабатывать любые кодировки для любых символьных наборов, которые она поддерживает.

В кодированном тексте может использоваться только субнабор печатных ASCII-символов. Символы SP и HT не допустимы, чтобы начало и конец кодировочного слова были выделены однозначно. Символ "?" используется в "кодировочном слове" для разделения различных частей этого слова друг от друга. По этой причине "?" не может появляться в секциях "кодировочного слова". Другие символы могут также оказаться нелегальными в определенном контексте. Например, 'encoded-word' во 'фразе', предшествующей адресу в поле заголовка From не может содержать какие-либо специальные символы ("specials"), определенные в RFC-822. Наконец, некоторые другие символы также недопустимы в определенных контекстах, это связано с необходимостью обеспечить надежность пересылки сообщений через почтовые шлюзы.

"B"-кодирование автоматически отвечает этим требованиям. "Q"-кодирование допускает использование широкого перечня печатных символов в некритических позициях заголовка сообщения (например, в Subject), с ограниченным списком символов, допустимых в других полях.

"B"-кодирование идентично "BASE64", описанному RFC-2045.

"Q"-кодирование подобно закавыченным строкам печатных символов ("Quoted-Printable"), описанным в RFC-2045. Оно создано, для того чтобы позволить читать текст, содержащему по большей части ASCII-символы, а алфавитно-цифровом терминале без декодирования.

'encoded-word' может появиться в заголовке сообщения или в заголовке тела секции в соответствии со следующими правилами:

comment = "(" *(ctext | quoted-pair | comment | encoded-word) ")"

"Q"-кодированное 'encoded-word', которое появляется в комментарии не должно содержать символов "(", ")" или ". 'Кодировочное слово', появляющееся в комментарии должно отделяться от смежного 'encoded-word' или 'ctext' с помощью LWS.

Важно заметить, что комментарии распознаются только внутри структурированных полей тела. В полях, чьи тела определены как '*text', "(" и ")" обрабатываются как обычные символы, а не как разделители комментариев, и применимо правило (1) этой секции. (См. RFC-822, секции 3.1.2 и 3.1.3)

В этом случае набор символов, который можно использовать с "Q"-кодированным 'encoded-word' ограничивается до: < ASCII-буква верхнего и нижнего регистров, десятичные цифры, "!", "*", "+", "-", "/", "=" и "_" (ASCII 95.)>. 'Кодировочное слово', которое появляется внутри 'фразы', должно быть отделено от любого смежного 'слова', 'текста' или специального символа ('special') посредством LWS. Это единственные места, где может появиться 'encoded-word'. В частности:

+ 'encoded-word' не должно появляться в любой части 'addr-spec'.
+ 'encoded-word' не должно появляться в пределах 'quoted-string'.
+ 'encoded-word' не должно использоваться в поле заголовка Received.
+ 'encoded-word' не должно использоваться в параметре MIME поля Content-Type или Content-Disposition, или в любом структурированном поле тела, за исключением 'comment' или 'phrase'.

'Кодированный текст' не должен продолжаться от одного 'encoded-word' к другому. Это предполагает, что секция кодированного текста 'B-encoded-word' будет иметь длину кратную 4 символам; для 'Q-encoded-word', за любым символом "=", который появляется в секции кодированного текста, следуют две шестнадцатеричные цифры.

Каждое 'encoded-word' должно кодировать полное число октетов. 'Кодированный текст' в каждом 'encoded-word' должен быть хорошо оформлен согласно специфицированному кодированию. 'Кодированный текст' не может продолжаться в следующем 'encoded-word'. (Например, "=?charset?Q?=?= =?charset?Q?AB?=" было бы нелегальным, так как два шестнадцатеричные числа "AB" должны следовать за "=" в одном и том же 'encoded-word'.)

Каждое 'encoded-word' представлять собой целое число символов. Многооктетные символы не могут расщепляться между смежными 'кодировочными словами'.

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

Использование этих методов для кодирования нетекстовых данных (напр., изображения или голоса) в данном документе не определено. Применение 'кодировочных слов' для представления строк ASCII-символов допустимо, но не рекомендуется.

Программа чтения почты должна осуществлять разбор сообщения и заголовков секций согласно правилам RFC-822, для того чтобы правильно распознать 'кодировочные слова'.

'кодировочные слова' должны распознаваться как:

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

Декодирование и отображение закодированных слов происходит, после того как структурные поля тела будут разобраны на лексемы. Следовательно, возможно спрятать 'специальные' символы в 'кодировочных словах', которые при отображении будут неотличимы от 'специальных' символов окружающего текста. По этой и другим причинам вообще невозможно транслировать заголовок сообщения, содержащий 'кодировочные слова', к виду, который может анализироваться программой чтения почты (RFC-822).

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

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

Если почтовая программа не поддерживает использованный символьный набор, она может отобразить 'кодировочное слово', как обычный текст (т.е., так как оно записано в заголовке), может попробовать отобразить его с использованием имеющегося символьного набора, или выдать сообщение, что текст не может быть отображен.

Если используемый символьный набор реализует технику кодового переключения, отображение кодированного текста начинается в режиме "ASCII". Кроме того, почтовая программа должна проверить, что выходное устройство снова в режиме "ASCII", после того как отображено 'кодировочное слово'.

Возможно, что 'кодировочное слово', которое легально согласно синтаксическим правилам секции 2, не корректно сформировано с точки зрения регламентаций использованного правила кодирования. Например:

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

Программа, формирующая почтовое сообщение и соответствующая данной спецификации, должна гарантировать, что любая строка печатных ASCII-символов, не содержащая HT и SP в пределах '*text' или '*ctext', начинается с "=?" и завершается "?=" является корректным 'кодировочным словом'. ("Начинается" означает: в начале тела сразу после LWS, или сразу после "(" для 'кодировочного слова' в пределах '*ctext'; "завершается" означает: в конце тела, непосредственно перед LWS, или непосредственно перед ")" для 'кодировочного слова' в '*ctext'.) Кроме того, любое 'слово' в 'фразе', которое начинается с "=?" и завершается "?=" должно быть корректным 'кодировочным словом'.

Программа, читающая почтовые сообщения, совместимые с данной спецификацией должна быть способна отделить 'кодировочное слово' от 'text', 'ctext', или 'слов', которые согласуются с правилами секции 6, где бы они не встретились в заголовке сообщения. Она должна поддерживать "B"- и "Q"-кодирование для любых символьных наборов, которые она поддерживает. Программа должна быть способна отобразить не кодированный текст, если символьный набор соответствует "US-ASCII". Для символьных наборов ISO-8859-*, программа должна быть способна, по крайней мере, отобразить символы, которые совпадают с ASCII.

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

From: =?US-ASCII?Q?Keith_Moore?=
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?=
CC: =?ISO-8859-1?Q?Andr=E9?= Pirard
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

В выше приведенном примере в 'кодировочном слове' поля, последний символ "=" в конце кодированного текста необходим, так как каждое 'кодировочное слово' должно быть самодостаточным (символ "=" завершает группу из 4 символов base64 представляющих 2 октета). Дополнительный октет может быть закодирован в первом 'кодировочном слове' (так чтобы 'кодировочное слово' содержало число октетов кратное трем). Второе 'кодировочное слово' использует символьный набор, не совпадающий с тем, что применен в первом слове.

From: =?ISO-8859-1?Q?Olle_J=E4rnefors?=
To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
>Subject: Time for ISO 10646?

To: Dave Crocker
Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
Subject: Re: RFC-HDR care and feeding
From: Nathaniel Borenstein
(=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
To: Greg Vaudreuil , Ned Freed
, Keith Moore
Subject: Test of new header generator
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1

Правила несколько отличаются для полей, определенных как '*text' так как "(" и ")" не распознаются в качестве разделителей комментария. [Секция 5, параграф (1)].

В каждом из следующих примеров, если бы одна и та же последовательность встретилась в поле '*text', форма "Отображается как" не рассматривалась бы как кодировочные слова, а была бы идентична форме "Кодированное представление". Это происходит, потому что каждое из 'кодировочных слов' в ниже приведенных примерах соседствуют с символами "(" или ")".

В пределах 'комментария', HT или SP должны появляться между 'кодировочным словом' и окружающим текстом. [Секция 5, параграф (2)]. Однако HT или SP не нужны между начальным символом "(", который открывает 'комментарий', и 'кодировочным словом'.

HT или SP между смежными 'кодировочными словами' не отображаются.

Даже кратные пробелы между 'кодировочными словами' игнорируются.

Любое число LWS между 'кодировочными словами', даже если там содержится CRLF, за которым следует один или более пробелов, игнорируется.

Для того чтобы пробел был отображен в пределах кодированного текста, SP должен быть закодирован в качестве части 'кодировочного слова'.

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

Современные протоколы Интернет с самого начала создавались таким образом, чтобы их было легко расширить или модернизировать. В частности, MIME [RFC-2045] является открытой системой, допускающей введение новых типов объектов, символьных наборов и методов доступа без изменения базового протокола. Однако необходим процесс регистрации, чтобы гарантировать, что набор таких значений соответствует стандарту и может использоваться в общедоступных сетях.

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

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

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

Для того чтобы увеличить эффективность и гибкость процесса регистрации различные структуры субтипов имен могут быть зарегистрированы так, чтобы удовлетворить различным естественным требованиям, например, субтип, который будет рекомендованa для широкого использования сообществом Интернет или субтип, который используется для переноса файлов, ассоциированных с некоторой частной программой. Последующие субсекции данного документа определяют регистрационные "деревья", отличающиеся использованием стандартной формы имен (например, имен вида "tree.subtree...type"). Заметим, что некоторые типы среды определены до появления данного документа и их имена не согласуются с данной схемой. Смотри приложение A, где рассматривается эта проблема.

Дерево IETF служит для типов, представляющих общий интерес для сообщества Интернет. Регистрация в IETF требует одобрения IESG и публикации данного типа среды в каком-то документе RFC.

Типы среды в IETF-дереве обычно обозначаются именами, которые не оформлены стандартным образом, т.е., не содержат символов точка (".", полный останов).

"Хозяином" регистрации типа среды в рамках дерева IETF предполагается сама группа IETF. Модификации или изменения спецификации требуют той же процедуры, что и регистрация.

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

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

Регистрация в рамках дерева производителя выделяется с помощью префикса имени "vnd.". Далее может следовать имя известного производителя (например, "vnd.lapot"), адрес производителя или место расположения программы, заключительная секция имени может содержать наименование типа среды (например, vnd.bigcompany.funnypictures).

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

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

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

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

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

Типы среды должны функционировать как настоящий формат среды. Регистрация вещей, которые относятся в большей мере к транспортному кодированию, выбору символьного набора не допускается. Например, хотя существуют приложения, которые осуществляют транспортное декодирование base64 [RFC-2045], base64 не может быть зарегистрировано в качестве типа среды. Это требование не зависит от используемого регистрационного дерева.

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

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

Новые субтипы типов верхнего уровня должны соответствовать регламентациям этого уровня. Например, все субтипы типа составных данных должны использовать один и тот же синтаксис инкапсуляции.

В некоторых случаях новый субтип среды может не вполне согласовываться с определенным на текущий момент типом содержимого верхнего уровня. Если такое произошло, следует определить новый тип верхнего уровня, который бы согласовывался с данным субтипом. Такое определение должно быть выполнено согласно стандартной процедуре и опубликовано в RFC. Это требование не зависит от используемого регистрационного дерева.

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

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

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

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

Некоторые типы среды включают в себя патентованные технологии. Регистрация типа среды, включающего в себя патентованные технологии, также разрешена. Однако устанавливаются ограничения (RFC-1602) на применение патентованных технологий в рамках стандартных протоколов.

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

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

Рассмотрение аспектов безопасности необходимо для всех типов, регистрируемых в рамках IETF-дерева. Аналогичный анализ для типов среды регистрируемых в рамках частного дерева или дерева производителя рекомендуется, но не является обязательным. Однако вне зависимости от того что анализ безопасности мог проводиться или нет, все описания соображений по безопасности должны быть выполнены крайне аккуратно вне зависимости от дерева регистрации. В частности, заявление, что "никакие соображения безопасности не сопряжены с этим типом" не следует путать с "безопасность сопряженная с данным типом не анализировалась и не оценивалась".

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

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

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

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

Предложения для типов среды регистрируемых в рамках IETF-дерева должны публиковаться в виде RFC. RFC-публикации типа среды производителя или частного типа среды желательны, но не обязательны. Во всех случаях IANA сохраняет копии всех предложений по типам среды и публикует их как часть самого регистрационного дерева типов среды.

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

Как было обсуждено выше, регистрация типа среды верхнего уровня предполагает стандартную процедуру принятия и, следовательно, обязательную RFC-публикацию.

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

Такая информация часто оказывается весьма полезной и, если имеется, то должна предоставляться.

Следующая процедура была применена IANA для обзора и одобрения новых типов среды. Для регистрации в рамках дерева IETF, нужно следовать обычной процедуре, осуществляя на первом этапе рассылку интернет-проекта. Для регистрации в рамках частного дерева или дерева производителя осуществляется без широкого обсуждения. Проект непосредственно направляется IANA (по адресу iana@iana.org).

Все начинается с посылки предложения регистрации типа среды лист-серверу ietf-types@iana.org . Отклики ожидаются в течение двух недель. Этот подписной лист был учрежден для целей обсуждения предлагаемых типов среды и доступа. Предложенные типы среды, если они формально не зарегистрированы, не могут быть использованы; префикс "x-", специфицированный в RFC-2045, может применяться до тех пор, пока процесс регистрации не завершится.

Типы среды, регистрируемые в рамках дерева IETF должны представляться на одобрение IESG.

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

Комментарии по поводу регистрации типа среды могут быть направлены членам сообщества IANA. Эти комментарии будут переданы "хозяину" типа среды. Комментаторы могут потребовать, чтобы их замечания были присовокуплены к материалам регистрации данного типа среды и, если IANA одобрит это, такая процедура будет произведена.

Материалы регистрации типа среды доступны через анонимный FTP сервер ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ , а все зарегистрированные типы среды будут перечислены в периодически обновляемом документе "Assigned Numbers" RFC [в настоящее время STD-2, RFC-1700]. Описания типа среды и другие материалы могут быть также опубликованы в виде информационных RFC путем посылки документа по адресу "rfc-editor@isi.edu" [RFC-1543].

IANA регистрирует типы среды, принадлежащие дереву IETF. Частные типы и типы среды производителя регистрируются IANA автоматически и без формального обсуждения, если выполнены следующие условия:

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

Изменения следует делать лишь при обнаружении серьезных упущений или ошибок в опубликованной спецификации.

Владелец типа содержимого может передать ответственность за него другому лицу или организации, проинформировав об этом IANA и список рассылки ietf-типов. Это может быть сделано без обсуждения.

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

Регистрации типа среды не могут быть аннулированы. Типы среды, которые не используются более, объявляются устаревшими (OBSOLETE) путем изменения их поля "intended use" (область применения). Такие типы среды будет помечены соответствующим образом и в списках, публикуемых IANA.

To: ietf-types@iana.org
Subject: Registration of MIME media type XXX/YYY(Регистрация типа среды MIME)

RFC-2046 определяет тип среды message/external-body, в рамках которой объект MIME может действовать, как указатель на реальное информационное тело сообщения. Каждый указатель message/external-body специфицирует тип доступа, который определяет механизм получения реального тела сообщения. RFC-2046 определяет исходный набор типов доступа, но допустимо описание нового механизма доступа в процессе регистрации нового типа среды.

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

Каждый тип доступа должен иметь уникальное имя. Это имя появляется в параметре типа доступа в поле заголовка типа содержимого message/external-body, и должно соответствовать синтаксису параметров MIME.

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

Все типы доступа должны быть описаны в RFC. RFC может быть информационным, а не обязательно описанием стандарта.

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

Регистрация нового типа доступа начинается с создания проекта RFC. Далее осуществляется рассылка проекта через список подписки ietf-types@iana.org . Для получения откликов выделяется две недели. Этот подписной лист создан для целей обсуждения предлагаемых типов среды и доступа. Предлагаемые типы доступа не должны применяться до момента формальной регистрации.

Когда двухнедельный период истечет, ответственное лицо, назначенное региональным директором IETF, переадресует запрос iana@isi.edu, или отклоняет его из-за существенных возражений, высказанных в процессе обсуждения.

Решения принятые ответственным лицом IETF рассылаются всем через подписной лист IETF-types всем заинтересованным лицам в пределах двух недель. Это решение может быть обжаловано в IESG.

Утвержденная спецификация типа доступа должна быть опубликована в качестве документа RFC. Информационные RFC публикуются путем посылки их по адресу "rfc-editor@isi.edu".

Зарегистрированные спецификации типа доступа доступны через анонимное FTP на сервере ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/ . Все зарегистрированные типы доступа включаются в перечень типов доступа, периодически публикуемый в документе "Assigned Numbers" RFC-1700.

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

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

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

Каждый тип транспортного кодирования должен иметь уникальное имя. Это имя записывается в поле заголовка Content-Transfer-Encoding и должно согласовываться с его синтаксисом.

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

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

Не существует требования, чтобы транспортное кодирование приводило к определенному выходному формату. Однако выходной формат каждого транспортного кодирования должен быть исчерпывающе документирован. В частности, каждая спецификация должна ясно объявить, являются ли выходные данные 7-битовыми, 8-битовыми или просто двоичными.

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

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

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

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

Регистрационные материалы по всем стандартизованным видам транспортного кодирования доступны через анонимное FTP на сервере ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/ . Все зарегистрированные типы транспортного кодирования обязательно заносятся в списки документа "Assigned Numbers" [RFC-1700].

Далее рассмотрено, какие части MIME должны поддерживаться MIME-совместимой программной реализацией.

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

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

Текст:

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

Применение:

Составное сообщение:

Сообщение:

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

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

В сети Интернет имеется большое число почтовых агентов, которые в процессе реализации протокола SMTP, модифицируют сообщения на пролете. Следующие соображения могут оказаться полезными любому, кто разрабатывает формат данных (тип среды), который бы сохранялся неповрежденным в любых сетевых средах и для любых почтовых агентов. Заметим, что данные, закодированные в base64, удовлетворяют этим требованиям, а некоторые хорошо известные механизмы, в частности утилита UNIX uuencode, не удовлетворяет. Заметим также, что данные, закодированные с использованием закавыченных последовательностей печатных символов, успешно преодолевают большинство почтовых шлюзов, но могут быть повреждены в системах, которые используют символьный набор EBCDIC.

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

Процесс формирования объекта MIME можно смоделировать в виде цепочки последовательных шагов. Заметим, что эти шаги сходны с используемыми в PEM [RFC-1421] и реализуются для каждого "внутреннего" уровня тела сообщения.

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

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

Например, в случае чистого текста, данные должны преобразовываться с использованием поддерживаемого символьного набора, а строки должны завершаться CRLF, как этого требует RFC-822. Заметьте, что ограничения на длины строк, налагаемые RFC-822, игнорируются, если на следующем шаге выполняется кодирование с использованием base64 или закавыченных строк печатных символов.

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

Закодированное тело вкладывается в объект MIME, снабженный соответствующими заголовками. Объект затем вкладывается в объект более высокого уровня, если это требуется.

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

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

Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64

должно быть сначала представлено в форме text/foo, затем, если необходимо, представлено в символьном наборе и, наконец, трансформировано с использованием алгоритма base64 в формат, безопасный для пересылки через любые шлюзы.

Некоторые проблемы вызывают почтовые системы, которые для обозначения перехода на новую строку используют нечто отличное от CRLF, принятого в стандарте RFC-822. Важно отметить, что эти форматы не являются каноническими RFC-822/MIME. Заметим также, что форматы, где вместо последовательности CRLF заносится, например, LF не способны представлять сообщения MIME, содержащие двоичные данные с октетами LF, которые не являются частью последовательности CRLF.

Данное сообщение содержит пять частей, которые должны быть отображены последовательно: - два вводных объекта чистого текста, встроенное составное сообщение, объект типа text/enriched и завершающее инкапсулированное текстовое сообщение с символьным набором не ASCII типа. Встроенное составное сообщение в свою очередь содержит два объекта, которые должны отображаться в параллель, изображение и звуковой фрагмент.

MIME-Version: 1.0
From: Nathaniel Borenstein
To: Ned Freed
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example(составной пример)
Content-Type: multipart/mixed;boundary=unique-boundary-1

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

--unique-boundary-1
... Здесь размещается некоторый текст ...

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

--unique-boundary-1
Content-type: text/plain; charset=US-ASCII

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

--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2
Content-Type: audio/basic

Content-Transfer-Encoding: base64
... здесь размещаются одноканальные аудио данные, полученные при частоте стробирования 8 кГц, представленные с использованием m-преобразования, и закодированные с привлечением base64 ...

--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... здесь размещается изображение, закодированное с привлечением base64 ...
--unique-boundary-2--
--unique-boundary-1
Content-type: text/enriched

This is enriched.
как определено в RFC-1896
Isn't it
cool?
-unique-boundary-1
Content-Type: message/RFC-822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--

Previous: 4.4.14.3 Протокол Интернет для работы с сообщениями IMAP    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет    Next: 4.4.14.5 Программа Sendmail