О документе
Рабочая группа сети N. Freed
Запрос комментариев: 4289 Sun Microsystems
BCP: 13 J. Klensin
Заменяет: 2048 Декабрь 2005
Категория: Лучшая современная практика
Многоцелевые расширения почты Интернета (MIME), часть четвёртая:
Процедуры регистрации
1. Введение
Новейшие интернет-протоколы были тщательно разработаны так, чтобы в
определённых областях их было легко расширять. В частности, MIME
[RFC2045] является открытой структурой и может поддерживать
дополнительные типы объектов, наборы символов и методы доступа без
каких-либо изменений базового протокола. Однако необходим процесс
регистрации, чтобы обеспечить упорядоченное, чётко определённое и
публичное формирование набора таких значений.
Этот документ определяет процедуры регистрации, использующие Internet
Assigned Numbers Authority (IANA) в качестве центрального реестра этих
значений.
Примечание:
Регистрация типов носителей и наборов символов для использования в
MIME определяется отдельными документами [RFC4288] [RFC2978] и здесь
не рассматривается.
1.1. Соглашения, используемые в этом документе
Ключевые слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT»,
«SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY» и «OPTIONAL» в этом
документе должны интерпретироваться, как описано в [RFC2119].
2. Типы доступа к внешнему телу
[RFC2046] определяет тип носителя message/external-body, при котором
сущность MIME может выступать указателем на фактические данные тела
вместо непосредственного включения данных в тело сущности. Каждая
ссылка message/external-body определяет тип доступа, который задаёт
механизм, используемый для получения фактических данных тела. RFC 2046
определяет начальный набор типов доступа, но допускает регистрацию
дополнительных типов доступа для поддержки новых механизмов получения.
2.1. Требования к регистрации
Спецификации новых типов доступа ДОЛЖНЫ (MUST) соответствовать
требованиям, описанным ниже.
2.1.1. Требования к именованию
Каждый тип доступа ДОЛЖЕН (MUST) иметь уникальное имя. Это имя
указывается в параметре access-type поля заголовка content-type
message/external-body и ДОЛЖНО (MUST) соответствовать синтаксису
параметров типа содержимого MIME.
2.1.2. Требования к спецификации механизма
Все протоколы, транспорты и процедуры, используемые данным типом
доступа, ДОЛЖНЫ (MUST) быть описаны либо в самой спецификации типа
доступа, либо в некоторой другой общедоступной спецификации с
достаточной подробностью, чтобы тип доступа мог быть реализован любым
компетентным разработчиком. Использование секретных и/или
проприетарных методов в типах доступа прямо запрещено. Также необходимо
соблюдать ограничения, налагаемые [RFC2026] на стандартизацию
запатентованных алгоритмов.
2.1.3. Требования к публикации
Все типы доступа ДОЛЖНЫ (MUST) быть описаны в RFC. RFC может быть
информационным, а не относящимся к треку стандартов, хотя для всех
типов доступа рекомендуется проверка и одобрение в рамках трека
стандартов.
2.1.4. Требования безопасности
Любые известные проблемы безопасности, возникающие при использовании
типа доступа, ДОЛЖНЫ (MUST) быть описаны полностью и исчерпывающе. Не
требуется, чтобы тип доступа был безопасным или не содержал рисков, но
требуется, чтобы известные риски были идентифицированы. Публикация
нового типа доступа не требует исчерпывающей проверки безопасности, и
раздел соображений безопасности подлежит непрерывной оценке.
Дополнительные соображения безопасности СЛЕДУЕТ (SHOULD) рассматривать
путём публикации пересмотренных версий спецификации типа доступа.
2.2. Процедура регистрации
Регистрация нового типа доступа начинается с публикации спецификации в
качестве Internet Draft.
2.2.1. Представление типа доступа сообществу
Предлагаемая спецификация типа доступа направляется в список рассылки
«ietf-types@iana.org» для двухнедельного периода рассмотрения. Этот
список рассылки был создан с целью рассмотрения предлагаемых типов
доступа и типов носителей. Предлагаемые типы доступа формально не
регистрируются и не должны использоваться.
Цель публичного размещения состоит в получении комментариев и обратной
связи по спецификации типа доступа, а также в рассмотрении любых
соображений безопасности.
2.2.2. Рецензент типов доступа
По истечении двухнедельного периода рецензент типов доступа, назначаемый
директором (директорами) области приложений IETF, либо пересылает запрос
в iana@iana.org, либо отклоняет его из-за существенных возражений,
высказанных в списке.
Решения, принятые рецензентом, должны быть опубликованы в списке
рассылки ietf-types в течение 14 дней. Решения, принятые рецензентом,
могут быть обжалованы в IESG, как указано в [RFC2026].
2.2.3. Регистрация IANA
При условии, что тип доступа либо прошёл рассмотрение, либо его
апелляция в IESG была успешно удовлетворена, IANA зарегистрирует тип
доступа и сделает регистрацию доступной сообществу. Спецификация типа
доступа также должна быть опубликована как RFC.
2.3. Местонахождение списка зарегистрированных типов доступа
Регистрации типов доступа перечислены IANA на следующей веб-странице:
http://www.iana.org/assignments/access-types
2.4. Процедуры IANA для регистрации типов доступа
Личность рецензента типов доступа сообщается IANA со стороны IESG.
Затем IANA действует только либо в ответ на определения типов доступа,
одобренные рецензентом типов доступа и направленные в IANA для
регистрации, либо в ответ на сообщение от IESG о том, что апелляция по
определению типа доступа отменила решение рецензента типов доступа.
3. Кодировки передачи
Кодировки передачи — это преобразования, применяемые к типам носителей
MIME после преобразования в каноническую форму типа носителя. Кодировки
передачи используются для нескольких целей:
o Многие транспорты, особенно транспорты сообщений, могут обрабатывать
только данные, состоящие из сравнительно коротких текстовых строк.
Могут существовать серьёзные ограничения на то, какие символы можно
использовать в этих текстовых строках. Некоторые транспорты
ограничены небольшим подмножеством US-ASCII, а другие не могут
обрабатывать определённые последовательности символов. Кодировки
передачи используются для преобразования двоичных данных в текстовую
форму, способную пройти через такие транспорты. Примеры такого рода
кодировок передачи включают кодировки передачи base64 и
quoted-printable, определённые в [RFC2045].
o Сущности изображений, аудио, видео и даже приложений иногда имеют
весьма большой размер. Алгоритмы сжатия часто эффективны для
уменьшения размера больших сущностей. Кодировки передачи могут
использоваться для применения к сущностям MIME универсальных
алгоритмов сжатия без потерь.
o Транспортные кодировки могут определяться как средство представления
существующих форматов кодирования в контексте MIME.
ВАЖНО: Стандартизация большого числа различных кодировок передачи
рассматривается как существенное препятствие для широкомасштабной
совместимости и прямо не поощряется. Тем не менее следующая процедура
определена для предоставления средства определения дополнительных
кодировок передачи, если стандартизация действительно оправдана.
3.1. Требования к кодировке передачи
Спецификации кодировок передачи ДОЛЖНЫ (MUST) соответствовать
требованиям, описанным ниже.
3.1.1. Требования к именованию
Каждая кодировка передачи ДОЛЖНА (MUST) иметь уникальное имя. Это имя
указывается в поле заголовка Content-Transfer-Encoding и ДОЛЖНО (MUST)
соответствовать синтаксису этого поля.
3.1.2. Требования к спецификации алгоритма
Все алгоритмы, используемые в кодировке передачи (например,
преобразование в печатную форму, сжатие), ДОЛЖНЫ (MUST) быть полностью
описаны в спецификации кодировки передачи. Использование секретных
и/или проприетарных алгоритмов в стандартизированных кодировках
передачи прямо запрещено. Также ДОЛЖНЫ (MUST) соблюдаться ограничения,
налагаемые [RFC2026] на стандартизацию запатентованных алгоритмов.
3.1.3. Требования к входной области
Все кодировки передачи ДОЛЖНЫ (MUST) быть применимы к произвольной
последовательности октетов любой длины. Зависимость от конкретных форм
входных данных не допускается.
Следует отметить, что кодировки 7bit и 8bit не соответствуют этому
требованию. Помимо нежелательности наличия специализированных кодировок,
намерение здесь состоит в том, чтобы запретить добавление дополнительных
кодировок, аналогичных 7bit и 8bit либо избыточных по отношению к ним.
3.1.4. Требования к диапазону вывода
Не существует требования, чтобы конкретная кодировка передачи давала
конкретную форму закодированного вывода. Однако формат вывода для каждой
кодировки передачи ДОЛЖЕН (MUST) быть полностью и исчерпывающе
документирован. В частности, каждая спецификация ДОЛЖНА (MUST) ясно
указывать, всегда ли формат вывода находится в пределах 7bit или 8bit,
либо представляет собой просто чистые двоичные данные.
3.1.5. Требования к целостности и универсальности данных
Все кодировки передачи ДОЛЖНЫ (MUST) быть полностью обратимы на любой
платформе; ДОЛЖНА (MUST) существовать возможность для любого восстановить
исходные данные, выполнив соответствующую операцию декодирования.
Обратите внимание, что это требование фактически исключает использование
в качестве кодировки передачи всех форм сжатия с потерями, а также всех
форм шифрования.
3.1.6. Требования к новой функциональности
Все кодировки передачи ДОЛЖНЫ (MUST) предоставлять некоторый вид новой
функциональности. Допустима некоторая степень перекрытия функциональности
с ранее определёнными кодировками передачи, но любая новая кодировка
передачи ДОЛЖНА (MUST) также предлагать нечто, чего не предоставляет
никакая другая кодировка передачи.
3.1.7. Требования безопасности
В максимально возможной степени кодировки передачи НЕ СЛЕДУЕТ (SHOULD
NOT) содержать известные проблемы безопасности. Независимо от этого,
любые известные проблемы безопасности, возникающие при использовании
кодировки передачи, ДОЛЖНЫ (MUST) быть описаны полностью и исчерпывающе.
Если после первоначальной публикации и регистрации выявляются
дополнительные проблемы безопасности, их СЛЕДУЕТ (SHOULD) рассматривать
путём публикации пересмотренных версий спецификации кодировки передачи.
3.2. Процедура определения кодировки передачи
Определение нового кодирования передачи начинается с публикации
спецификации в качестве Internet Draft. Черновик ДОЛЖЕН (MUST) точно и
полностью определять кодирование передачи, а также ДОЛЖЕН (MUST) приводить
существенное обоснование для определения и стандартизации нового кодирования
передачи. Затем эту спецификацию ДОЛЖНЫ (MUST) представить IESG для
рассмотрения. IESG может:
o отклонить спецификацию сразу как непригодную для
стандартизации;
o передать спецификацию существующей рабочей группе IETF для
дальнейшей работы;
o одобрить создание рабочей группы IETF для работы над
спецификацией в соответствии с процедурами IETF; или
o принять спецификацию в её текущем виде для обработки как
индивидуальную подачу по стандартному направлению.
Спецификации кодирования передачи на стандартном направлении следуют обычным
правилам IETF для документов стандартного направления. Кодирование передачи
считается определённым и доступным для использования, как только оно находится
на стандартном направлении.
3.3. Процедуры IANA для регистрации кодирования передачи
Нет необходимости в специальной процедуре регистрации кодирований передачи в
IANA. Все законные регистрации кодирования передачи ДОЛЖНЫ (MUST) оформляться
как RFC стандартного направления, поэтому IESG отвечает за уведомление IANA об
одобрении нового кодирования передачи.
3.4. Местонахождение списка зарегистрированных кодирований передачи
Список регистраций кодирования передачи можно найти по адресу:
http://www.iana.org/assignments/transfer-encodings
4. Вопросы безопасности
Требования безопасности для типов доступа рассматриваются в разделе 2.1.4.
Требования безопасности для кодирований передачи рассматриваются в разделе
3.1.7.
5. Вопросы IANA
Единственная цель этого документа — определить реестры IANA для типов доступа
и кодирований передачи. Процедуры IANA для этих реестров определены
соответственно в разделе 2.4 и разделе 3.3.
6. Благодарности
Текущие авторы хотели бы выразить свою признательность покойному д-ру Jon
Postel, чья общая модель процедур регистрации IANA и конкретный вклад
сформировали предшественников этого документа [RFC2048]. Мы надеемся, что
текущая версия была бы той, с которой он согласился бы, но, поскольку проверить
такое согласие невозможно, мы с сожалением удалили его имя из числа соавторов.
7.1. Нормативные ссылки
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
7.2. Информационные ссылки
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
Приложение A. Изменения со времени RFC 2048
o Процедуры регистрации типов носителей теперь описаны в отдельном
документе [RFC4288].
o Различные URL и адреса в этом документе были изменены, чтобы все
они ссылались на iana.org, а не на isi.edu. Кроме того, многие URL
были изменены на использование HTTP; ранее они использовали FTP.
o Значительная часть документа была уточнена с учётом
эксплуатационного опыта применения этих процедур.
o Несколько ссылок в этом документе были обновлены так, чтобы они
ссылались на текущие версии соответствующих спецификаций.
o В список возможных действий, которые IESG может предпринять,
была добавлена возможность поручить существующей рабочей группе
задачу работы над новым кодированием передачи.
o Были добавлены разделы вопросов безопасности и вопросов IANA.
o Регистрация наборов символов для использования в MIME определена
в [RFC2978] и более не рассматривается в этом документе.