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

Типы среды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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