Registration Procedures for Message Header Fields
RFC 3864 определяет процедуры регистрации имён полей заголовков сообщений, используемых в интернет-почте, HTTP, Netnews и других приложениях. Документ устанавливает постоянный реестр и предварительное хранилище IANA, различая поля с опубликованной спецификацией и поля, предложенные без утверждения их полезности или качества определения. Он задаёт шаблоны, порядок подачи, основания для возражений, изменение записей и требования к использованию реестра в RFC, определяющих новые поля заголовков для интернет-почты, HTTP или MIME.
Network Working Group G. Klyne
Request for Comments: 3864 Nine by Nine
BCP: 90 M. Nottingham
Category: Best Current Practice BEA
J. Mogul
HP Labs
September 2004
Процедуры регистрации полей заголовков сообщений
Статус этого меморандума
Этот документ устанавливает Best Current Practices Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2004).
Аннотация
Эта спецификация определяет процедуры регистрации полей заголовков
сообщений, используемых почтой Интернета, HTTP, Netnews и другими
приложениями.
Klyne, et al. Best Current Practice [Page 1]
RFC 3864 Регистрация полей заголовков September 2004
Содержание
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Структура этого документа . . . . . . . . . . . . . . . 3
1.2. Терминология и соглашения документа . . . . . . . . . . 4
2. Поля заголовков сообщений . . . . . . . . . . . . . . . . . . 4
2.1. Постоянные и предварительные поля заголовков . . . . . . 4
2.2. Определения полей заголовков сообщений . . . . . . . . . 5
2.2.1. Поля заголовков сообщений, специфичные для
приложений . . . . . . . . . . . . . . . . . . . 5
2.2.2. Поля заголовков MIME . . . . . . . . . . . . . . 6
3. Требования к использованию реестра . . . . . . . . . . . . . . 6
4. Процедура регистрации . . . . . . . . . . . . . . . . . . . . 6
4.1. Спецификация поля заголовка . . . . . . . . . . . . . . . 7
4.2. Шаблоны регистрации . . . . . . . . . . . . . . . . . . . 7
4.2.1. Шаблон регистрации постоянного поля заголовка
сообщения . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Шаблон представления предварительного поля
заголовка сообщения . . . . . . . . . . . . . . . 8
4.3. Подача регистрации . . . . . . . . . . . . . . . . . . . 10
4.4. Возражения против регистрации . . . . . . . . . . . . . 10
4.5. Контроль изменений . . . . . . . . . . . . . . . . . . . 11
4.6. Комментарии к определениям заголовков . . . . . . . . . 12
4.7. Расположение реестра полей заголовков . . . . . . . . . 12
5. Соображения IANA . . . . . . . . . . . . . . . . . . . . . . 12
6. Соображения безопасности . . . . . . . . . . . . . . . . . . 12
7. Благодарности . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . . 13
8.2. Информативные ссылки . . . . . . . . . . . . . . . . . . 13
9. Адреса авторов . . . . . . . . . . . . . . . . . . . . . . . 16
10. Полное заявление об авторских правах . . . . . . . . . . . . 17
1. Введение
Эта спецификация определяет процедуры регистрации имён полей
заголовков сообщений, используемых почтой Интернета, HTTP, потоками
групп новостей и другими Интернет-приложениями. Она не предназначена
для замены реестров, специфичных для протоколов, таких как реестр SIP
[30].
Преимущества центрального реестра имён полей заголовков сообщений
включают:
o предоставление единой точки отсчёта для стандартизированных и
широко используемых имён полей заголовков;
o предоставление центральной точки обнаружения устоявшихся полей
заголовков и простого нахождения определяющих их документов;
Klyne, et al. Best Current Practice [Page 2]
RFC 3864 Регистрация полей заголовков September 2004
o препятствование множественным определениям имени поля заголовка
для разных целей;
o помощь тем, кто предлагает новые поля заголовков, в распознавании
сложившихся тенденций и соглашений, а также в избегании имён,
которые могут быть спутаны с существующими;
o поощрение сближения использования имён полей заголовков между
несколькими приложениями и протоколами.
Основной спецификацией полей заголовков сообщений Интернета в
электронной почте является спецификация формата почтового сообщения
Интернета, RFC 2822 [4]. HTTP/1.0 [10] и HTTP/1.1 [24] определяют
поля заголовков сообщений (соответственно, элементы протокола
HTTP-header и message-header) для использования с HTTP. RFC 1036 [5]
определяет элементы заголовков сообщений для использования с потоками
Netnews. Эти спецификации также определяют ряд полей заголовков и
предусматривают расширение посредством использования новых имён
полей.
Существует много документов стандартного направления Интернета,
определяющих дополнительные поля заголовков для использования в тех
же пространствах имён, в частности MIME [11] и связанные
спецификации. Другие Интернет-приложения, использующие MIME, такие
как SIP (RFC 3261 [30]), также могут использовать многие из тех же
полей заголовков (но следует отметить, что IANA ведёт отдельный
реестр полей заголовков, используемых с SIP).
Хотя в принципе каждое приложение определяет собственный набор
допустимых полей заголовков, обмен сообщениями между приложениями
(например, шлюзы из почты в Netnews), общее использование
MIME-инкапсуляции и возможность общей обработки различных типов
сообщений (например, общая система архивирования и извлечения
сообщений) делают желательным наличие общей точки отсчёта для
стандартизированных и предлагаемых полей заголовков. Совместное
перечисление полей заголовков снижает вероятность случайной коллизии
и помогает разработчикам реализации находить относящуюся к делу
информацию. Определяемые здесь реестры полей заголовков сообщений
служат этой цели.
1.1. Структура этого документа
В разделе 2 обсуждается назначение этой спецификации и указываются
некоторые источники информации об определённых полях заголовков
сообщений.
В разделе 4 определяются хранилища имён полей заголовков сообщений,
а также устанавливаются требования и процедуры создания записей в
них.
Klyne, et al. Best Current Practice [Page 3]
RFC 3864 Регистрация полей заголовков September 2004
1.2. Терминология и соглашения документа
Ключевые слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT»,
«SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY» и «OPTIONAL» в этом
документе следует интерпретировать так, как описано в BCP 14, RFC
2119 [2].
2. Поля заголовков сообщений
2.1. Постоянные и предварительные поля заголовков
Многие поля заголовков сообщений определены в документах стандартного
направления, что означает, что они прошли процесс рассмотрения
сообществом и достигли консенсуса о том, что предоставляют полезную и
обоснованную возможность либо представляют широко распространённое
использование, о котором разработчикам следует знать. Некоторые
определены для экспериментального использования, что обычно указывает
на консенсус относительно их назначения, но не обязательно
относительно их технических деталей. Многие другие были определены и
приняты специально для конкретной ситуации для удовлетворения локально
возникающего требования; некоторые из них получили широкое
распространение.
Определённые здесь каталоги предназначены для охвата всех этих полей
заголовков, сохраняя при этом чёткое различие и статус для тех из них,
по которым имеется консенсус сообщества. Для этого определяются два
хранилища:
o Реестр постоянных полей заголовков сообщений, предназначенный для
заголовков, определённых в документах IETF стандартного
направления, тех, которые достигли сопоставимого уровня
рассмотрения сообществом, либо общепризнанно широко используются.
Политика назначения для такой регистрации — «Specification
Required», как определено RFC 2434 [3], при этом спецификация
должна быть опубликована в RFC (стандартного направления,
экспериментальном, информационном или историческом) либо как
«Open Standard» в смысле раздела 7 RFC 2026 [1].
o Хранилище предварительных полей заголовков сообщений,
предназначенное для любого поля заголовка, предложенного любым
разработчиком, без каких-либо утверждений о его полезности или
качестве его определения. Политика учёта таких полей — «Private
Use» согласно RFC 2434 [3].
Ни одно из хранилищ не отслеживает синтаксис, семантику или тип
значений полей. Регистрируются только имена полей, применимые
протоколы и статус; все прочие подробности указываются в определяющих
документах, на которые ссылаются записи хранилища. Значительные
обновления таких ссылок (например, замена RFC Proposed Standard на RFC
Draft Standard, но не обязательно пересмотр Internet-draft) СЛЕДУЕТ
(SHOULD) сопровождать обновлениями соответствующих записей хранилища.
Klyne, et al. Best Current Practice [Page 4]
RFC 3864 Регистрация полей заголовков September 2004
2.2. Определения полей заголовков сообщений
RFC 2822 [4] определяет общий синтаксис заголовков сообщений, а также
ряд полей для использования с почтой Интернета. HTTP/1.0 [10] и
HTTP/1.1 [24] делают то же для HTTP. Дополнительные имена полей
определены в различных документах RFC стандартного направления,
включая: RFC 1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1864 [9], RFC
2156 [14], RFC 2183 [15], RFC 2045 [11], RFC 2046 [12], RFC 2557
[23], RFC 2227 [16], RFC 2231 [17], RFC 2298 [18], RFC 2369 [19], RFC
2421 [21], RFC 2518 [22], RFC 2617 [25], RFC 2821 [26], RFC 2912
[27], RFC 2919 [28], RFC 2965 [29] и RFC 3282 [31].
2.2.1. Поля заголовков сообщений, специфичные для приложений
Интернет-приложения, использующие сходные заголовки сообщений,
включают почту Интернета [26] [4], потоки групп новостей NNTP [5],
веб-доступ HTTP [24] и любое другое приложение, использующее
MIME [11] для инкапсуляции содержимого сообщения.
В некоторых случаях (в частности, HTTP [24]) синтаксис и
использование заголовка переопределяются для конкретного приложения.
Эта регистрация касается только распределения и спецификации имён
полей, а не подробностей реализации заголовков в конкретных
протоколах.
В некоторых случаях одно и то же имя поля может быть определено
по-разному (разными документами) для использования с различными
прикладными протоколами; например, поле заголовка Date:, используемое
с HTTP, имеет иной синтаксис, чем Date:, используемое с почтой
Интернета. В других случаях имя поля может иметь общую спецификацию
для нескольких протоколов (без учёта лексических соглашений и
соглашений о наборах символов, специфичных для протокола); например,
так обычно обстоит дело для полей заголовков MIME с именами вида
'Content-*'.
Поэтому необходимо учитывать поля, специфичные для приложений, в то
же время желая признавать и поощрять (где это уместно) общность других
полей между несколькими приложениями. Общие хранилища используются для
всех приложений, и каждое зарегистрированное поле заголовка указывает
прикладной протокол, к которому относится соответствующее определение.
Данное имя поля может иметь несколько записей реестра для разных
протоколов; в реестре постоянных полей заголовков сообщений данное имя
поля заголовка может быть зарегистрировано только один раз для любого
данного протокола. (В некоторых случаях регистрация может ссылаться
на несколько определяющих документов.)
Klyne, et al. Best Current Practice [Page 5]
RFC 3864 Регистрация полей заголовков September 2004
2.2.2. Поля заголовков MIME
Некоторые поля заголовков с именами вида Content-* связаны со средой
инкапсуляции и маркировки объектов данных MIME. Эти поля заголовков
могут осмысленно применяться к объекту данных отдельно от протокола,
используемого для его передачи.
MIME используется с сообщениями электронной почты и другими
протоколами, которые определяют формат объекта данных на основе MIME.
Поля заголовков MIME, используемые с такими протоколами, определены в
реестре с протоколом «mime» и поэтому предполагаются пригодными для
использования совместно с любым протоколом, передающим объекты MIME.
Другие протоколы не передают объекты MIME, но определяют ряд полей
заголовков с именами и функциями, сходными с MIME. В частности, HTTP
определяет ряд полей заголовков сущности, которые служат в HTTP той же
цели, что поля заголовков MIME в электронной почте. Некоторые из этих
полей заголовков имеют те же имена и сходные функции, что и их аналоги
MIME (хотя имеются некоторые различия). Такие поля заголовков должны
быть зарегистрированы отдельно для любого протокола, не передающего
MIME, с которым они могут использоваться.
Повторно использовать имя поля заголовка из другого протокола только
потому, что поля имеют сходные (даже «очень сходные») значения,
является плохой практикой. Протоколам следует совместно использовать
имена полей заголовков только тогда, когда их значения идентичны при
всех предвидимых обстоятельствах. В частности, новые имена полей
заголовков вида Content-* не следует определять для протоколов, не
передающих MIME, если только их спецификация не является в точности
такой же, как в MIME.
3. Требования к использованию реестра
RFC, определяющие новые поля заголовков для почты Интернета, HTTP или
MIME, ДОЛЖНЫ (MUST) включать соответствующие шаблоны регистрации
заголовков (как приведено в разделе 4.2) для всех заголовков,
определённых в документе, в раздел соображений IANA. Использование
реестра заголовков МОЖЕТ (MAY) предписываться другими спецификациями
протоколов, однако при отсутствии такого предписания использование
реестра не требуется.
4. Процедура регистрации
Процедура регистрации поля заголовка сообщения такова:
1. Составить спецификацию поля заголовка
2. Подготовить шаблон регистрации
3. Представить шаблон регистрации
Klyne и др. Лучшая современная практика [Страница 6]
RFC 3864 Регистрация полей заголовка Сентябрь 2004
4.1. Спецификация поля заголовка
Регистрация нового поля заголовка сообщения начинается с подготовки
предложения, описывающего синтаксис, семантику и предполагаемое
использование поля. Для записей в Постоянном реестре полей заголовков
сообщений это предложение ДОЛЖНО (MUST) быть опубликовано как RFC или как
Открытый стандарт в смысле, описанном в разделе 7 RFC 2026 [1].
Зарегистрированное имя поля СЛЕДУЕТ (SHOULD) по меньшей мере соответствовать
синтаксису, определённому в разделе 3.6.8 RFC 2822 [4].
Кроме того, символ "." зарезервирован для обозначения подструктуры
именования и НЕ ДОЛЖЕН (MUST NOT) включаться ни в одно зарегистрированное
имя поля. В настоящее время никакая конкретная подструктура не определена;
при её использовании любая такая структура ДОЛЖНА (MUST) быть определена
документом RFC категории standards track.
Имена полей заголовков иногда могут использоваться в URI, URN и/или XML.
Для соблюдения синтаксических ограничений этих форм рекомендуется
ограничивать символы в зарегистрированном имени поля теми, которые могут
использоваться без экранирования в URI [20] или URN [13], а также
допустимы в именах элементов XML [32].
Таким образом, для максимальной гибкости имена полей заголовков СЛЕДУЕТ
(SHOULD) дополнительно ограничить только буквами, цифрами, дефисом ('-')
и символом подчёркивания ('_'), причём первым символом должна быть буква
или символ подчёркивания.
4.2. Шаблоны регистрации
Шаблон регистрации поля заголовка сообщения может содержаться в
определяющем документе либо подготавливаться отдельно.
4.2.1. Шаблон регистрации постоянного поля заголовка сообщения
Заголовок, зарегистрированный в Постоянном реестре полей заголовков
сообщений, ДОЛЖЕН (MUST) быть опубликован как RFC или как «Открытый
стандарт» в смысле, описанном в разделе 7 RFC 2026 [1], и ДОЛЖЕН (MUST)
иметь имя, уникальное среди всех зарегистрированных постоянных имён полей,
которые могут использоваться с тем же протоколом приложения.
Шаблон регистрации имеет следующую форму.
ШАБЛОН РЕГИСТРАЦИИ ПОСТОЯННОГО ПОЛЯ ЗАГОЛОВКА СООБЩЕНИЯ:
Имя поля заголовка:
Имя, запрашиваемое для нового поля заголовка. Оно ДОЛЖНО (MUST)
соответствовать деталям спецификации поля заголовка, указанным в
разделе 4.1.
Klyne и др. Лучшая современная практика [Страница 7]
RFC 3864 Регистрация полей заголовка Сентябрь 2004
Применимый протокол:
Укажите "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
"netnews" (RFC 1036) либо приведите ссылку на любой другой RFC
категории standards track, определяющий протокол, с которым
предполагается использовать заголовок.
Статус:
Укажите "standard", "experimental", "informational", "historic",
"obsoleted" или иное подходящее значение в соответствии с типом и
статусом основного документа, в котором он определён. Для спецификаций
не-IETF те из них, которые официально одобрены другими органами по
стандартизации, следует помечать как "standard"; остальные могут быть
"informational" или "deprecated" в зависимости от причины
регистрации.
Автор/контролёр изменений:
Для Internet standards-track укажите "IETF". Для других открытых
стандартов укажите наименование публикующего органа (например, ANSI,
ISO, ITU, W3C и т. д.). Для других спецификаций укажите имя, адрес
электронной почты и название организации автора основной спецификации.
Также могут быть включены почтовый адрес, URI домашней страницы, номера
телефона и факса.
Документ(ы) спецификации:
Ссылка на документ, определяющий заголовок для использования с
указанным протоколом, желательно включающая URI, который может быть
использован для получения копии документа. Также МОЖЕТ (MAY) быть
включено указание соответствующих разделов, но оно не требуется.
Связанная информация:
Необязательно, ссылки на дополнительные документы, содержащие другую
относящуюся к делу информацию. (Эта часть реестра также может
использоваться для комментариев IESG.) Если основная спецификация
ссылается на другой документ для получения существенных технических
подробностей, упоминание документа, на который дана ссылка, здесь
полезно.
4.2.2. Шаблон представления предварительного поля заголовка сообщения
Регистрация в качестве предварительного поля заголовка сообщения не
подразумевает какого-либо одобрения со стороны IETF, IANA или любого
другого органа.
Основные требования для включения поля заголовка в предварительное
хранилище состоят в том, что оно ДОЛЖНО (MUST) иметь спецификацию, на
которую можно сослаться, и НЕ ДОЛЖНА (MUST NOT) существовать
соответствующая запись (с тем же именем поля и протоколом) в постоянном
реестре полей заголовков.
Klyne и др. Лучшая современная практика [Страница 8]
RFC 3864 Регистрация полей заголовка Сентябрь 2004
Спецификация СЛЕДУЕТ (SHOULD) указывать адрес электронной почты для
отправки технических комментариев и обсуждения предлагаемого заголовка
сообщения.
Шаблон представления имеет следующую форму.
ШАБЛОН ПРЕДСТАВЛЕНИЯ ПРЕДВАРИТЕЛЬНОГО ПОЛЯ ЗАГОЛОВКА СООБЩЕНИЯ:
Имя поля заголовка:
Имя, предложенное для нового поля заголовка. Оно СЛЕДУЕТ (SHOULD)
соответствовать деталям спецификации имени поля, указанным в разделе
4.1.
Применимый протокол:
Укажите "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
"netnews" (RFC 1036) либо приведите ссылку на любой другой RFC
категории standards track, определяющий протокол, с которым
предполагается использовать заголовок.
Статус:
Укажите: "provisional". Он будет обновлён, если и когда регистрация
заголовка впоследствии будет перенесена в постоянный реестр.
Автор/контролёр изменений:
Имя, адрес электронной почты и название организации автора
представления, который может санкционировать изменения записи в
хранилище или её отзыв. Также могут быть включены почтовый адрес, URI
домашней страницы, номера телефона и факса.
Если предложение исходит от рабочей группы органа по стандартизации,
укажите наименование и URI домашней страницы рабочей группы, а также
адрес электронной почты для обсуждения спецификации или комментариев к
ней.
Документ(ы) спецификации:
Ссылка на документ, определяющий заголовок для использования с
указанным протоколом. Документ ДОЛЖЕН (MUST) быть RFC, действующим
Internet-draft или URL общедоступного документа (чтобы IANA могла
проверить доступность спецификации). Также МОЖЕТ (MAY) быть включено
указание соответствующих разделов, но оно не требуется.
ПРИМЕЧАНИЕ: если спецификация доступна только в печатной форме,
то следует опубликовать Internet-draft, содержащий полную ссылку
на бумажный документ, и сослаться на него в шаблоне регистрации.
На бумажную спецификацию МОЖЕТ (MAY) быть приведена ссылка в
разделе связанной информации.
Связанная информация:
Необязательно, ссылки на дополнительные документы, содержащие другую
относящуюся к делу информацию.
Klyne и др. Лучшая современная практика [Страница 9]
RFC 3864 Регистрация полей заголовка Сентябрь 2004
4.3. Представление регистрации
Шаблон регистрации представляется для включения в одно из хранилищ IANA
полей заголовков сообщений одним из следующих способов:
o Раздел соображений IANA в определяющем RFC, призывающий к регистрации
заголовка сообщения и содержащий ссылочную информацию, требуемую
шаблоном регистрации, в том же документе. Затем регистрация заголовка
обрабатывается как часть процесса публикации RFC.
o Отправьте копию шаблона в назначенный список рассылки для обсуждений
[33] [34]. Предоставьте разумный период — не менее 2 недель — для
обсуждения и комментариев, затем отправьте шаблон в IANA по
назначенному адресу электронной почты [35]. IANA опубликует информацию
шаблона, если запрошенное имя и документ спецификации отвечают
критериям, указанным в разделе 4.1 и разделе 4.2.2, если только IESG
или назначенный ею эксперт не потребовали не публиковать её (см.
раздел 4.4). Назначенному IESG эксперту следует подтвердить IANA, что
критерии регистрации были соблюдены.
Когда новая запись вносится в постоянный реестр полей заголовков
сообщений, IANA удалит из предварительного реестра все соответствующие
записи (с тем же именем поля и протоколом).
4.4. Возражения против регистрации
Во включении записи в предварительное хранилище не следует легкомысленно
отказывать. В регистрации записи МОЖЕТ (MAY) быть отказано, если есть
некоторое заслуживающее доверия основание полагать, что такая регистрация
будет вредоносной. При отсутствии такого возражения IANA СЛЕДУЕТ (SHOULD)
разрешать любую регистрацию, отвечающую критериям, изложенным в разделе
4.1 и разделе 4.2.2. Некоторые разумные основания для отказа могут быть
следующими:
o Имеется консенсус IETF, что публикация, вероятно, каким-либо образом
нанесёт ущерб технической инфраструктуре Интернета.
o Бесчестное или легкомысленное использование средств регистрации.
o Предложение настолько лишено цели или вводит в заблуждение относительно
своей цели, что его можно считать пустой тратой времени и усилий.
o Конфликт с какой-либо текущей деятельностью IETF.
Klyne и др. Лучшая современная практика [Страница 10]
RFC 3864 Регистрация полей заголовка Сентябрь 2004
Обратите внимание, что возражения или разногласия по техническим деталям
сами по себе не считаются основаниями для отказа во включении в
предварительное хранилище. В конце концов, одна из его целей состоит в
том, чтобы позволить разработчикам общаться с целью объединить их идеи,
опыт и энергию с максимальной пользой для интернет-сообщества.
Публикация в RFC или ином документе в форме Открытого стандарта (согласно
разделу 7 RFC 2026 [1]) является достаточным основанием для публикации в
постоянном реестре.
Чтобы помочь IANA определить, существует ли устойчивое возражение против
какой-либо регистрации, IESG назначает выделенного эксперта для связи с
IANA по поводу новых регистраций. По большей части роль выделенного
эксперта состоит в подтверждении IANA того, что критерии регистрации были
соблюдены.
IESG или назначенный ею эксперт МОЖЕТ (MAY) потребовать приложить любое
изменение или комментарий к любой записи реестра.
IESG является окончательным арбитром по любому возражению.
4.5. Контроль изменений
Контроль изменений регистрации поля заголовка подчиняется тому же условию,
что и первоначальная регистрация; то есть публикации (или
переклассификации) спецификации Открытого стандарта для Постоянного поля
заголовка сообщения или запросу указанного автора/контролёра изменений
для Предварительного заголовка сообщения (как и первоначальное
представление, при условии рассмотрения в назначенном списке рассылки для
обсуждений [33]).
Изменение регистрации постоянного поля заголовка сообщения МОЖЕТ (MAY)
быть запрошено IESG.
Изменение или отзыв любой записи Хранилища предварительных полей
заголовков сообщений МОЖЕТ (MAY) быть запрошен IESG или выделенным
экспертом.
IANA МОЖЕТ (MAY) удалить любую запись Хранилища предварительных полей
заголовков сообщений, соответствующий документ спецификации которой более
недоступен (например, Internet-draft с истёкшим сроком действия или URL,
который невозможно разрешить). Любой может уведомить IANA о любом таком
случае, отправив электронное письмо по назначенному адресу электронной
почты [35]. Прежде чем удалить запись по этой причине, IANA СЛЕДУЕТ
(SHOULD) связаться с зарегистрированным Автором/контролёром изменений,
чтобы определить, доступна ли замена документа спецификации
(соответствующая требованиям раздела Раздела 4.2.2).
Klyne и др. Лучшая современная практика [Страница 11]
RFC 3864 Регистрация полей заголовка Сентябрь 2004
Предполагается, что записи в Постоянном реестре полей заголовков сообщений
могут использоваться при построении URN (согласно RFC 2141 [13]), для
которых имеются особые требования к уникальности и постоянству (согласно
RFC 1737 [8]). Поэтому после внесения записи в Постоянный реестр
заголовков сообщений сочетание имени заголовка и применимого протокола НЕ
ДОЛЖНО (MUST NOT) впоследствии регистрироваться для какой-либо иной цели.
(Это не исключает пересмотра применимых спецификаций в рамках
соответствующих правил консенсуса IETF и соответствующих обновлений ссылки
на спецификацию в регистрации заголовка.)
4.6. Комментарии к определениям заголовков
Комментарии к предлагаемым регистрациям следует направлять в назначенный
список рассылки для обсуждений [33].
4.7. Расположение реестра полей заголовков
Реестр полей заголовков сообщений доступен на веб-сайте IANA
http://www.iana.org/assignments/message-headers/
message-header-index.html
5. Соображения IANA
Данная спецификация предусматривает:
o Новый реестр IANA для постоянных полей заголовков сообщений согласно
разделу 4 данного документа. Политика включения в этот реестр описана
в разделе 4.1 и разделе 4.2.1.
o Новое хранилище IANA, содержащее список предварительных полей
заголовков сообщений согласно разделу 4 данного документа. Политика
включения в этот реестр описана в разделе 4.1 и разделе 4.2.2.
o IESG назначает выделенного эксперта для консультирования IANA по
вопросу о том, соблюдены ли критерии регистрации для предлагаемых
регистраций.
Начальные записи реестра не предоставлены.
6. Соображения безопасности
Данная спецификация не вводит соображений безопасности сверх тех, которые
уже присущи использованию заголовков сообщений.
Klyne и др. Лучшая современная практика [Страница 12]
RFC 3864 Регистрация полей заголовка Сентябрь 2004
7. Благодарности
Форма описанных здесь реестров во многом обязана энергичному обсуждению
предыдущих версий многими обитателями списка рассылки IETF-822.
Авторы также с благодарностью признают вклад тех, кто предоставил
ценные отзывы о более ранних версиях этой записки: Charles
Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle
Cotton.
8. Ссылки
8.1. Нормативные ссылки
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
8.2. Справочные ссылки
[5] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", RFC 1036, December 1987.
[6] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the messages", RFC 1496, August
1993.
[7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header
Field for Internet Messages", RFC 1505, August 1993.
[8] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864,
October 1995.
[10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
Klyne, et al. Best Current Practice [Page 13]
RFC 3864 Header Field Registration September 2004
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[13] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[15] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting
for HTTP", RFC 2227, October 1997.
[17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", RFC
2231, November 1997.
[18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
Notification", RFC 3798, May 2004.
[19] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message
Header Fields", RFC 2369, July 1998.
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
version 2 (VPIMv2)", RFC 3801, June 2004.
[22] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518,
February 1999.
[23] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME
Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC
2557, March 1999.
Klyne, et al. Best Current Practice [Page 14]
RFC 3864 Header Field Registration September 2004
[24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[25] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[27] Klyne, G., "Indicating Media Features for MIME Content", RFC
2912, September 2000.
[28] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists", RFC 2919,
March 2001.
[29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
RFC 2965, October 2000.
[30] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[32] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
Recommendation xml, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[33] "Mail address for announcement of new header field submissions",
Почтовый адрес: ietf-message-headers@lists.ietf.org
[34] "Mail address for subscription to ietf-message-
headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO
THE MAILING LIST ITSELF)", Почтовый адрес: ietf-message-headers-
request@lists.ietf.org
[35] "Mail address for submission of new header field templates",
Почтовый адрес: iana@iana.org
Klyne, et al. Best Current Practice [Page 15]
RFC 3864 Header Field Registration September 2004
9. Адреса авторов
Graham Klyne
Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Mark Nottingham
BEA Systems
235 Montgomery St.
Level 15
San Francisco, CA 94104
USA
EMail: mnot@pobox.com
Jeffrey C. Mogul
HP Labs
1501 Page Mill Road
Palo Alto, CA 94304
US
EMail: JeffMogul@acm.org
Klyne, et al. Best Current Practice [Page 16]
RFC 3864 Header Field Registration September 2004
10. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004). Этот документ подпадает
под действие прав, лицензий и ограничений, содержащихся в BCP 78, и,
за исключением предусмотренного в нём, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются по
принципу «КАК ЕСТЬ», И ВКЛАДЧИК (CONTRIBUTOR), ОРГАНИЗАЦИЯ, КОТОРУЮ
ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ КОТОРАЯ ЕГО/ЕЁ СПОНСИРУЕТ (ЕСЛИ ТАКОВАЯ
ИМЕЕТСЯ), THE INTERNET SOCIETY И THE INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ,
ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ
ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИЕ-ЛИБО ПРАВА, И ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ
ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма
каких-либо прав интеллектуальной собственности либо других прав,
которые могут быть заявлены как относящиеся к реализации или
использованию технологии, описанной в этом документе, или относительно
того, может ли какая-либо лицензия в отношении таких прав быть доступна;
также она не заявляет, что предприняла какие-либо независимые усилия по
выявлению таких прав. Информацию о процедурах в отношении прав в
документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, направленных в Секретариат IETF, и любые заверения
о лицензиях, которые будут предоставлены, либо результат попытки
получить общую лицензию или разрешение на использование таких прав
собственности разработчиками или пользователями этой спецификации
можно получить в онлайновом репозитории IPR IETF по адресу
http://www.ietf.org/ipr.
IETF приглашает любое заинтересованное лицо довести до её сведения
сведения об авторских правах, патентах или патентных заявках, либо
иных правах собственности, которые могут охватывать технологию,
которая может быть необходима для реализации этого стандарта. Просим
направлять эту информацию в IETF по адресу ietf-
ipr@ietf.org.
Признательность
Финансирование функции RFC Editor в настоящее время обеспечивается
The Internet Society.
Klyne, et al. Best Current Practice [Page 17]
Network Working Group G. Klyne
Request for Comments: 3864 Nine by Nine
BCP: 90 M. Nottingham
Category: Best Current Practice BEA
J. Mogul
HP Labs
September 2004
Registration Procedures for Message Header Fields
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 (2004).
Abstract
This specification defines registration procedures for the message
header fields used by Internet mail, HTTP, Netnews and other
applications.
Klyne, et al. Best Current Practice [Page 1]
RFC 3864 Header Field Registration September 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Structure of this Document . . . . . . . . . . . . . . . 3
1.2. Document Terminology and Conventions . . . . . . . . . . 4
2. Message Header Fields. . . . . . . . . . . . . . . . . . . . . 4
2.1. Permanent and Provisional Header Fields. . . . . . . . . 4
2.2. Definitions of Message Header Fields . . . . . . . . . . 5
2.2.1. Application-specific Message Header Fields. . . . 5
2.2.2. MIME Header Fields. . . . . . . . . . . . . . . . 6
3. Registry Usage Requirements. . . . . . . . . . . . . . . . . . 6
4. Registration Procedure . . . . . . . . . . . . . . . . . . . . 6
4.1. Header Field Specification . . . . . . . . . . . . . . . 7
4.2. Registration Templates . . . . . . . . . . . . . . . . . 7
4.2.1. Permanent Message Header Field Registration
Template. . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Provisional Message Header Field Submission
Template. . . . . . . . . . . . . . . . . . . . . 8
4.3. Submission of Registration . . . . . . . . . . . . . . . 10
4.4. Objections to Registration . . . . . . . . . . . . . . . 10
4.5. Change Control . . . . . . . . . . . . . . . . . . . . . 11
4.6. Comments on Header Definitions . . . . . . . . . . . . . 12
4.7. Location of Header Field Registry. . . . . . . . . . . . 12
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This specification defines registration procedures for the message
header field names used by Internet mail, HTTP, newsgroup feeds and
other Internet applications. It is not intended to be a replacement
for protocol-specific registries, such as the SIP registry [30].
Benefits of a central registry for message header field names
include:
o providing a single point of reference for standardized and
widely-used header field names;
o providing a central point of discovery for established header
fields, and easy location of their defining documents;
Klyne, et al. Best Current Practice [Page 2]
RFC 3864 Header Field Registration September 2004
o discouraging multiple definitions of a header field name for
different purposes;
o helping those proposing new header fields discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encouraging convergence of header field name usage across multiple
applications and protocols.
The primary specification for Internet message header fields in email
is the Internet mail message format specification, RFC 2822 [4].
HTTP/1.0 [10] and HTTP/1.1 [24] define message header fields
(respectively, the HTTP-header and message-header protocol elements)
for use with HTTP. RFC 1036 [5] defines message header elements for
use with Netnews feeds. These specifications also define a number of
header fields, and provide for extension through the use of new
field-names.
There are many other Internet standards track documents that define
additional header fields for use within the same namespaces, notably
MIME [11] and related specifications. Other Internet applications
that use MIME, such as SIP (RFC 3261 [30]) may also use many of the
same header fields (but note that IANA maintains a separate registry
of header fields used with SIP).
Although in principle each application defines its own set of valid
header fields, exchange of messages between applications (e.g., mail
to Netnews gateways), common use of MIME encapsulation, and the
possibility of common processing for various message types (e.g., a
common message archive and retrieval facility) makes it desirable to
have a common point of reference for standardized and proposed header
fields. Listing header fields together reduces the chance of an
accidental collision, and helps implementers find relevant
information. The message header field registries defined here serve
that purpose.
1.1. Structure of this Document
Section 2 discusses the purpose of this specification, and indicates
some sources of information about defined message header fields.
Section 4 defines the message header field name repositories, and
sets out requirements and procedures for creating entries in them.
Klyne, et al. Best Current Practice [Page 3]
RFC 3864 Header Field Registration September 2004
1.2. Document Terminology and Conventions
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 BCP 14, RFC 2119 [2].
2. Message Header Fields
2.1. Permanent and Provisional Header Fields
Many message header fields are defined in standards-track documents,
which means they have been subjected to a process of community review
and achieved consensus that they provide a useful and well-founded
capability, or represent a widespread use of which developers should
be aware. Some are defined for experimental use, typically
indicating consensus regarding their purpose but not necessarily
concerning their technical details. Many others have been defined
and adopted ad-hoc to address a locally occurring requirement; some
of these have found widespread use.
The catalogues defined here are intended to cater for all of these
header fields, while maintaining a clear distinction and status for
those which have community consensus. To this end, two repositories
are defined:
o A Permanent Message Header Field Registry, intended for headers
defined in IETF standards-track documents, those that have
achieved a comparable level of community review, or are generally
recognized to be in widespread use. The assignment policy for
such registration is "Specification Required", as defined by RFC
2434 [3], where the specification must be published in an RFC
(standards-track, experimental, informational or historic), or as
an "Open Standard" in the sense of RFC 2026, section 7 [1].
o A Provisional Message Header Field Repository, intended for any
header field proposed by any developer, without making any claim
about its usefulness or the quality of its definition. The policy
for recording these is "Private Use", per RFC 2434 [3].
Neither repository tracks the syntax, semantics or type of field-
values. Only the field-names, applicable protocols and status are
registered; all other details are specified in the defining documents
referenced by repository entries. Significant updates to such
references (e.g., the replacement of a Proposed Standard RFC by a
Draft Standard RFC, but not necessarily the revision of an Internet-
draft) SHOULD be accompanied by updates to the corresponding
repository entries.
Klyne, et al. Best Current Practice [Page 4]
RFC 3864 Header Field Registration September 2004
2.2. Definitions of Message Header Fields
RFC 2822 [4] defines a general syntax for message headers, and also
defines a number of fields for use with Internet mail. HTTP/1.0 [10]
and HTTP/1.1 [24] do likewise for HTTP. Additional field names are
defined in a variety of standards-track RFC documents, including: RFC
1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1864 [9], RFC 2156 [14],
RFC 2183 [15], RFC 2045 [11], RFC 2046 [12], RFC 2557 [23], RFC 2227
[16], RFC 2231 [17], RFC 2298 [18], RFC 2369 [19], RFC 2421 [21], RFC
2518 [22], RFC 2617 [25], RFC 2821 [26], RFC 2912 [27], RFC 2919
[28], RFC 2965 [29], and RFC 3282 [31].
2.2.1. Application-specific Message Header Fields
Internet applications that use similar message headers include
Internet mail [26] [4], NNTP newsgroup feeds [5], HTTP web access
[24] and any other that uses MIME [11] encapsulation of message
content.
In some cases (notably HTTP [24]), the header syntax and usage is
redefined for the specific application. This registration is
concerned only with the allocation and specification of field names,
and not with the details of header implementation in specific
protocols.
In some cases, the same field name may be specified differently (by
different documents) for use with different application protocols;
e.g., The Date: header field used with HTTP has a different syntax
than the Date: used with Internet mail. In other cases, a field name
may have a common specification across multiple protocols (ignoring
protocol-specific lexical and character set conventions); e.g., this
is generally the case for MIME header fields with names of the form
'Content-*'.
Thus, we need to accommodate application-specific fields, while
wishing to recognize and promote (where appropriate) commonality of
other fields across multiple applications. Common repositories are
used for all applications, and each registered header field specifies
the application protocol for which the corresponding definition
applies. A given field name may have multiple registry entries for
different protocols; in the Permanent Message Header Field registry,
a given header field name may be registered only once for any given
protocol. (In some cases, the registration may reference several
defining documents.)
Klyne, et al. Best Current Practice [Page 5]
RFC 3864 Header Field Registration September 2004
2.2.2. MIME Header Fields
Some header fields with names of the form Content-* are associated
with the MIME data object encapsulation and labelling framework.
These header fields can meaningfully be applied to a data object
separately from the protocol used to carry it.
MIME is used with email messages and other protocols that specify a
MIME-based data object format. MIME header fields used with such
protocols are defined in the registry with the protocol "mime", and
as such are presumed to be usable in conjunction with any protocol
that conveys MIME objects.
Other protocols do not convey MIME objects, but define a number of
header fields with similar names and functions to MIME. Notably,
HTTP defines a number of entity header fields that serve a purpose in
HTTP similar to MIME header fields in email. Some of these header
fields have the same names and similar functions to their MIME
counterparts (though there are some variations). Such header fields
must be registered separately for any non-MIME-carrying protocol with
which they may be used.
It is poor practice to reuse a header field name from another
protocol simply because the fields have similar (even "very similar")
meanings. Protocols should share header field names only when their
meanings are identical in all foreseeable circumstances. In
particular, new header field names of the form Content-* should not
be defined for non-MIME-carrying protocols unless their specification
is exactly the same as in MIME.
3. Registry Usage Requirements
RFCs defining new header fields for Internet mail, HTTP, or MIME MUST
include appropriate header registration template(s) (as given in
Section 4.2) for all headers defined in the document in their IANA
considerations section. Use of the header registry MAY be mandated
by other protocol specifications, however, in the absence of such a
mandate use of the registry is not required.
4. Registration Procedure
The procedure for registering a message header field is:
1. Construct a header field specification
2. Prepare a registration template
3. Submit the registration template
Klyne, et al. Best Current Practice [Page 6]
RFC 3864 Header Field Registration September 2004
4.1. Header Field Specification
Registration of a new message header field starts with construction
of a proposal that describes the syntax, semantics and intended use
of the field. For entries in the Permanent Message Header Field
Registry, this proposal MUST be published as an RFC, or as an Open
Standard in the sense described by RFC 2026, section 7 [1].
A registered field name SHOULD conform at least to the syntax defined
by RFC 2822 [4], section 3.6.8.
Further, the "." character is reserved to indicate a naming sub-
structure and MUST NOT be included in any registered field name.
Currently, no specific sub-structure is defined; if used, any such
structure MUST be defined by a standards track RFC document.
Header field names may sometimes be used in URIs, URNs and/or XML.
To comply with the syntactic constraints of these forms, it is
recommended that characters in a registered field name are restricted
to those that can be used without escaping in a URI [20] or URN [13],
and that are also legal in XML [32] element names.
Thus, for maximum flexibility, header field names SHOULD further be
restricted to just letters, digits, hyphen ('-') and underscore ('_')
characters, with the first character being a letter or underscore.
4.2. Registration Templates
The registration template for a message header field may be contained
in the defining document, or prepared separately.
4.2.1. Permanent Message Header Field Registration Template
A header registered in the Permanent Message Header Field Registry
MUST be published as an RFC or as an "Open Standard" in the sense
described by RFC 2026, section 7 [1], and MUST have a name which is
unique among all the registered permanent field names that may be
used with the same application protocol.
The registration template has the following form.
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
Header field name:
The name requested for the new header field. This MUST conform to
the header field specification details noted in Section 4.1.
Klyne, et al. Best Current Practice [Page 7]
RFC 3864 Header Field Registration September 2004
Applicable protocol:
Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
"netnews" (RFC 1036), or cite any other standards-track RFC
defining the protocol with which the header is intended to be
used.
Status:
Specify "standard", "experimental", "informational", "historic",
"obsoleted", or some other appropriate value according to the type
and status of the primary document in which it is defined. For
non-IETF specifications, those formally approved by other
standards bodies should be labelled as "standard"; others may be
"informational" or "deprecated" depending on the reason for
registration.
Author/Change controller:
For Internet standards-track, state "IETF". For other open
standards, give the name of the publishing body (e.g., ANSI, ISO,
ITU, W3C, etc.). For other specifications, give the name, email
address, and organization name of the primary specification
author. A postal address, home page URI, telephone and fax
numbers may also be included.
Specification document(s):
Reference to document that specifies the header for use with the
indicated protocol, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant
sections MAY also be included, but is not required.
Related information:
Optionally, citations to additional documents containing further
relevant information. (This part of the registry may also be used
for IESG comments.) Where a primary specification refers to
another document for substantial technical detail, the referenced
document is usefully mentioned here.
4.2.2. Provisional Message Header Field Submission Template
Registration as a Provisional Message Header Field does not imply any
kind of endorsement by the IETF, IANA or any other body.
The main requirements for a header field to be included in the
provisional repository are that it MUST have a citable specification,
and there MUST NOT be a corresponding entry (with same field name and
protocol) in the permanent header field registry.
Klyne, et al. Best Current Practice [Page 8]
RFC 3864 Header Field Registration September 2004
The specification SHOULD indicate an email address for sending
technical comments and discussion of the proposed message header.
The submission template has the following form.
PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:
Header field name:
The name proposed for the new header field. This SHOULD conform
to the field name specification details noted in Section 4.1.
Applicable protocol:
Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
"netnews" (RFC 1036), or cite any other standards-track RFC
defining the protocol with which the header is intended to be
used.
Status:
Specify: "provisional". This will be updated if and when the
header registration is subsequently moved to the permanent
registry.
Author/Change controller:
The name, email address, and organization name of the submission
author, who may authorize changes to or retraction of the
repository entry. A postal address, home page URI, telephone and
fax numbers may also be included.
If the proposal comes from a standards body working group, give
the name and home page URI of the working group, and an email
address for discussion of or comments on the specification.
Specification document(s):
Reference to document that specifies the header for use with the
indicated protocol. The document MUST be an RFC, a current
Internet-draft or the URL of a publicly accessible document (so
IANA can verify availability of the specification). An indication
of the relevant sections MAY also be included, but is not
required.
NOTE: if the specification is available in printed form only,
then an Internet draft containing full reference to the paper
document should be published and cited in the registration
template. The paper specification MAY be cited under related
information.
Related information:
Optionally, citations to additional documents containing further
relevant information.
Klyne, et al. Best Current Practice [Page 9]
RFC 3864 Header Field Registration September 2004
4.3. Submission of Registration
The registration template is submitted for incorporation in one of
the IANA message header field repositories by one of the following
methods:
o An IANA considerations section in a defining RFC, calling for
registration of the message header and referencing information as
required by the registration template within the same document.
Registration of the header is then processed as part of the RFC
publication process.
o Send a copy of the template to the designated email discussion
list [33] [34]. Allow a reasonable period - at least 2 weeks -
for discussion and comments, then send the template to IANA at the
designated email address [35]. IANA will publish the template
information if the requested name and the specification document
meet the criteria noted in Section 4.1 and Section 4.2.2, unless
the IESG or their designated expert have requested that it not be
published (see Section 4.4). IESG's designated expert should
confirm to IANA that the registration criteria have been
satisfied.
When a new entry is recorded in the permanent message header field
registry, IANA will remove any corresponding entries (with the same
field name and protocol) from the provisional registry.
4.4. Objections to Registration
Listing of an entry in the provisional repository should not be
lightly refused. An entry MAY be refused if there is some credible
reason to believe that such registration will be harmful. In the
absence of such objection, IANA SHOULD allow any registration that
meets the criteria set out in Section 4.1 and Section 4.2.2. Some
reasonable grounds for refusal might be:
o There is IETF consensus that publication is considered likely to
harm the Internet technical infrastructure in some way.
o Disreputable or frivolous use of the registration facilities.
o The proposal is sufficiently lacking in purpose, or misleading
about its purpose, that it can be held to be a waste of time and
effort.
o Conflict with some current IETF activity.
Klyne, et al. Best Current Practice [Page 10]
RFC 3864 Header Field Registration September 2004
Note that objections or disagreements about technical detail are not,
of themselves, considered grounds to refuse listing in the
provisional repository. After all, one of its purposes is to allow
developers to communicate with a view to combining their ideas,
expertise and energy to the maximum benefit of the Internet
community.
Publication in an RFC or other form of Open Standard document (per
RFC 2026 [1], section 7) is sufficient grounds for publication in the
permanent registry.
To assist IANA in determining whether or not there is a sustainable
objection to any registration, IESG nominates a designated expert to
liaise with IANA about new registrations. For the most part, the
designated expert's role is to confirm to IANA that the registration
criteria have been satisfied.
The IESG or their designated expert MAY require any change or
commentary to be attached to any registry entry.
The IESG is the final arbiter of any objection.
4.5. Change Control
Change control of a header field registration is subject to the same
condition as the initial registration; i.e., publication (or
reclassification) of an Open Standards specification for a Permanent
Message Header Field, or on request of the indicated author/change
controller for a Provisional Message Header (like the original
submission, subject to review on the designated email discussion list
[33].)
A change to a permanent message header field registration MAY be
requested by the IESG.
A change to or retraction of any Provisional Message Header Field
Repository entry MAY be requested by the IESG or designated expert.
IANA MAY remove any Provisional Message Header Field Repository entry
whose corresponding specification document is no longer available
(e.g., expired Internet-draft, or URL not resolvable). Anyone may
notify IANA of any such cases by sending an email to the designated
email address [35]. Before removing an entry for this reason, IANA
SHOULD contact the registered Author/Change controller to determine
whether a replacement for the specification document (consistent with
the requirements of section Section 4.2.2) is available.
Klyne, et al. Best Current Practice [Page 11]
RFC 3864 Header Field Registration September 2004
It is intended that entries in the Permanent Message Header Field
Registry may be used in the construction of URNs (per RFC 2141 [13])
which have particular requirements for uniqueness and persistence
(per RFC 1737 [8]). Therefore, once an entry is made in the
Permanent Message Header Registry, the combination of the header name
and applicable protocol MUST NOT subsequently be registered for any
other purpose. (This is not to preclude revision of the applicable
specification(s) within the appropriate IETF Consensus rules, and
corresponding updates to the specification citation in the header
registration.)
4.6. Comments on Header Definitions
Comments on proposed registrations should be sent to the designated
email discussion list [33].
4.7. Location of Header Field Registry
The message header field registry is accessible from IANA's web site
http://www.iana.org/assignments/message-headers/
message-header-index.html
5. IANA Considerations
This specification calls for:
o A new IANA registry for permanent message header fields per
Section 4 of this document. The policy for inclusion in this
registry is described in Section 4.1 and Section 4.2.1.
o A new IANA repository listing provisional message header fields
per Section 4 of this document. The policy for inclusion in this
registry is described in Section 4.1 and Section 4.2.2.
o IESG appoints a designated expert to advise IANA whether
registration criteria for proposed registrations have been
satisfied.
No initial registry entries are provided.
6. Security Considerations
No security considerations are introduced by this specification
beyond those already inherent in the use of message headers.
Klyne, et al. Best Current Practice [Page 12]
RFC 3864 Header Field Registration September 2004
7. Acknowledgements
The shape of the registries described here owes much to energetic
discussion of previous versions by many denizens of the IETF-822
mailing list.
The authors also gratefully acknowledge the contribution of those who
provided valuable feedback on earlier versions of this memo: Charles
Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle
Cotton.
8. References
8.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
8.2. Informative References
[5] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", RFC 1036, December 1987.
[6] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the messages", RFC 1496, August
1993.
[7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header
Field for Internet Messages", RFC 1505, August 1993.
[8] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864,
October 1995.
[10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
Klyne, et al. Best Current Practice [Page 13]
RFC 3864 Header Field Registration September 2004
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[13] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[15] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting
for HTTP", RFC 2227, October 1997.
[17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", RFC
2231, November 1997.
[18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
Notification", RFC 3798, May 2004.
[19] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message
Header Fields", RFC 2369, July 1998.
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
version 2 (VPIMv2)", RFC 3801, June 2004.
[22] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518,
February 1999.
[23] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME
Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC
2557, March 1999.
Klyne, et al. Best Current Practice [Page 14]
RFC 3864 Header Field Registration September 2004
[24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[25] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[27] Klyne, G., "Indicating Media Features for MIME Content", RFC
2912, September 2000.
[28] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists", RFC 2919,
March 2001.
[29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
RFC 2965, October 2000.
[30] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[32] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
Recommendation xml, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[33] "Mail address for announcement of new header field submissions",
Mail address: ietf-message-headers@lists.ietf.org
[34] "Mail address for subscription to ietf-message-
headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO
THE MAILING LIST ITSELF)", Mail address: ietf-message-headers-
request@lists.ietf.org
[35] "Mail address for submission of new header field templates",
Mail address: iana@iana.org
Klyne, et al. Best Current Practice [Page 15]
RFC 3864 Header Field Registration September 2004
9. Authors' Addresses
Graham Klyne
Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Mark Nottingham
BEA Systems
235 Montgomery St.
Level 15
San Francisco, CA 94104
USA
EMail: mnot@pobox.com
Jeffrey C. Mogul
HP Labs
1501 Page Mill Road
Palo Alto, CA 94304
US
EMail: JeffMogul@acm.org
Klyne, et al. Best Current Practice [Page 16]
RFC 3864 Header Field Registration September 2004
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Klyne, et al. Best Current Practice [Page 17]