RFC4289 — Многоцелевые расширения электронной почты Интернета (MIME). Часть четвёртая: процедуры регистрации

Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures

Выжимка

RFC 4289 устанавливает процедуры IANA для регистрации типов доступа внешнего тела MIME и кодировок передачи содержимого. Для новых типов доступа требуются уникальное имя, полное общедоступное описание, публикация спецификации в RFC, описание известных рисков безопасности и рассмотрение через список рассылки ietf-types. Новые кодировки передачи должны быть точно определены, применимы к произвольным последовательностям октетов, полностью обратимы и давать новую функциональность; их стандартизация проходит через IESG и документы RFC на стандартизируемом пути. Документ имеет статус Best Current Practice, входит в BCP 13 и заменяет RFC 2048.

Полный перевод

Рабочая группа сети                                           N. Freed
Запрос комментариев: 4289                              Sun Microsystems
BCP: 13                                                       J. Klensin
Заменяет: 2048                                            Декабрь 2005
Категория: Лучшая современная практика


        Многоцелевые расширения почты Интернета (MIME), часть четвёртая:
                           Процедуры регистрации

Статус этого меморандума

   Этот документ определяет лучшую современную практику Интернета для
   интернет-сообщества и запрашивает обсуждение и предложения по
   улучшениям. Распространение этого меморандума не ограничено.

Уведомление об авторских правах

   Copyright (C) The Internet Society (2005).

Аннотация

   Этот документ определяет процедуры регистрации IANA для MIME
   типов доступа к внешнему телу и кодировок передачи содержимого.
















Freed & Klensin          Лучшая современная практика             [Страница 1]

RFC 4289                   Регистрация MIME                 Декабрь 2005


Содержание

   1. Введение .......................................................2
   2. Типы доступа к внешнему телу ...................................3
      2.1. Требования к регистрации ..................................3
         2.1.1. Требования к именованию ..............................3
         2.1.2. Требования к спецификации механизма .................3
         2.1.3. Требования к публикации ..............................4
         2.1.4. Требования безопасности ..............................4
      2.2. Процедура регистрации .....................................4
         2.2.1. Представление типа доступа сообществу ...............4
         2.2.2. Рецензент типов доступа .............................4
         2.2.3. Регистрация IANA ....................................5
      2.3. Местонахождение списка зарегистрированных типов доступа ..5
      2.4. Процедуры IANA для регистрации типов доступа .............5
   3. Кодировки передачи .............................................5
      3.1. Требования к кодировке передачи ..........................6
         3.1.1. Требования к именованию .............................6
         3.1.2. Требования к спецификации алгоритма .................6
         3.1.3. Требования к входной области ........................6
         3.1.4. Требования к диапазону вывода .......................6
         3.1.5. Требования к целостности и универсальности данных ...7
         3.1.6. Требования к новой функциональности .................7
         3.1.7. Требования безопасности .............................7
      3.2. Процедура определения кодировки передачи .................7
      3.3. Процедуры IANA для регистрации кодировки передачи ........8
      3.4. Местонахождение списка зарегистрированных кодировок передачи
                                                                  ....8
   4. Соображения безопасности .......................................8
   5. Соображения IANA ...............................................8
   6. Благодарности ..................................................8
   7. Ссылки .........................................................9
   A.  Изменения после RFC 2048 ......................................9

1.  Введение

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

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





Freed & Klensin          Лучшая современная практика             [Страница 2]

RFC 4289                   Регистрация MIME                 Декабрь 2005


   Примечание:

      Регистрация типов носителей и наборов символов для использования в
      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] на стандартизацию
   запатентованных алгоритмов.






Freed & Klensin          Лучшая современная практика             [Страница 3]

RFC 4289                   Регистрация MIME                 Декабрь 2005


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






Freed & Klensin          Лучшая современная практика             [Страница 4]

RFC 4289                   Регистрация MIME                 Декабрь 2005


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.



Freed & Klensin          Лучшая современная практика             [Страница 5]

RFC 4289                   Регистрация MIME                 Декабрь 2005


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

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,
   либо представляет собой просто чистые двоичные данные.



Freed & Klensin          Лучшая современная практика             [Страница 6]

RFC 4289                   Регистрация MIME                 Декабрь 2005


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



Freed & Klensin          Best Current Practice                  [Страница 7]

RFC 4289                   MIME Registration               Декабрь 2005


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

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













Freed & Klensin          Best Current Practice                  [Страница 8]

RFC 4289                   MIME Registration               Декабрь 2005


7.  Ссылки

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.


















Freed & Klensin          Best Current Practice                  [Страница 9]

RFC 4289                   MIME Registration               Декабрь 2005


Приложение A.  Изменения со времени RFC 2048

   o  Процедуры регистрации типов носителей теперь описаны в отдельном
      документе [RFC4288].

   o  Различные URL и адреса в этом документе были изменены, чтобы все
      они ссылались на iana.org, а не на isi.edu. Кроме того, многие URL
      были изменены на использование HTTP; ранее они использовали FTP.

   o  Значительная часть документа была уточнена с учётом
      эксплуатационного опыта применения этих процедур.

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

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

   o  Были добавлены разделы вопросов безопасности и вопросов IANA.

   o  Регистрация наборов символов для использования в MIME определена
      в [RFC2978] и более не рассматривается в этом документе.

Адреса авторов

   Ned Freed
   Sun Microsystems
   3401 Centrelake Drive, Suite 410
   Ontario, CA  92761-1205
   USA

   Телефон: +1 909 457 4293
   EMail: ned.freed@mrochek.com


   John C. Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140

   EMail: klensin+ietf@jck.com










Freed & Klensin          Best Current Practice                 [Страница 10]

RFC 4289                   MIME Registration               Декабрь 2005


Полное заявление об авторских правах

   Copyright (C) The Internet Society (2005).

   Этот документ подлежит правам, лицензиям и ограничениям, содержащимся в
BCP 78, и, за исключением предусмотренного в нём, авторы сохраняют все свои
права.

   Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ КОТОРАЯ
ЕГО/ЕЁ СПОНСИРУЕТ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY И THE INTERNET
ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ
ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, В ЧАСТНОСТИ, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, И ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ
ЦЕЛИ.

Интеллектуальная собственность

   IETF не занимает позиции относительно действительности или объёма каких-либо
прав интеллектуальной собственности либо иных прав, которые могут заявляться
как относящиеся к реализации или использованию технологии, описанной в этом
документе, или относительно того, может или не может быть доступна какая-либо
лицензия по таким правам; также IETF не заявляет, что предпринимала
какие-либо независимые усилия для выявления таких прав. Информацию о процедурах
в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

   Копии раскрытий IPR, сделанных Секретариату IETF, и любых заверений о
лицензиях, которые будут предоставлены, либо результат попытки получить общую
лицензию или разрешение на использование таких имущественных прав
реализаторами или пользователями этой спецификации можно получить из
онлайнового репозитория IPR IETF по адресу
http://www.ietf.org/ipr.

   IETF приглашает любую заинтересованную сторону довести до её сведения любые
авторские права, патенты или патентные заявки либо иные имущественные права,
которые могут охватывать технологию, которая может потребоваться для реализации
этого стандарта. Пожалуйста, направляйте эту информацию в IETF по адресу ietf-
ipr@ietf.org.

Благодарность

   Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.






Freed & Klensin          Best Current Practice                 [Страница 11]
Оригинал (EN)





Network Working Group                                           N. Freed
Request for Comments: 4289                              Sun Microsystems
BCP: 13                                                       J. Klensin
Obsoletes: 2048                                            December 2005
Category: Best Current Practice


        Multipurpose Internet Mail Extensions (MIME) Part Four:
                        Registration Procedures

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document specifies IANA registration procedures for MIME
   external body access types and content-transfer-encodings.



























Freed & Klensin          Best Current Practice                  [Page 1]

RFC 4289                   MIME Registration               December 2005


Table of Contents

   1. Introduction ....................................................2
   2. External Body Access Types ......................................3
      2.1. Registration Requirements ..................................3
         2.1.1. Naming Requirements ...................................3
         2.1.2. Mechanism Specification Requirements ..................3
         2.1.3. Publication Requirements ..............................4
         2.1.4. Security Requirements .................................4
      2.2. Registration Procedure .....................................4
         2.2.1. Present the Access Type to the Community ..............4
         2.2.2. Access Type Reviewer ..................................4
         2.2.3. IANA Registration .....................................5
      2.3. Location of Registered Access Type List ....................5
      2.4. IANA Procedures for Registering Access Types ...............5
   3. Transfer Encodings ..............................................5
      3.1. Transfer Encoding Requirements .............................6
         3.1.1. Naming Requirements ...................................6
         3.1.2. Algorithm Specification Requirements ..................6
         3.1.3. Input Domain Requirements .............................6
         3.1.4. Output Range Requirements .............................6
         3.1.5. Data Integrity and Generality Requirements ............7
         3.1.6. New Functionality Requirements ........................7
         3.1.7. Security Requirements .................................7
      3.2. Transfer Encoding Definition Procedure .....................7
      3.3. IANA Procedures for Transfer Encoding Registration .........8
      3.4. Location of Registered Transfer Encodings List .............8
   4. Security Considerations .........................................8
   5. IANA Considerations .............................................8
   6. Acknowledgements ................................................8
   7. References ......................................................9
   A.  Changes Since RFC 2048 .........................................9

1.  Introduction

   Recent Internet protocols have been carefully designed to be easily
   extensible in certain areas.  In particular, MIME [RFC2045] is an
   open-ended framework and can accommodate additional object types,
   charsets, and access methods without any changes to the basic
   protocol.  A registration process is needed, however, to ensure that
   the set of such values is developed in an orderly, well-specified,
   and public manner.

   This document defines registration procedures that use the Internet
   Assigned Numbers Authority (IANA) as a central registry for these
   values.





Freed & Klensin          Best Current Practice                  [Page 2]

RFC 4289                   MIME Registration               December 2005


   Note:

      Registration of media types and charsets for use in MIME are
      specified in separate documents [RFC4288] [RFC2978] and are not
      addressed here.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  External Body Access Types

   [RFC2046] defines the message/external-body media type, whereby a
   MIME entity can act as pointer to the actual body data in lieu of
   including the data directly in the entity body.  Each
   message/external-body reference specifies an access type, which
   determines the mechanism used to retrieve the actual body data.  RFC
   2046 defines an initial set of access types but allows for the
   registration of additional access types to accommodate new retrieval
   mechanisms.

2.1.  Registration Requirements

   New access type specifications MUST conform to the requirements
   described below.

2.1.1.  Naming Requirements

   Each access type MUST have a unique name.  This name appears in the
   access-type parameter in the message/external-body content-type
   header field and MUST conform to MIME content type parameter syntax.

2.1.2.  Mechanism Specification Requirements

   All of the protocols, transports, and procedures used by a given
   access type MUST be described, either in the specification of the
   access type itself or in some other publicly available specification,
   in sufficient detail for the access type to be implemented by any
   competent implementor.  Use of secret and/or proprietary methods in
   access types is expressly prohibited.  The restrictions imposed by
   [RFC2026] on the standardization of patented algorithms must be
   respected as well.







Freed & Klensin          Best Current Practice                  [Page 3]

RFC 4289                   MIME Registration               December 2005


2.1.3.  Publication Requirements

   All access types MUST be described by an RFC.  The RFC may be
   informational rather than standards-track, although standards-track
   review and approval are encouraged for all access types.

2.1.4.  Security Requirements

   Any known security issues that arise from the use of the access type
   MUST be completely and fully described.  It is not required that the
   access type be secure or that it be free from risks, but it is
   required that the known risks be identified.  Publication of a new
   access type does not require an exhaustive security review, and the
   security considerations section is subject to continuing evaluation.
   Additional security considerations SHOULD be addressed by publishing
   revised versions of the access type specification.

2.2.  Registration Procedure

   Registration of a new access type starts with the publication of the
   specification as an Internet Draft.

2.2.1.  Present the Access Type to the Community

   A proposed access type specification is sent to the
   "ietf-types@iana.org" mailing list for a two-week review period.
   This mailing list has been established for the purpose of reviewing
   proposed access and media types.  Proposed access types are not
   formally registered and must not be used.

   The intent of the public posting is to solicit comments and feedback
   on the access type specification and a review of any security
   considerations.

2.2.2.  Access Type Reviewer

   When the two-week period has passed, the access type reviewer, who is
   appointed by the IETF Applications Area Director(s), either forwards
   the request to iana@iana.org or rejects it because of significant
   objections raised on the list.

   Decisions made by the reviewer must be posted to the ietf-types
   mailing list within 14 days.  Decisions made by the reviewer may be
   appealed to the IESG as specified in [RFC2026].







Freed & Klensin          Best Current Practice                  [Page 4]

RFC 4289                   MIME Registration               December 2005


2.2.3.  IANA Registration

   Provided that the access type either has passed review or has been
   successfully appealed to the IESG, the IANA will register the access
   type and make the registration available to the community.  The
   specification of the access type must also be published as an RFC.

2.3.  Location of Registered Access Type List

   Access type registrations are listed by the IANA on the following web
   page:

     http://www.iana.org/assignments/access-types

2.4.  IANA Procedures for Registering Access Types

   The identity of the access type reviewer is communicated to the IANA
   by the IESG.  The IANA then only acts either in response to access
   type definitions that are approved by the access type reviewer and
   forwarded to the IANA for registration, or in response to a
   communication from the IESG that an access type definition appeal has
   overturned the access type reviewer's ruling.

3.  Transfer Encodings

   Transfer encodings are transformations applied to MIME media types
   after conversion to the media type's canonical form.  Transfer
   encodings are used for several purposes:

   o  Many transports, especially message transports, can only handle
      data consisting of relatively short lines of text.  There can be
      severe restrictions on what characters can be used in these lines
      of text.  Some transports are restricted to a small subset of US-
      ASCII, and others cannot handle certain character sequences.
      Transfer encodings are used to transform binary data into a
      textual form that can survive such transports.  Examples of this
      sort of transfer encoding include the base64 and quoted-printable
      transfer encodings defined in [RFC2045].

   o  Image, audio, video, and even application entities are sometimes
      quite large.  Compression algorithms are often effective in
      reducing the size of large entities.  Transfer encodings can be
      used to apply general-purpose non-lossy compression algorithms to
      MIME entities.

   o  Transport encodings can be defined as a means of representing
      existing encoding formats in a MIME context.




Freed & Klensin          Best Current Practice                  [Page 5]

RFC 4289                   MIME Registration               December 2005


   IMPORTANT:  The standardization of a large number of different
   transfer encodings is seen as a significant barrier to widespread
   interoperability and is expressly discouraged.  Nevertheless, the
   following procedure has been defined in order to provide a means of
   defining additional transfer encodings, should standardization
   actually be justified.

3.1.  Transfer Encoding Requirements

   Transfer encoding specifications MUST conform to the requirements
   described below.

3.1.1.  Naming Requirements

   Each transfer encoding MUST have a unique name.  This name appears in
   the Content-Transfer-Encoding header field and MUST conform to the
   syntax of that field.

3.1.2.  Algorithm Specification Requirements

   All of the algorithms used in a transfer encoding (e.g., conversion
   to printable form, compression) MUST be described in their entirety
   in the transfer encoding specification.  Use of secret and/or

   proprietary algorithms in standardized transfer encodings is
   expressly prohibited.  The restrictions imposed by [RFC2026] on the
   standardization of patented algorithms MUST be respected as well.

3.1.3.  Input Domain Requirements

   All transfer encodings MUST be applicable to an arbitrary sequence of
   octets of any length.  Dependence on particular input forms is not
   allowed.

   It should be noted that the 7bit and 8bit encodings do not conform to
   this requirement.  Aside from the undesirability of having
   specialized encodings, the intent here is to forbid the addition of
   additional encodings similar to, or redundant with, 7bit and 8bit.

3.1.4.  Output Range Requirements

   There is no requirement that a particular transfer encoding produce a
   particular form of encoded output.  However, the output format for
   each transfer encoding MUST be fully and completely documented.  In
   particular, each specification MUST clearly state whether the output
   format always lies within the confines of 7bit or 8bit or is simply
   pure binary data.




Freed & Klensin          Best Current Practice                  [Page 6]

RFC 4289                   MIME Registration               December 2005


3.1.5.  Data Integrity and Generality Requirements

   All transfer encodings MUST be fully invertible on any platform; it
   MUST be possible for anyone to recover the original data by
   performing the corresponding decoding operation.  Note that this
   requirement effectively excludes all forms of lossy compression as
   well as all forms of encryption from use as a transfer encoding.

3.1.6.  New Functionality Requirements

   All transfer encodings MUST provide some sort of new functionality.
   Some degree of functionality overlap with previously defined transfer
   encodings is acceptable, but any new transfer encoding MUST also
   offer something no other transfer encoding provides.

3.1.7.  Security Requirements

   To the greatest extent possible, transfer encodings SHOULD NOT
   contain known security issues.  Regardless, any known security issues
   that arise from the use of the transfer encoding MUST be completely
   and fully described.  If additional security issues come to light
   after initial publication and registration, they SHOULD be addressed
   by publishing revised versions of the transfer encoding
   specification.

3.2.  Transfer Encoding Definition Procedure

   Definition of a new transfer encoding starts with the publication of
   the specification as an Internet Draft.  The draft MUST define the
   transfer encoding precisely and completely, and it MUST also provide
   substantial justification for defining and standardizing a new
   transfer encoding.  This specification MUST then be presented to the
   IESG for consideration.  The IESG can:

   o  reject the specification outright as being inappropriate for
      standardization,

   o  assign the specification to an existing IETF working group for
      further work,

   o  approve the formation of an IETF working group to work on the
      specification in accordance with IETF procedures, or

   o  accept the specification as-is for processing as an individual
      standards-track submission.

   Transfer encoding specifications on the standards track follow normal
   IETF rules for standards-track documents.  A transfer encoding is



Freed & Klensin          Best Current Practice                  [Page 7]

RFC 4289                   MIME Registration               December 2005


   considered to be defined and available for use once it is on the
   standards track.

3.3.  IANA Procedures for Transfer Encoding Registration

   There is no need for a special procedure for registering Transfer
   Encodings with the IANA.  All legitimate transfer encoding
   registrations MUST appear as a standards-track RFC, so it is the
   IESG's responsibility to notify the IANA when a new transfer encoding
   has been approved.

3.4.  Location of Registered Transfer Encodings List

   The list of transfer encoding registrations can be found at:

     http://www.iana.org/assignments/transfer-encodings

4.  Security Considerations

   Security requirements for access types are discussed in Section
   2.1.4.  Security requirements for transfer encodings are discussed in
   Section 3.1.7.

5.  IANA Considerations

   The sole purpose of this document is to define IANA registries for
   access types and transfer encodings.  The IANA procedures for these
   registries are specified in Section 2.4 and Section 3.3 respectively.

6.  Acknowledgements

   The current authors would like to acknowledge their debt to the late
   Dr. Jon Postel, whose general model of IANA registration procedures
   and specific contributions shaped the predecessors of this document
   [RFC2048].  We hope that the current version is one with which he
   would have agreed but, as it is impossible to verify that agreement,
   we have regretfully removed his name as a co-author.














Freed & Klensin          Best Current Practice                  [Page 8]

RFC 4289                   MIME Registration               December 2005


7.  References

7.1.  Normative References

   [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.  Informative References

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






















Freed & Klensin          Best Current Practice                  [Page 9]

RFC 4289                   MIME Registration               December 2005


Appendix A.  Changes Since RFC 2048

   o  Media type registration procedures are now described in a separate
      document [RFC4288].

   o  The various URLs and addresses in this document have been changed
      so they all refer to iana.org rather than isi.edu.  Additionally,
      many of the URLs have been changed to use HTTP; formerly they used
      FTP.

   o  Much of the document has been clarified in the light of
      operational experience with these procedures.

   o  Several of the references in this document have been updated to
      refer to current versions of the relevant specifications.

   o  The option of assigning the task of working on a new transfer
      encoding to an existing working group has been added to the list
      of possible actions the IESG can take.

   o  Security considerations and IANA considerations sections have been
      added.

   o  Registration of charsets for use in MIME is specified in [RFC2978]
      and is no longer addressed by this document.

Authors' Addresses

   Ned Freed
   Sun Microsystems
   3401 Centrelake Drive, Suite 410
   Ontario, CA  92761-1205
   USA

   Phone: +1 909 457 4293
   EMail: ned.freed@mrochek.com


   John C. Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140

   EMail: klensin+ietf@jck.com








Freed & Klensin          Best Current Practice                 [Page 10]

RFC 4289                   MIME Registration               December 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Freed & Klensin          Best Current Practice                 [Page 11]