Рабочая группа сети M. Mealling
Запрос комментариев: 3553 VeriSign
BCP: 73 L. Masinter
Категория: Лучшая современная практика Adobe Systems
T. Hardie
Qualcomm
G. Klyne
Nine by Nine
Июнь 2003
Подпространство имён IETF URN для зарегистрированных параметров протоколов
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение данного меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (2003). All Rights Reserved.
Аннотация
Этот документ описывает новое подделегирование для пространства имён
URN «ietf» для зарегистрированных элементов протоколов. Пространство
имён URN «ietf» определено в RFC 2648 как корень для постоянных URI,
которые ссылаются на ресурсы, определённые IETF.
1. Введение
Время от времени стандарты IETF требуют регистрации различных
элементов протоколов в общеизвестном центральном репозитории.
Internet Assigned Numbers Authority поддерживает этот центральный
репозиторий и получает от IETF указания о том, что, как и когда
добавлять в него. IANA ведёт перечни таких элементов, как все
назначенные номера портов, типы носителей MIME, номера предприятий и
т. д.
Со временем возникла необходимость иметь возможность ссылаться на эти
элементы как на URI в различных схемах. В прошлом это делалось очень
специальным образом, что легко приводило к проблемам совместимости.
Этот документ создаёт новое подделегирование в пространстве имён URN
«ietf» [2] [1] с именем «params», которое действует как
стандартизованный механизм именования элементов, зарегистрированных
для стандартов IETF. Любые назначения ниже него, указанные в RFC в
соответствии с процессом достижения консенсуса IETF и включающие
шаблон, приведённый в разделе 4.
2. Терминология
Ключевые слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT»,
«SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY» и «OPTIONAL» в данном
документе подлежат толкованию, описанному в RFC 2119.
3. Особенности подпространства имён IETF
Имя подпространства имён:
params
Заявленный регистрант пространства имён:
The Internet Engineering Task Force
Описание структуры:
Пространство имён является преимущественно непрозрачным. IANA как
оператор реестра может принимать предложения по именам для
назначения, но оставляет за собой право назначить любое имя по
своему усмотрению в рамках руководящих принципов, установленных
IESG. Символ двоеточия («:») используется для обозначения весьма
ограниченного понятия иерархии. Если присутствует двоеточие, то
элементы по обе его стороны являются допустимыми именами. В общем
случае, если имя содержит двоеточие, то элемент в левой части
представляет класс тех элементов, который включал бы другие
элементы этого класса. Например, имя может быть назначено всему
списку кодов типов записей ресурсов DNS, а также каждому отдельному
коду. URN для списка может выглядеть так:
urn:ietf:params:dns:rr-type-codes
тогда как URN для кода типа записей SOA может выглядеть так:
urn:ietf:params:dns:rr-type-codes:soa
Релевантная вспомогательная документация:
[3], [2], [1]
Вопросы уникальности идентификаторов:
IESG использует процесс достижения консенсуса IETF для обеспечения
того, чтобы подпространства имён создавали уникальные имена внутри
соответствующего подпространства имён. IESG делегирует IANA задачу
обеспечения уникальности самих имён подпространств имён. До тех
пор, пока IESG не определит иное, IANA предписывается обеспечивать
уникальность путём сравнения назначаемого имени с перечнем ранее
назначенных имён. В случае конфликта IANA должна запрашивать у
регистранта новую строку до разрешения конфликта.
Вопросы постоянства идентификаторов:
После выделения имени оно НЕ ДОЛЖНО (MUST NOT) выделяться повторно
для иной цели. Правила, предусмотренные для назначения значений в
пределах подпространства имён, ДОЛЖНЫ (MUST) быть построены так,
чтобы смысл значений не мог изменяться. Этот механизм регистрации
не подходит для именования значений, смысл которых может меняться
со временем. Если значение изменяется со временем, назначение
ДОЛЖНО (MUST) именовать контейнер или понятие, содержащее это
значение, а не само значение. Например, если параметр с именем
«foo» имеет значение, изменяющееся со временем, допустимо создать
имя «urn:ietf:params:foo-params:foo», идентифицирующее этот «слот».
Недопустимо фактически создавать имя, содержащее это значение, если
только оно не является постоянным и уникальным значением, таким как
номер версии.
Процесс назначения идентификаторов:
Идентификаторы назначаются только после регистрации конкретного
элемента протокола или номера в IANA с применением стандартных
политик и процедур либо после документирования в RFC, описывающем
протокол на пути стандартизации. Это означает, что функцией
«допуска» для назначения является процесс «консенсус IETF»,
документированный в RFC 2434 [4].
Процесс разрешения идентификаторов:
На данный момент механизм разрешения не определён.
Правила лексической эквивалентности:
Лексическая эквивалентность достигается точным сопоставлением
строк в соответствии с правилами синтаксиса URN, приведёнными в
RFC 2141 [1]. В частности, вследствие определений синтаксиса URN
стандарт «stringprep», приведённый в RFC 3454 [7], не применяется.
Соответствие синтаксису URN:
Дополнительные символы не зарезервированы.
Механизм проверки:
Отсутствует.
Область действия:
Глобальная
4. Назначение имён
Создание нового имени реестра будет простым для большинства плоских
реестров. Единственными обязательными элементами будут имя реестра,
ссылка на релевантные документы, утверждение о том, какие текущие или
предполагаемые репозитории документов содержат авторитетные данные для
реестра, и утверждение, определяющее, какой элемент реестра является
значением, используемым в URN. В большинстве случаев этим последним
элементом будет индексное значение, назначенное IANA.
Более сложным реестрам (например, параметрам DNS) потребуется
повторить эту информацию для всех подпространств имён. Также должно
быть ясно, назначается ли имя самому подпространству имён (то есть,
является ли «urn:ietf:params:dns:rr-types» само по себе допустимым и,
если да, что оно именует?).
Шаблон:
Имя реестра: -- Имя подпространства имён. Во многих случаях это должно
быть то же имя, которым IANA называет сам реестр.
Спецификация: -- Релевантные опубликованные IETF документы, которые
определяют реестр и его элементы.
Репозиторий: -- Указатель на «текущее» расположение реестра в
репозитории параметров протоколов или на релевантные RFC, которые
документируют именуемые элементы. Это значение будет меняться со
временем по мере того, как организация, поддерживающая репозиторий,
перемещает файлы и/или файловые серверы. Оно не предназначено как
постоянная привязка к имени файла, а служит IANA подсказкой о том,
каким будет первоначальное сопоставление.
Индексное значение: -- Описание того, как зарегистрированное значение
должно быть встроено в форму URI. Оно ДОЛЖНО (MUST) включать
подробности всех преобразований, которые могут потребоваться, чтобы
полученная строка соответствовала правилам синтаксиса URN, а также
любую канонизацию, необходимую для того, чтобы чувствительное к
регистру сравнение строк давало ожидаемые эквивалентности.
Процесс запроса назначения URN в настоящее время состоит в помещении
приведённого выше шаблона или ссылки на него в раздел соображений IANA
определяющего документа. Иные, более автоматизированные процессы могут
быть предложены позднее, если этого потребует спрос.
5. Соображения безопасности
Нет иных, помимо уже присущих использованию URN. Соображения
безопасности для URN в целом можно найти в RFC 2141 [1]. Дополнительные
соображения безопасности для одного конкретного метода разрешения URN
можно найти в Dynamic Delegation Discovery System (DDDS) Part Four:
The Uniform Resource Identifiers (URI) Resolution Application (RFC
3404) [5], который является частью серии, начинающейся с Dynamic
Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS
(RFC 3401) [6].
6. Соображения IANA
Этот документ возлагает на IANA новое и существенное бремя, поскольку
для каждого нового реестра IANA может потребоваться дополнительный
процесс назначения. Чтобы минимизировать административную нагрузку на
IANA, регистрация любого пространства имён параметров предельно ясно
определяет критерии включения в это пространство имён.
Определение реестра, соответствующего ограничениям пространства имён
URN, потребует дополнительной дисциплины, которая должна снять часть
неопределённости при создании и поддержании такого реестра.
7. Заявление об интеллектуальной собственности
IETF не занимает позиции относительно действительности или объёма
какой-либо интеллектуальной собственности либо иных прав, которые могут
заявляться как относящиеся к реализации или использованию технологии,
описанной в данном документе, либо относительно того, может или не
может быть доступна какая-либо лицензия по таким правам; также IETF не
заявляет, что предпринял какие-либо усилия для выявления подобных прав.
Информацию о процедурах IETF в отношении прав в документации на пути
стандартизации и связанной со стандартами документации можно найти в
BCP-11. Копии заявлений о правах, предоставленных для публикации, и
любые гарантии предоставления лицензий либо результат попытки получить
общую лицензию или разрешение на использование таких имущественных прав
реализаторами или пользователями данной спецификации можно получить у
Секретариата IETF.
IETF приглашает любую заинтересованную сторону довести до его сведения
любые авторские права, патенты или заявки на патенты либо иные
имущественные права, которые могут охватывать технологию, которая может
требоваться для практического применения этого стандарта. Просьба
направлять эту информацию Исполнительному директору IETF.
8. Нормативные ссылки
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[3] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
February 2002.
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, May 2002.
[7] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002.
9. Адреса авторов
Michael Mealling
VeriSign
21345 Ridgetop Circle
Sterling, VA 20166
US
EMail: michael@verisignlabs.com, michael@neonym.net
URI: http://www.verisign.com
Larry Masinter
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
US
Phone: +1 408 536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Ted Hardie
Qualcomm, Inc.
675 Campbell Technology Parkway
Suite 200
Campbell, CA
U.S.A.
EMail: hardie@qualcomm.com
Graham Klyne
Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
10. Полное заявление об авторском праве
Copyright (C) The Internet Society (2003). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему,
иным образом разъясняющие его или содействующие его реализации,
могут подготавливаться, копироваться, публиковаться и распространяться
полностью или частично без каких-либо ограничений при условии, что
приведённое выше уведомление об авторском праве и этот абзац включены
во все такие копии и производные работы. Однако сам этот документ
не может изменяться каким бы то ни было образом, например путём
удаления уведомления об авторском праве или ссылок на Internet Society
либо другие организации Интернета, за исключением изменений, необходимых
для разработки стандартов Интернета, в каковом случае должны соблюдаться
процедуры в отношении авторских прав, определённые в процессе разработки
стандартов Интернета, или изменений, требуемых для перевода документа на
языки, отличные от английского.
Выданные выше ограниченные разрешения являются бессрочными и не будут
отозваны Internet Society или её правопреемниками либо цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ,
ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ
ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.
Благодарности
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.