Протокол электронной почты

В нотации 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" означало различные вещи. Существует два приемлемых механизма определения новых субтипов среды.

Сообщения по умолчанию без 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-newencoding". Дополнительные стандартизованные значения 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 =
for all folk to come=
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.10, из их перечня исключены коды, имеющие особое значение для протокола SMTP (например, ".", CR, LF), а также разграничитель секций составного сообщения "-" (RFC-2046).

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

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

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

Типы среды

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

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

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

Поле заголовка Content-Type и механизм типа среды спроектированы так, чтобы сохранить масштабируемость, обеспечивая постепенный рост со временем числа пар тип/субтип и сопряженных с ними параметров. Транспортное кодирование MIME, а также типы доступа message/externalbody со временем могут обрести новые значения. Чтобы гарантировать, что такие значения разработаны и специфицированы корректно, в MIME предусмотрен процесс регистрации, который использует IANA (Internet Assigned Numbers Authority) в качестве главного органа, контролирующего данный процесс (см. RFC 2048). В данном разделе описаны семь стандартизованных типов среды верхнего уровня.

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

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

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

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

Тип среды Text

Тип среды 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-битовые без модификаций, связанных c <shift> или <escape>.

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

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

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

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

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

Тип среды Image

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

Тип среды Audio

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

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

Тип среды Video

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

Тип среды Application

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

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

Тип среды Multipart

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

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

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

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

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

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

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

Поле 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]
dash-boundary transport-padding
CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
transport-padding := *LWSP-char ; Отправители не должны генерировать
; транспортные заполнители ненулевой
; длины, но получатели должны уметь
; обрабатывать заполнители, введенные
; при транспортировке.
encapsulation := delimiter transport-padding CRLF body-part
delimiter := CRLF dash-boundary
close-delimiter := delimiter "--"
epilogue := discard-text
; Строки части тела не должны начинаться с дефис-границы, а разделитель
; не должен появляться где-либо в теле секции. Заметим, что семантика части
; тела отличается от семантики сообщения, как это описано в тексте.
OCTET := <любое значение октета 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="---- main boundary ----"
------ main boundary ----
...Вводный текст или содержимое таблицы...
------ main boundary ----
Content-Type: multipart/digest;
boundary="---- next message ----"
------ next message ----
From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion
... здесь размещается тело...
------ next message ----
From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion
... здесь размещается следующее тело ...
------ next message ------
------ main boundary ------

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

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

Тип среды Message

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

Content-Type: Message/Partial; number=2; total=3;
Id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Content-Type: Message/Partial;
Id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2

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

Content-Type: Message/Partial; number=3; total=3;
Id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Заметьте, что нумерация фрагментов начинается с 1, а не c 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;
access-type=local-file;
name="/u/nsb/Me.jpeg"
Content-type: image/jpeg
Content-ID:
Content-Transfer-Encoding: binary
Это в действительности не тело!

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

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

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

Как с message/partial, объекты MIME типа message/external-body имеют транспортное кодирование 7-бит (по умолчанию). В частности, даже в среде, которая поддерживает 8-битовую транспортировку, использование транспортного кодирования 8bit или binary категорически запрещено для объектов типа message/external-body.

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

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

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

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

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

Тип доступа mail-server

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

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

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

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