Протоколы Internet


Многоцелевое расширение почты Интернет (MIME) - часть 72


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

(1)

отклонить спецификацию, как неприемлемую для стандартизации,

(2)

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

(3)

принять спецификацию, так как она есть, и поместить ее в перечень стандартов.

4.3. Процедуры IANA для регистрации транспортного кодирования

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

4.4. Размещение списка зарегистрированных видов транспортного кодирования

Регистрационные материалы по всем стандартизованным видам транспортного кодирования доступны через анонимное FTP на сервере

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

V. Критерии совместимости и примеры

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

1. Совместимость с MIME

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

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

(1)

Всегда генерировать поле заголовка "MIME-Version: 1.0" в любом формируемом сообщении.

(2)

Распознавать поле заголовка Content-Transfer-Encoding и декодировать все получаемые данные, кодированные в формате закавыченных последовательностей печатных символов или в base64. Должна идентифицироваться также форма преобразования (7-бит, 8-бит или двоичная).

Любые не 7-битовые данные, посланные без кодирования, должны быть соответствующим образом помечены в поле content-transfer-encoding как 8-битовые или двоичные в зависимости от реального формата. Если транспортная система не поддерживает 8-битовый или двоичный формат (как, например, SMTP [RFC-821]), отправитель должен выполнить кодирование и пометить данные, как закодированные в формате base64 или закавыченных последовательностей печатных символов.

(3)

Должен обрабатывать любые нераспознанные транспортные кодирования как тип содержимого "application/octet-stream", вне зависимости от того, распознан или нет действительный тип содержимого.

(4)

Распознавать и интерпретировать поле заголовка Content-Type, и избегать отображения исходных данных со значением поля Content-Type, отличным от text. Реализации должны быть способны посылать, по крайней мере, сообщения text/plain, с символьным набором, специфицированным с помощью параметра charset, если это не US-ASCII.

(5)

Игнорировать любые параметры типа содержимого с не распознанными именами.

(6)

Работать с ниже приведенными значениями типов среды.

<


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