RFC 8141 | Унифицированные имена ресурсов (URN)

Оригинальный документ RFC 8141

 

Аннотация

Унифицированное имя ресурса (URN) — это унифицированный идентификатор ресурса (URI), который назначается по схеме URI «urn» и определенному пространству имен URN с намерением, чтобы URN был постоянным, независимым от местоположения идентификатором ресурса. Что касается синтаксиса URN, этот документ определяет канонический синтаксис для URN (способом, совместимым с синтаксисом URI), определяет методы определения URNequivalence и обсуждает соответствие URI. Что касается пространств имен URN, этот документ определяет метод определения пространства имен URN и связывания его с идентификатором пространства имен, а также описывает процедуры регистрации идентификаторов пространства имен в Управлении по назначению номеров в Интернете (IANA). Из-за этого документа устарели [RFC2141 #] и [RFC3406 #].

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 [RFC7841 #].

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc8141.

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

Copyright (c) 2017 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

Оглавление

1. Введение
1.1. Терминология
1.2. Компромиссы дизайна
1.2.1. Разрешение
1.2.2. Наборы символов и кодировки
2. Синтаксис URN
2.1. Идентификатор пространства имен (NID)
2.2. Специфичная строка пространства имен (NSS)
2.3. Дополнительные компоненты
2.3.1. r-компонент
2.3.2. q-компонент
2.3.3. f-компонент
3. URN-эквивалентность
3.1. Процедура
3.2. Примеры
4. Соответствие URI
4.1. Использование в слотах протокола URI
4.2. Анализ
4.3. URNs и относительные ссылки
4.4. Транспорт и Дисплей
4.5. URI Дизайн и Владение
5. Пространства имен URN
5.1. Формальные пространства имен URN
5.2. Неформальные пространства имен URN
6. Определение и регистрация пространства имен URN
6.1. Обзор
6.2. Политика и процесс регистрации: регистрация сообщества
6.3. Политика и процесс регистрации: ускоренный путь для организаций по разработке стандартов, научных обществ и аналогичных органов
6.4. Заполнение шаблона
6.4.1. Цель
6.4.2. Синтаксис
6.4.3. Присваивание
6.4.4. Безопасность и конфиденциальность
6.4.5. Взаимодействие
6.4.6. Разрешение
6.4.7. Дополнительная информация
7. Соображения IANA
7.1. Схема URI
7.2. Регистрация пространств имен URN
7.3. Список обсуждений для новых и обновленных регистраций NID
8. Вопросы безопасности и конфиденциальности
9. Ссылки
9.1. Нормативные ссылки
9.2. Информационные ссылки
Приложение А. Шаблон регистрации
Приложение B. Изменения по сравнению с RFC 2141
B.1. Изменения синтаксиса от RFC 2141
B.2. Другие изменения из RFC 2141
Приложение C. Изменения по сравнению с RFC 3406
Благодарности
Авторы
Адреса авторов

 

1. Введение

Унифицированное имя ресурса (URN) — это Унифицированный идентификатор ресурса (URI) [RFC3986 #], который назначается в схеме URI «urn» и определенном пространстве имен URN с намерением, чтобы URN был постоянным, независимым от местоположения идентификатором ресурса. Пространство имен URN — это набор таких URN, каждый из которых (1) уникален, (2) назначен согласованным и управляемым способом и (3) назначен в соответствии с общим определением. (Некоторые пространства имен URN создают имена, которые существуют только как URN, тогда как другие назначают URN на основе имен, которые уже были созданы в системах идентификаторов не-URN, таких как ISBN [RFC3187 #], ISSN [RFC3044 #] или RFC [RFC2648 #].)

Назначение URN осуществляется организацией (или, в некоторых случаях, согласно алгоритму или другому автоматизированному процессу), которой официально делегировано пространство имен URN в схеме «urn» (например, URN в «примерном» URN). пространство имен [RFC6963 #] может иметь форму «urn: example: foo»).

Этот документ основывается на двух ключевых предположениях:

1. Назначение URN является управляемым процессом
2. Пространство пространств имен URN само управляется

В то время как другие схемы URI могут позволять свободно выбирать и назначать идентификаторы ресурсов, это не относится к URN. Синтаксическая правильность имени, начинающегося с «urn:», недостаточна, чтобы сделать его URN. Чтобы имя было действительным URN, идентификатор пространства имен (NID) должен быть зарегистрирован в соответствии с правилами, определенными здесь, а остальные части части с присвоенным именем URN должны быть сгенерированы в соответствии с правила для зарегистрированного пространства имен URN.

Чтобы информация как о синтаксисе URN, так и о пространствах имен URN была доступна в одном месте, этот документ выполняет следующие действия:

1. Определяет канонический синтаксис для URN в целом (способом, который согласуется с синтаксисом URI), определяет методы для определения URN-эквивалентности и обсуждает соответствие URI.
2. Определяет метод определения пространства имен URN и связывания его с конкретным NID, а также описывает процедуры регистрации NID URN в Управлении по присвоению номеров в Интернете (IANA).

Для синтаксиса URN и пространств имен URN этот документ модернизирует и заменяет исходные спецификации для синтаксиса URN [RFC2141 #] и для определения и регистрации пространств имен URN [RFC3406 #]. Эти модификации основаны на ключевых требованиях, представленных в оригинальном функциональном описании для URN [RFC1737 #], и на уроках многолетнего опыта. В этих исходных документах и ​​в настоящем документе цель состоит в том, чтобы определять URN согласованным образом, чтобы, где это практически возможно, анализ, обработка и разрешение URN могли быть независимыми от пространства имен URN, в котором назначен данный URN.

Вместе с вкладом нескольких ключевых сообществ пользователей история и опыт использования URN продиктовали расширение определения URN для поддержки новых функций, включая использование синтаксиса, явно зарезервированного для будущей стандартизации в [RFC2141 #]. Все пространства имен URN и URN, которые были действительны в соответствии с более ранние спецификации остаются в силе, хотя может быть полезно обновить определения некоторых пространств имен URN, чтобы воспользоваться преимуществами новых функций.

Приведенные выше соображения вместе с различными различиями между URN и URI, которые являются локаторами (в частности, URL-адресами), а также с большим вниманием к URL-адресам в RFC 3986 в качестве окончательного преемника [RFC1738 #] и [RFC1808 #], могут привести к некоторым интерпретациям RFC 3986, и эта спецификация, которая появляется (или, возможно, фактически), не полностью согласована, особенно в отношении действий или семантики, отличных от самого основного синтаксиса. Если возникают такие ситуации, обсуждения URN и пространств имен URN должны интерпретироваться в соответствии с этим документом, а не путем экстраполяции из RFC 3986.

Сводка изменений из RFC 2141 и RFC 3406 приведена в Приложениях B и C соответственно. Этот документ сделал устаревшими, как [RFC2141 #], так и [RFC3406 #]. Хотя он явно не обновляет или не заменяет [RFC1737 #] или [RFC2276 #], читатель, ссылающийся на эти документы, должен знать, что концептуальная модель URN в этом документе немного отличается от этих более старых спецификаций.

1.1. Терминология

Следующие термины отличаются друг от друга, как описано ниже:

URN

URI (как определено в RFC 3986) с использованием схемы «urn» и со свойствами «name», как описано в этом документе, а также со свойствами, описанными в этом. Термин применяется ко всему URI, включая его необязательные компоненты. Примечание для читателя: термин «URN» использовался в других контекстах для обозначения пространства имен URN, идентификатора пространства имен, назначенного имени и URI, которые не используют схему «urn». Все, кроме последнего, описаны с использованием более конкретной терминологии в другом месте этого документа, но из-за этих других применений этот термин следует использовать и интерпретировать с осторожностью.

Locator (Локатор)

Идентификатор, который предоставляет средства доступа к ресурсу.

Identifier system (Система идентификаторов)

Управляемая коллекция имен. Этот документ ссылается на системы идентификаторов вне контекста URN как на «системы идентификаторов не-URN».

URN namespace (Пространство имен URN)

Система идентификаторов, связанная с NID URN.

NID

Идентификатор, связанный с пространством имен URN.

NSS

Специфичная для пространства имен URN часть URN.

Assigned-name (Назначенное имя)

Комбинация схемы «urn:», NID и конкретной строки пространства имен (NSS). Следовательно, «назначенное имя» является подстрокой URN (как определено выше), если эта URN содержит какие-либо дополнительные компоненты (см. Раздел 2).

Термин «имя» здесь намеренно не определен и должен (и на практике используется) только очень неформально. RFC 3986 использует этот термин в качестве категории URI, отличной от «локатора» (раздел 1.1.3), но также использует его в других контекстах. Если эти виды использования рассматриваются как определения, они будут конфликтовать, например, с идеей имен пространств имен URN (то есть NID) и с терминами, связанными с системами идентификаторов не-URN.

В этом документе термины «ресурс» (resource), «идентификатор» (identifier), «идентификация» (identify),«разыменование» (dereference), «представление» (representation) и «метаданные» (metadata) используются примерно так, как определено в спецификации URI [RFC3986 #].

В этом документе термины «разрешение» (resolution) и «распознаватель» (resolver) используются примерно в том смысле, в котором они использовались в первоначальном обсуждении архитектурных принципов для URN [RFC2276 #], т. е. «Разрешение» — это акт предоставления услуг, связанных с идентифицированным ресурсом. например, преобразование постоянного URN в один или несколько текущих локаторов для ресурса, доставку метаданных о ресурсе в соответствующем формате или даже доставку представления ресурса (например, документа) без дополнительных посредников. На момент написания этой статьи службы разрешения описаны в [RFC2483 #].

О разнице между представлениями и метаданными смотри Раздел 1.2.2 [RFC3986 #].

Несколько других терминов, относящихся к операциям «нормализации», которые не являются частью стандарта Unicode [UNICODE], также используются здесь, как и в RFC 3986.

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

1.2. Компромиссы дизайна

В гораздо большей степени, чем при первом рассмотрении URN и обрисовке их использования (см. [RFC1737 #]), проблемы постоянных идентификаторов в Интернете связаны с фундаментальными компромиссными решениями, которые намного шире, чем URN или подход URN, и даже касаются открытого исследовательские вопросы в сообществе информатики. Идеальные и исчерпывающие спецификации о том, что должно быть сделано или требуется во всей вселенной URN, потребуют общего согласия и решения широкого спектра таких проблем. Хотя некоторые из этих проблем были вызваны подходами Интернета или компьютерного века к кодированию символов и абстракции данных, другие предшествовали Интернету и компьютерным системам на века; вряд ли в ближайшем будущем будет достигнуто соглашение о всеобъемлющих решениях.

Хотя эта спецификация, следовательно, содержит некоторые требования и гибкость, которых не было бы в более совершенном мире, это было необходимо для создания согласованной спецификации, которая предоставляет модернизированное определение URN (непривлекательной альтернативой было бы не модернизировать определение несмотря на широкое распространение).

В следующих подразделах более подробно описаны два соответствующих вопроса.

1.2.1. Разрешение

Одной из проблем, специфичных для URN (в отличие от систем именования в целом), является довольно сложная тема «разрешения», которая обсуждается в разделах 1.1, 2.3.1, 6.4.6 и других местах ниже.

С традиционными унифицированными локаторами ресурсов (URL), т. е. с большинством URI, которые являются локаторами, разрешение является относительно простым, поскольку оно используется для определения механизма доступа, который, в свою очередь, используется для разыменования локатора путем (обычно) извлечения представления ассоциированного ресурс, такой как документ (см. Раздел 1.2.2 [RFC3986 #]).

Напротив, разрешение для URN является более гибким и разнообразным.

Один важный случай связан с отображением URN в один или несколько локаторов. В этом случае конечный результат все еще является вопросом разыменования сопоставленного локатора (ов) в одно или несколько представлений. Основным отличием здесь является постоянство: даже если сопоставленный локатор изменился (например, имя домена DNS перешло к другому владельцу, а URL-адрес не был изменен для указания нового местоположения или, в более экстремальном и гипотетическом случае, DNS является замененный полностью), пользователь URN сможет получить правильное представление (например, документ), если распознаватель постоянно обновляет свои сопоставления URN-to-locator. Следовательно, соответствующие отношения могут быть определены довольно точно для URN, которые разрешаются в локаторы, которые в свою очередь разыменовываются в представление.

Однако эта спецификация допускает несколько других случаев разрешения URN, а также URN для ресурсов, которые не связаны с системами поиска информации. Это верно либо для отдельных URN, либо (как определено ниже) для всех пространств имен URN.

Рассмотрим пространство имен URN, которые разрешаются локаторам, которые в свою очередь разыменовываются только к метаданным о ресурсах, поскольку базовые системы не содержат представлений этих ресурсов; примером может быть пространство имен URN для международных стандартных идентификаторов имен (ISNI), поскольку эта система идентификаторов определена в соответствующем стандарте [ISO.27729.2012], где по умолчанию URN разрешается только в запись метаданных, описывающую общедоступный идентификатор, идентифицируемый ISNI.

Рассмотрим также URN, которые разрешают представления, только если запрашивающий объект авторизован для получения представления, тогда как другие объекты могут получать только метаданные о ресурсе; примером могут служить документы, хранящиеся в легальной депозитарной коллекции национальной библиотеки.

Наконец, некоторые URN могут вообще не предназначаться для разрешения локаторам; примеры могут включать URN, идентифицирующие имена пространства имен XML (например, пространство имен URN «dgiwg», указанное в [RFC6288 #]), URN, идентифицирующие функции приложения, которые могут поддерживаться в протоколе связи (например, пространство имен URN «alert», указанное в [RFC7462 #] ) и URN, идентифицирующие перечисляемые типы, такие как значения в реестре (например, пространство имен URN может использоваться для индивидуальной идентификации значений во всех реестрах IANA, как предварительно предложено в [IANA-URN]).

Различные типы URN и сервисы с множественным разрешением, которые могут быть доступны для них, оставляют концепцию «разрешения» более сложной, но также гораздо более богатой для URN, чем простой случай разрешения для локатора, который разыменовывается в представление.

1.2.2. Наборы символов и кодировки

Аналогичный набор соображений применяется к наборам символов и кодировкам. URN, особенно URN, которые будут использоваться в качестве идентификаторов, ориентированных на пользователя, должны быть удобны для использования на местных языках и в системах письменности, легко задаваться с помощью широкого диапазона клавиатур и локальных соглашений и быть однозначными. Между этими целями есть компромиссы, и в настоящее время невозможно увидеть, как можно разработать простой и понятный набор правил, который был бы оптимальным или даже разумным для всех URN. Обсуждение в разделе 2.2 определяет общую структуру, которая должна сделать возможным общий анализ и обработку, а также дает рекомендации по правилам для отдельных пространств имен URN.

2. Синтаксис URN

Как обсуждалось выше, синтаксис для URN в этой спецификации обеспечивает значительно большую функциональность, чем это было в более ранних спецификациях, совсем недавно [RFC2141 #]. Он также согласован с общим синтаксисом URI [RFC3986 #] (который, следует отметить, был завершен после более ранних спецификаций URN).

Однако эта спецификация не расширяет синтаксис URN, чтобы разрешить прямое использование символов вне диапазона ASCII [RFC20 #]. Это ограничение подразумевает, что любые такие символы необходимо кодировать в процентах, как описано в разделе 2.1 из спецификации URI [RFC3986].

Основной синтаксис для URN определяется с использованием расширенной формы Бэкуса-Наура (ABNF), как указано в [RFC5234 #]. Правила, не определенные здесь (в частности: alphanum, фрагмент и pchar), определены как часть синтаксиса URI [RFC3986 #] и используются здесь, чтобы указать на синтаксическую связь с используемыми там терминами. Определения некоторых терминов, используемых ниже, не являются исчерпывающими; дополнительные ограничения налагаются прозой, которую можно найти в разделах этого документа, относящихся к этим терминам (особенно r-компонент в разделе 2.3.1 и q-компонент в разделе 2.3.2).

namestring = assigned-name
[ rq-components ]
[ «#» f-component ]
assigned-name = «urn» «:» NID «:» NSS
NID = (alphanum) 0*30(ldh) (alphanum)
ldh = alphanum / «-»
NSS = pchar *(pchar / «/»)
rq-components = [ «?+» r-component ]
[ «?=» q-component ]
r-component = pchar *( pchar / «/» / «?» )
q-component = pchar *( pchar / «/» / «?» )
f-component = fragment

Знак вопроса «?» может использоваться без процентного кодирования внутри r-компонентов, q-компонентов и f-компонентов. Кроме внутри этих компонентов, «?» за ним не следует сразу после «=» или «+», он не определен для URN и должен рассматриваться как синтаксическая ошибка специфичными для URN синтаксическими анализаторами и другими процессорами.

В следующих разделах представлена дополнительная информация о синтаксических элементах URN.

2.1. Идентификатор пространства имен (NID)

NID нечувствительны к регистру (например, «ISBN» и «isbn» эквивалентны).

Символы вне диапазона ASCII [RFC20 #] недопустимы в NID, и механизм кодирования для таких символов не поддерживается.

Разделы 5.1 и 5.2 накладывают дополнительные ограничения на строки, которые могут использоваться в качестве NID, то есть приведенный выше синтаксис не является исчерпывающим.

2.2. Специфичная строка пространства имен (NSS)

NSS — это строка, уникальная в пространстве имен URN, которая назначается и управляется согласованным образом и соответствует определению соответствующего пространства имен URN. Сочетание NID (уникального для всей схемы «urn») и NSS (уникального в пространстве имен URN) гарантирует, что результирующий URN будет глобально уникальным.

NSS, как указано в этом документе, допускает использование нескольких символов, не разрешенных предыдущими спецификациями (см. Приложение B). В частности, символ «/», который теперь разрешен, эффективно позволяет инкапсулировать иерархические имена из систем идентификаторов не-URN. Например, рассмотрим гипотетический пример системы иерархических идентификаторов, в которой имена принимают форму последовательности чисел, разделенных символом «/», например «1/406/47452/2». Если полномочия для таких имен должны были использовать URN, было бы естественно поместить существующее имя в NSS, что приведет к URN, таким как «urn: пример: 1/406/47452/2».

Эти изменения в синтаксисе для NSS не изменяют правила кодирования для пространств имен URN, которые были определены в соответствии с [RFC2141]. Если любое такое пространство имен URN, чьи имена используются вне контекста URN (т. Е. В системе идентификаторов, отличных от URN), также позволяет использовать «/», «~» или «&» в собственной форме в этой системе идентификаторов , тогда правила кодирования для этого пространства имен URN не изменяются этой спецификацией.

В зависимости от правил, регулирующих систему идентификаторов, отличных от URN, и связанного с ней пространства имен URN, имена, действительные в этой системе идентификаторов, могут содержать символы, которые не разрешены продукцией «pchar», упомянутой выше (например, символы вне диапазона ASCII или в соответствии с ограничениями в RFC 3986, символы «/», «?», «#», «[» и «]»). Хотя такое имя может быть допустимым в системе идентификаторов не-URN, оно не является действительным URN, пока оно не будет преобразовано в NSS, который соответствует правилам этого конкретного пространства имен URN. В случае URN, которые сформированы из имен, которые существуют отдельно в системе идентификаторов не-URN, преобразование имени из его «собственного» формата в формат URN выполняется с использованием методов канонизации и кодирования, определенных для URN в целом, или конкретные правила для этого пространства имен URN. Программное обеспечение, которое не знает о правилах канонизации и кодирования, специфичных для пространства имен, НЕ ДОЛЖНО создавать URN из имени в системе идентификаторов, не относящихся к URN.

В частности, что касается символов вне диапазона ASCII, URN, которые появляются в протоколах или передаются между системами, ДОЛЖНЫ использовать только символы Unicode, закодированные в UTF-8 и дополнительно закодированные в соответствии с требованиями RFC 3986. В той степени, в которой это возможно и согласуется с требования к именам, определенным и стандартизированным в других местах, а также принципы, обсуждаемые в разделе 1.2, символы, используемые для представления имен, ДОЛЖНЫ быть ограничены либо буквами и цифрами ASCII, либо символами и синтаксисом некоторых широко используемых моделей, таких как модели интернационализирующего домена Имена в приложениях (IDNA) [RFC5890], подготовка, применение и сравнение интернационализированных строк (PRECIS) [RFC7613] или спецификация идентификатора Unicode и синтаксиса шаблона [UAX31].

Чтобы сделать URN настолько стабильными и постоянными, насколько это возможно, при развитии протоколов и изменении среды вокруг них, пространства имен URN НЕ ДОЛЖНЫ разрешать символы вне диапазона ASCII [RFC20], если только природа конкретного пространства имен URN не делает такие символы необходимыми.

2.3. Дополнительные компоненты

Эта спецификация включает три дополнительных компонента в синтаксисе URN. Они известны как r-компонент, q-компонент и f-компонент и более подробно описаны ниже. Поскольку эта спецификация фокусируется почти исключительно на синтаксисе URN, она не определяет детальную семантику этих компонентов для URN в целом. Однако каждый из этих компонентов играет отдельную роль, которая не зависит от какой-либо данной URN и его пространства имен URN. Предполагается, что клиенты смогут обрабатывать эти компоненты единообразно для всех URN. Эти компоненты МОГУТ использоваться с URN из существующих пространств имен URN, независимо от того, поддерживает ли пространство имен URN их явно. Однако в соответствии с подходом, принятым в RFC 3986, поведение URN, которое содержит компоненты, которые не определены или не имеют смысла для конкретного пространства имен или ресурса URN, не определено. В следующих разделах описываются эти дополнительные компоненты и их интерпретация более подробно.

2.3.1. r-компонент

R-компонент предназначен для передачи параметров службам разрешения URN (в широком смысле см. Раздел 1.2) и интерпретируется этими службами. (В отличие от этого, передача параметров ресурсам, идентифицированным URN, или приложениям, которые управляют такими ресурсами, обрабатывается q-компонентами, как описано в следующем разделе.)

R-компонент URN не имеет синтаксического аналога в любой другой известной схеме URI.

Последовательность «? +» Вводит r-компонент. R-компонент заканчивается последовательностью «? =» (Которая начинается с q-компонента) или символом «#» (знак числа, который начинается с f-компонента). Если ни один из них не появляется, r-компонент продолжается до конца URN. Обратите внимание, что символы вне диапазона ASCII [RFC20] ДОЛЖНЫ быть кодированы в процентах с использованием метода, определенного в разделе 2.1 общей спецификации URI [RFC3986].

Как описано в разделе 3, r-компонент НЕ ДОЛЖЕН учитываться при определении URN-эквивалентности. Однако r-компонент ДОЛЖЕН быть предоставлен вместе с URN при представлении запроса службе разрешения URN.

Этот документ определяет только синтаксис r-компонента и резервирует его для будущего использования. Точная семантика r-компонента и его использование в протоколах разрешения URN являются предметом потенциальной стандартизации в отдельных спецификациях, предположительно включая спецификации, которые определяют соглашения, и реестр для идентификаторов службы разрешения.

Рассмотрим гипотетический пример передачи параметров в службу разрешения (скажем, код страны альфа-2 ИСО [ISO.3166-1], чтобы выбрать предпочитаемую страну, в которой нужно искать физическую копию книги). Возможно, это можно сделать, указав код страны в r-компоненте, что приведет к появлению таких URN, как:

urn:example:foo-bar-baz-qux?+CCResolve:cc=uk

Хотя вышеприведенное должно служить общим объяснением и иллюстрацией намерения для r-компонентов, с ними связано много открытых вопросов, включая их связь с механизмами разрешения, связанными с конкретным пространством имен URN во время регистрации. Таким образом, r-компоненты НЕ ДОЛЖНЫ использоваться для URN до стандартизации их семантики.

2.3.2. q-компонент

Компонент q предназначен для передачи параметров либо названному ресурсу, либо системе, которая может предоставить запрашиваемую услугу, для интерпретации этим ресурсом или системой. (В отличие от этого, передача параметров в службы разрешения URN обрабатывается r-компонентами, как описано в предыдущем разделе.)

Q-компонент URN имеет тот же синтаксис, что и компонент запроса URI, но вводится как «? =», А не «?» в одиночестве. Для URN, который может быть преобразован в URI, который является локатором, семантика q-компонента идентична семантике для компонента запроса этого URI. Таким образом, распознаватели URN, возвращающие URI, который является локатором для URN с q-компонентом, делают это путем копирования q-компонента из URN в компонент запроса URI. Пример операции копирования приведен ниже.

Эта спецификация не определяет обязательное поведение в случае разрешения URN в URI, который является локатором, когда исходный URN имеет q-компонент, а URI имеет строку запроса. Различные обстоятельства могут потребовать разных подходов. Решатели ДОЛЖНЫ задокументировать свою стратегию в таких случаях.

Если URN не преобразуется в URI, который является локатором, интерпретация q-компонента не определена этой спецификацией. Для URN, которые могут быть преобразованы в URI, который является локатором, семантика q-компонента идентична таковой для запросов к ресурсу, расположенному через этот URI.

В целях соответствия RFC 3986 общий синтаксис и семантика q-компонентов не определяются пространством имен URN URN и не зависят от него. Параллельно с RFC 3986, особенности синтаксиса и семантики, например, какие ключевые слова или термины являются значимыми, конечно, могут зависеть от конкретного пространства имен URN или даже от конкретного ресурса.

Последовательность «? =» Вводит q-компонент. Q-компонент заканчивается символом «#» (знак числа, начинающийся с f-компонента). Если этот символ не появляется, q-компонент продолжается до конца URN. Косая черта («/») и знак вопроса («?») Могут представлять данные в компоненте q. Обратите внимание, что символы вне диапазона ASCII [RFC20] ДОЛЖНЫ быть кодированы в процентах с использованием метода, определенного в разделе 2.1 общей спецификации URI [RFC3986].

Как описано в разделе 3, q-компонент НЕ ДОЛЖЕН учитываться при определении URN-эквивалентности.

Пространства имен URN и соответствующее размещение информации в синтаксисе СЛЕДУЕТ спроектировать так, чтобы избежать необходимости в службе разрешения для учета q-компонента. Специфичные для пространства имен и более общие системы разрешения НЕ ДОЛЖНЫ требовать, чтобы информация q-компонента передавалась им для обработки.

Рассмотрим гипотетический пример передачи параметров в приложение, которое возвращает отчеты о погоде из разных регионов или за разные периоды времени. Возможно, это может быть достигнуто путем указания координат широты и долготы и даты-времени в q-компоненте URN, что приведет к появлению таких URN, как показано ниже.

urn:example:weather?=op=map&lat=39.56
&lon=-104.85&datetime=1969-07-21T02:56:15Z

Если этот пример разрешен в HTTP URI, результат может выглядеть следующим образом:

https://weatherapp.example?op=map&lat=39.56&lon=-104.85&datetime=1969-07-21T02:56:15Z

2.3.3. f-компонент

F-компонент предназначен для интерпретации клиентом как спецификация для местоположения в пределах или области именованного ресурса. Он различает составные части ресурса, названного URN. Для URN, который разрешает один или несколько локаторов, которые могут быть разыменованы в представлении, или когда распознаватель URN напрямую возвращает представление ресурса, семантика f-компонента определяется типом мультимедиа представления.

F-компонент URN имеет тот же синтаксис, что и компонент фрагмента URI. Если URN, содержащий f-компонент, преобразуется в один URI, который является локатором, связанным с названным ресурсом, f-компонент из URN может применяться (обычно клиентом) как фрагмент этого URI. Если URN не преобразуется в URI, который является локатором, интерпретация f-компонента не определена этой спецификацией. Таким образом, для URN, которые могут быть преобразованы в URI, который является локатором, семантика f-компонентов идентична семантике фрагментов для этого ресурса.

В целях соответствия RFC 3986 ни общий синтаксис, ни семантика f-компонентов не определяются и не зависят от пространства имен URN URN. Параллельно с RFC 3986, особенности синтаксиса и семантики, например, какие ключевые слова или термины являются значимыми, конечно, могут зависеть от конкретного пространства имен URN или даже от конкретного ресурса.

F-компонент вводится символом знака числа («#») и заканчивается концом URI. Любые символы за пределами диапазона ASCII [RFC20], которые появляются в f-компоненте, ДОЛЖНЫ быть кодированы в процентах с использованием метода, определенного в разделе 2.1 общей спецификации URI [RFC3986].

Как описано в разделе 3, f-компонент НЕ ДОЛЖЕН учитываться при определении URN-эквивалентности.

Клиенты НЕ ДОЛЖНЫ передавать f-компоненты службам разрешения, если только эти службы не выполняют функции поиска и интерпретации объектов.

Рассмотрим гипотетический пример получения ресурсов, которые являются частью более крупной сущности (скажем, главы книги). Каждая часть может быть указана в f-компоненте, что приводит к таким URN, как:

urn:example:foo-bar-baz-qux#somepart

3. URN-эквивалентность

3.1. Процедура

Для различных целей, таких как кэширование, часто желательно определить, являются ли два URN «одинаковыми». Обычно это делается (т. Е. Независимо от схемы) путем проверки на эквивалентность (см. Раздел 6.1 [RFC3986]).

Общая спецификация URI [RFC3986] очень гибка в отношении сравнений на равенство, уделяя особое внимание разрешению ложных отрицаний и предотвращению ложных срабатываний. Если сравнения производятся независимым от схемы способом, т. е. Только при сравнении URI, многие URN, которые в данной спецификации считают равными, будут отклонены. Нижеследующее обсуждение применяется, когда известно, что участвующие URI являются URN, и, таким образом, используют термины «URN-эквивалент» и «URN-эквивалентность» для ссылки на эквивалентность, как указано в этом документе.

Два URN являются URN-эквивалентными, если их части с присвоенным именем равны октету за октетом после применения нормализации регистра (как указано в Разделе 6.2.2.1 [RFC3986]) к следующим конструкциям:

1. схема URI «урна», путем преобразования в нижний регистр
2. NID, путем преобразования в нижний регистр
3. любые символы в NSS, закодированные в процентах (то есть все триплеты символов, которые соответствуют продукции <pct-encoding>, приведенной в разделе 2.1 спецификации базового URI [RFC3986]), путем преобразования в верхний регистр цифр A-F.

Кодированные в процентах символы НЕ ДОЛЖНЫ быть декодированы, то есть нормализация процентного кодирования (как указано в разделе 6.2.2.2 [RFC3986]) НЕ ДОЛЖНА применяться в качестве части процесса сравнения.

Если r-компонент, q-компонент или f-компонент (или любая их комбинация) включены в URN, он ДОЛЖЕН игнорироваться для определения URN-эквивалентности.

Определения пространства имен URN МОГУТ включать дополнительные правила для URN-эквивалентности, такие как нечувствительность к регистру NSS (или его частей). Такие правила ДОЛЖНЫ всегда приводить к устранению некоторых ложных негативов, полученных с помощью описанной выше процедуры, и НЕ ДОЛЖНЫ приводить к тому, что два URN считаются не «одинаковыми», если в приведенной здесь процедуре указано, что они URN-эквивалентны. Связанные соображения относительно регистрации NID см. Ниже.

3.2. Примеры

В этом разделе показаны различные URN (с использованием «примерного» NID, определенного в [RFC6963]), которые выделяют правила эквивалентности URN.

Во-первых, поскольку схема и NID нечувствительны к регистру, следующие три URN эквивалентны URN друг другу:

• urn:example:a123,z456
• URN:example:a123,z456
• urn:EXAMPLE:a123,z456

Во-вторых, поскольку r-компонент, q-компонент и f-компонент не принимаются во внимание в целях проверки URN-эквивалентности, следующие три URN эквивалентны URN первым трем приведенным выше примерам:

• urn:example:a123,z456?+abc
• urn:example:a123,z456?=xyz
• urn:example:a123,z456#789

В-третьих, поскольку символ «/» (и все, что следует за ним) в NSS учитывается для целей URN-эквивалентности, следующие URN не являются URN-эквивалентными друг другу или шести предшествующим URN:

• urn:example:a123,z456/foo
• urn:example:a123,z456/bar
• urn:example:a123,z456/baz

В-четвертых, из-за кодирования в процентах следующие URN эквивалентны URN только друг другу, а не любому из вышеперечисленных (обратите внимание, что, хотя% 2C является кодированным в процентах преобразованием «,» из предыдущих примеров, такие последовательности не декодируются для целей проверки URN-эквивалентности):

• urn:example:a123%2Cz456
• URN:EXAMPLE:a123%2cz456

В-пятых, поскольку символы в NSS, отличные от кодированных в процентах последовательностей, обрабатываются с учетом регистра (если не указано иное для рассматриваемого пространства имен URN), следующие URN не эквивалентны URN первым трем URN:

• urn:example:A123,z456
• urn:example:a123,Z456

В-шестых, при случайном визуальном осмотре URN, представленного в ориентированном на человека интерфейсе, следующий URN может отображаться так же, как и первые три URN (поскольку U + 0430 Кириллическое маленькое письмо A можно спутать с U + 0061 LATIN SMALL LETTER A), но он не эквивалентен URN первым трем URN:

• urn:example:%D0%B0123,z456

4. Соответствие URI

4.1. Использование в слотах протокола URI

Поскольку URN, синтаксически, является URI по схеме «urn», теоретически URN может быть помещен в любой слот протокола, который позволяет использовать URI (назовите лишь несколько атрибутов «href» и «src» в HTML). базовый элемент в HTML, атрибут «xml: base» в XML [XML-BASE] и атрибут «xmlns» в XML для имен пространств имен XML [XML-NAMES]).

Однако это не означает, что семантически на практике всегда имеет смысл помещать URN в заданный интервал протокола URI; в частности, поскольку URN может не указывать местоположение ресурса или даже косвенно указывать на него, может быть нецелесообразно помещать URN в слот протокола URI, который указывает на ресурс (например, вышеупомянутые «href» и « атрибуты).

В конечном счете, рекомендации относительно того, когда целесообразно использовать URI в схеме «urn» (или любой другой схеме), являются ответственностью спецификаций для отдельных слотов протокола URI (например, спецификация для атрибута «xml: base» в XML может рекомендовать что неуместно использовать URN в этом слоте протокола). Эта спецификация не может предвидеть все соответствующие случаи, и она не является местом данной спецификации, чтобы требовать или ограничивать использование для отдельных слотов протокола.

4.2. Анализ

Частично из-за отделения семантики URN от более общего синтаксиса URI, универсальные процессоры URI должны уделять особое внимание правилам анализа и анализа в RFC 3986 и, в частности, должны рассматривать URI как непрозрачные, если только схема и ее требования не являются распознан. В последнем случае такие процессоры могут быть в состоянии вызывать обработку, подходящую для схемы, например, с помощью распознавателя URN. Средство распознавания URN может быть либо внешним средством распознавания, о котором известно средство распознавания URI, либо функциональностью, встроенной в средство распознавания URI. Обратите внимание, что это требование может налагать ограничения на контексты, в которых URN используются надлежащим образом; см. раздел 4.1.

4.3. URNs и относительные ссылки

В разделе 5.2 [RFC3986] описан алгоритм для преобразования ссылки URI, которая может относиться к данному базовому URI, в «проанализированные компоненты» цели этой ссылки, которая затем может быть перекомпонована в соответствии с RFC 3986, раздел 5.3, в целевой URI , Этот алгоритм проблематичен для сетей URN, поскольку их синтаксис не поддерживает необходимые компоненты пути. Однако, если алгоритм применяется независимо от конкретной схемы, он должен работать предсказуемо и для URN со следующими пониманиями (терминология создания синтаксиса взята из RFC 3986):

1. Система, которая встречает <URI-ссылку>, которая подчиняется синтаксису для <относительного-ref>, независимо от того, имеет ли она явно схему «urn» или нет, преобразует его в целевой URI, как указано в RFC 3986.
2. Из-за ожиданий постоянства и стабильности URN, авторов документов и т. Д., Использующих URN, как правило, следует избегать использования схемы «urn» в любом <URI-reference>, который не является строго <URI>, как указано в RFC 3986, в частности, включая те, которые требуют обработки <относительный-ref>.

4.4. Транспорт и Дисплей

Когда URN транспортируются и обмениваются, они ДОЛЖНЫ быть представлены в формате, определенном в данном документе. Кроме того, приложениям с поддержкой URN настоятельно рекомендуется предлагать возможность отображения URN в этой канонической форме, чтобы обеспечить прямую транскрипцию (например, методами копирования и вставки). Такие приложения могут поддерживать отображение URN в более удобной для человека форме и могут использовать набор символов, который включает символы, которые не разрешены в синтаксисе URN, как определено в этой спецификации (например, при отображении URN людям, такие приложения могут заменить процент -кодированные строки с символами из расширенного набора символов, такого как Unicode [UNICODE]).

Чтобы свести к минимуму путаницу пользователей, любое приложение, отображающее URI, ДОЛЖНО отображать полный URI (включая, для URN, схему «urn» и любые компоненты), чтобы гарантировать отсутствие путаницы между NID URN и идентификаторами схемы URI. Например, URI, начинающийся с «urn: xmpp:» [RFC4854], сильно отличается от URI, начинающегося с «xmpp:» [RFC5122]. Аналогично, потенциальная схема URI цифрового идентификатора объекта (DOI) [DOI-URI] отличается от возможного пространства имен DOI URN и, возможно, совершенно не связана с ним.

4.5. URI Дизайн и Владение

Как уже упоминалось, назначение URN в пространстве имен URN является управляемым процессом, так же как и назначение самих пространств имен URN. Хотя проектирование URN, которые должны быть назначены в данном пространстве имен URN, передается этой спецификацией менеджеру пространства имен URN, выполнение этого управляемым способом позволяет избежать проблем, присущих неуправляемой генерации URI, как описано в рекомендациях, касающихся разработки и владения URI [ RFC7320].

5. Пространства имен URN

Пространство имен URN — это набор имен, которые подчиняются трем ограничениям: каждое имя (1) уникально, (2) назначено согласованным образом и (3) назначено в соответствии с общим определением.

1. Ограничение «уникальности» означает, что имя в пространстве имен URN никогда не назначается более чем одному ресурсу и никогда не назначается другому ресурсу (для вида «ресурса», идентифицируемого URN, назначенными в пространстве имен URN). Это верно даже в том случае, если само имя устарело или устарело.

2. Ограничение «согласованное назначение» означает, что имя в пространстве имен URN назначается организацией или создается в соответствии с процессом или алгоритмом, который всегда соблюдается.

3. Ограничение «общего определения» означает, что существуют четкие определения для синтаксиса имен в пространстве имен URN и для процесса их назначения или создания.

Пространство имен URN идентифицируется конкретным NID для обеспечения глобальной уникальности URN и, при необходимости, для предоставления подсказки относительно структуры URN, назначенных в пространстве имен URN.

Что касается глобальной уникальности, то использование разных NID для разных коллекций имен гарантирует, что никакие два URN не будут одинаковыми для разных ресурсов, поскольку каждая коллекция должна уникально назначать каждое имя. Однако одному ресурсу МОЖЕТ быть назначено более одного URN, либо в одном и том же пространстве имен URN (если это разрешено в пространстве имен URN), либо в разных пространствах имен URN, а также для аналогичных целей или для других целей. (Например, если издатель назначает ISBN [RFC3187] электронной публикации, и эта публикация позднее включается в цифровой долгосрочный архив, управляемый национальной библиотекой, библиотека может присвоить публикации национальный библиографический номер (NBN) [ RFC3188], в результате чего два URN ссылаются на одну и ту же книгу.) С учетом других ограничений, таких как ограничения, накладываемые синтаксисом URI [RFC3986], правила схемы URN предназначены для обеспечения возможности сохранения нормальной и естественной формы указанных имен. в системах идентификаторов не-URN, когда они рассматриваются как URN.

Что касается структуры имен, назначенных в пространстве имен URN, то разработка структуры имен (и, следовательно, набора имен) зависит от требований сообщества, определяющего имена, как имена будут назначаться и использоваться и т. Д. проблемы выходят за рамки синтаксиса URN и общих правил для пространств имен URN, поскольку они специфичны для сообщества, определяющего систему идентификаторов не-URN, или для конкретного пространства имен URN (например, библиографические и публикующие сообщества в случае «ISBN»). «Пространство имен URN [RFC3187] и пространство имен URN« ISSN »[RFC3044] или разработчики расширений для расширяемого протокола обмена сообщениями и присутствия [RFC6120] в случае пространства имен« XMPP »URN [RFC4854]).

Поскольку символ двоеточия («:») используется для отделения «урны» от NID и NID от NSS, заманчиво думать, что весь URN структурирован символами двоеточия, и предполагать, что двоеточия создают структуру или иерархию в пределах NSS части URN. Такая структура может быть указана конкретной спецификацией NID, но не существует неявной структуры. В URN, таком как

urn:example:apple:pear:plum:cherry

строка NSS представляет собой «яблоко: груша: слива: вишня» в целом, и для символов двоеточия в этой строке NSS нет конкретного значения, если только это значение не описано в спецификации пространства имен «пример».

Пространства имен URN наследуют определенные права и обязанности по природе URN, в частности:

1. Они поддерживают общие принципы хорошо управляемого пространства имен URN, обеспечивая постоянную идентификацию ресурсов и уникальное назначение имен в соответствии с общим определением.
2. При желании они могут быть зарегистрированы в службах глобальной регистрации, таких как описанные в [RFC2483].

Существует два типа пространств имен URN: формальное и неформальное. Они отличаются ожидаемым уровнем обслуживания, информацией, необходимой для определения пространства имен URN, и процедурами регистрации. Поскольку большинство зарегистрированных пространств имен URN до сих пор были формальными, этот документ концентрируется на формальных пространствах имен URN.

5.1. Формальные пространства имен URN

Формальное пространство имен URN предоставляет преимущества некоторому подмножеству пользователей в Интернете. В частности, не имеет смысла использовать формальное пространство имен URN только сообществом или сетью, не подключенной к Интернету. Например, было бы неуместно для пространства имен URN эффективно заставлять кого-то использовать собственную сеть или службу, не открытую для обычного пользователя Интернета. Намерение состоит в том, что, хотя сообщество тех, кто может активно использовать URN, назначенные в этом пространстве имен URN, может быть небольшим, потенциальное использование имен в этом пространстве имен URN открыто для любого пользователя в Интернете. Формальные пространства имен URN могут быть уместными, даже если некоторые аспекты не полностью открыты. Например, пространство имен URN может использовать платный, частный или частный реестр для назначения URN в пространстве имен URN. Тем не менее, некоторые пользователи Интернета могут по-прежнему пользоваться преимуществами, если связанные службы имеют открытые имена.

Организация, которая будет назначать URN в формальном пространстве имен URN, ДОЛЖНА соответствовать следующим критериям:

1. Организационная стабильность и способность поддерживать пространство имен URN в течение длительного времени; при отсутствии таких доказательств должно быть ясно, как пространство имен URN может оставаться жизнеспособным, если организация больше не может поддерживать пространство имен URN.
2. Компетентность в назначении URN. Это улучшит вероятность постоянства (например, чтобы минимизировать вероятность конфликтов).
3. Обязательство не переназначать существующие URN и разрешать старым URN оставаться действительными (например, если правопреемник URN больше не является членом или клиентом присваивающей организации, если происходит разная информация о правопреемнике или названном объекте изменить, или даже если правопреемник или сам названный объект больше не существует (во всех этих случаях URN все еще действителен).

Формальное пространство имен URN устанавливает конкретный NID с учетом следующих ограничений (помимо уже установленных правил синтаксиса):

1. Это НЕ ДОЛЖНО быть уже зарегистрированным NID.
2. Он НЕ ДОЛЖЕН начинаться с «urn-» (который зарезервирован для неформальных пространств имен URN).
3. Он ДОЛЖЕН быть длиной более двух символов и НЕ ДОЛЖЕН начинаться с АЛЬФА АЛЬФА «-«, то есть любая строка, состоящая из двух букв, за которыми следует один дефис; такие строки зарезервированы для потенциального использования в качестве NID на основе кодов стран ISO альфа-2 [ISO.3166-1] для возможных национальных регистраций пространств имен URN (однако, определение и определение правил для распределения ответственности за такой код страны пространства имен на основе URN выходят за рамки этого документа). Как следствие, он НЕ ДОЛЖЕН начинаться со строки «xn--» или любой другой строки, состоящей из двух букв, за которыми следуют два дефиса; такие строки зарезервированы для потенциального представления DNS-меток A и аналогичных строк в будущем [RFC5890].
4. Он НЕ ДОЛЖЕН начинаться со строки «X-», чтобы его нельзя было перепутать или конфликтовать с каким-либо экспериментальным пространством имен URN, ранее разрешенным [RFC3406].

Кандидаты и рецензенты, рассматривающие новые NID, также должны знать, что они могут иметь семантическое значение и, следовательно, быть источником конфликта. Особое внимание следует уделять строкам, которые могут быть истолкованы как идентификаторы или зарегистрированные в соответствии с полномочиями стран (включая коды альфа-3 ИСО 3166-1) и строкам, которые могут подразумевать связь с существующими схемами URI, не-URN-идентификатор системы или товарные знаки. Однако, в соответствии с традиционной политикой, споры о «владении» конкретными строками являются разногласиями между вовлеченными сторонами; ни IANA, ни IETF не будут участвовать в таких спорах, за исключением случаев, когда это делается по решению суда компетентной юрисдикции.

5.2. Неформальные пространства имен URN

Неформальные пространства имен URN — это полноценные пространства имен URN со всеми связанными правами и обязанностями. Неформальные пространства имен URN отличаются от формальных пространств имен URN в процессе назначения NID: для неформального пространства имен URN регистрант не назначает NID; вместо этого IANA назначает NID, состоящий из строки «urn-», за которой следуют одна или несколько цифр (например, «urn-7»), где цифры состоят из следующего доступного числа в последовательности положительных целых чисел, назначенных неформальным пространствам имен URN. Таким образом, синтаксис неформального идентификатора пространства имен URN:

InformalNamespaceName = «urn-» Number
Number = DigitNonZero 0*Digit
DigitNonZero = «1»/ «2» / «3» / «4»/ «5» / «6» / «7» / «8» / «9»
Digit = «0» / DigitNonZero

Единственное ограничение на <Number> состоит в том, что он (1) состоит строго из цифр ASCII, (2) не имеет ведущих нулей и (3) не заставляет NID превышать ограничения длины, определенные для синтаксиса URN (см. Раздел 2).

6. Определение и регистрация пространства имен URN

6.1. Обзор

Поскольку пространство пространств имен URN само управляется, определению пространства имен URN СЛЕДУЕТ уделять особое внимание:

1. Назначение пространства имен URN.
2. Синтаксис URN, назначенных в пространстве имен URN, включая внутренний синтаксис и ожидаемые эффекты r-компонентов или q-компонентов. (Синтаксис и интерпретация f-компонентов определены в RFC 3986.)
3. Процесс назначения URN в пространстве имен URN.
4. Последствия для безопасности назначения URN в пространстве имен URN и использования назначенных URN.
5. Любые потенциальные проблемы взаимодействия с URN, назначенными в пространстве имен URN.
6. Необязательно, процесс разрешения URN, назначенных в пространстве имен URN.

Раздел по заполнению шаблона (раздел 6.4) объясняет эти вопросы более подробно. Хотя шаблоны регистрации одинаковы во всех случаях, используются немного разные процедуры в зависимости от источника регистрации.

6.2. Политика и процесс регистрации: регистрация сообщества

Основной политикой регистрации для пространств имен URN является экспертная проверка, как это определено в документе «Соображения IANA» [RFC5226]. Для пространств имен URN или их определений, которые должны стать стандартами или составными частями стандартов, результатом процесса экспертизы должен быть отчет, а не инструкция IANA для принятия мер (см. Ниже). Ключевые шаги:

1. Заполните шаблон регистрации пространства имен URN (см. Раздел 6.4 и Приложение A). Это можно сделать как часть интернет-проекта или спецификации в другой серии, хотя это не является обязательным требованием.
2. Отправьте заполненный шаблон в список обсуждения urn@ietf.org для ознакомления.
3. Если необходимо учесть полученные комментарии, повторите шаги 1 и 2.
4. Если назначенные эксперты одобряют запрос и не предпринимает никаких действий по стандартизации, IANA зарегистрирует запрошенный NID. Если ожидается стандартизация, назначенные эксперты подготовят отчет и направят его в соответствующий орган по утверждению стандартов (IESG в случае IETF); IANA зарегистрирует запрошенный NID только после получения указаний от этого органа и копии отчета об экспертизе.

Регистрация в пространстве имен URN может быть изменена путем обновления шаблона регистрации, выполнив те же шаги, которые описаны выше для новых регистраций. Пересмотренная регистрация ДОЛЖНА описывать отличия от предыдущих версий и ДОЛЖНА специально отмечать любые соответствующие изменения в базовых технологиях или процессах управления пространством имен URN.

Накопленный на сегодняшний день опыт запросов на регистрацию пространства имен URN показал, что регистранты иногда изначально не понимают некоторые тонкости пространств имен URN и что определение пространства имен URN в форме спецификации позволяет владельцам регистраций четко сформулировать свой «договор» с предполагаемым пользователем. сообщества. Следовательно, хотя политикой регистрации для формальных пространств имен URN является экспертная проверка, и спецификация (в отличие от шаблона регистрации) строго не требуется, владельцы регистраций ДОЛЖНЫ предоставить стабильную спецификацию, документирующую определение пространства имен URN и расширяющую вопросы, описанные в данном документе.

Поскольку именование может быть сложным и спорным, владельцам регистраций пространства имен URN и назначенным экспертам настоятельно рекомендуется работать в духе добросовестности и взаимопонимания для достижения приблизительного консенсуса (см. [RFC7282]) по обработке запросов на регистрацию. Им также рекомендуется привнести дополнительные экспертные знания в обсуждение, если это будет полезно для обеспечения перспективы или иного решения проблем.

Особенно, когда итерации в процессе регистрации продлеваются, от назначенных экспертов ожидается, что они предпримут разумные меры предосторожности, чтобы избежать «расовых условий» в отношении предлагаемых NID и, в случае возникновения таких ситуаций, побудить кандидатов разрешить любые конфликты между собой.

6.3. Политика и процесс регистрации: ускоренный путь для организаций по разработке стандартов, научных обществ и аналогичных органов

IETF признает, что будут возникать ситуации, в которых будут создаваться пространства имен URN для встраивания существующих и установленных стандартов, в частности стандартов идентификаторов, или для отражения знаний, терминологии или методов организации информации, которые выходят далеко за пределы сферы действия IETF или знаний вероятного предмета. назначенных экспертов. В ситуациях, когда запрос на регистрацию исходит от уполномоченной признанной организации по разработке стандартов, научного общества или их уполномоченных лиц или разрешается им, по выбору этого органа доступна несколько иная процедура:

1. Шаблон регистрации пространства имен URN заполняется и отправляется, как описано в шагах 1 и 2 раздела 6.2.
2. Требуется спецификация, которая отражает или указывает на необходимые внешние стандарты или спецификации. Публикация в серии RFC или в процессе IETF (например, публикация в виде интернет-проекта) не ожидается и будет уместной только в очень необычных обстоятельствах.
3. Обзоры в дискуссионном списке и назначенных экспертов носят строго рекомендательный характер, при этом решения о том, какой совет принять, и продолжительности времени, выделяемого на процесс, строго под контролем внешнего органа.
4. Когда этот орган приходит к выводу, что заявка является достаточно зрелой, его представитель (-и) потребует, чтобы IANA завершила регистрацию для NID, и IANA сделает это.

Решения о том, признавать ли запрашивающий орган в качестве организации по разработке стандартов или научного общества, являются обязанностью IESG.

Модель, подобная этой, уже была определена для признанных организаций по разработке стандартов, которые хотят регистрировать типы носителей. Документ, описывающий этот механизм [RFC6838], предоставляет несколько больше информации об общем подходе.

6.4. Заполнение шаблона

Шаблон для определения и регистрации пространства имен URN приведен в Приложении А. В этом разделе описываются соображения по заполнению шаблона.

6.4.1. Цель

Раздел «Цель» шаблона описывает такие вопросы, как:

1. Виды ресурсов, идентифицируемых URN, назначенными в пространстве имен URN.

2. Объем и применимость URN, назначенных в пространстве имен URN; это может включать информацию о сообществе пользователей (например, о конкретной стране, отрасли, технологии или организации), о том, будут ли назначенные URN использоваться в общедоступных или частных сетях и т. д.

3. Каким образом предполагаемое сообщество (и интернет-сообщество в целом) получат выгоду от использования или разрешения назначенных URN.

4. Как пространство имен URN связано и дополняет существующие пространства имен URN, схемы URI и системы идентификаторов не-URN.

5. Виды программных приложений, которые могут использовать или разрешать назначенные URN (например, путем дифференциации между различными пространствами имен URN, постоянной идентификации ресурсов или осмысленного разрешения и доступа к услугам, связанным с пространством имен URN).

6. Доступны ли услуги разрешения или будут ли они доступны (и, если да, характер или идентичность услуг). Здесь полезны примеры q-компонента и (когда они стандартизированы) семантики и синтаксиса r-компонента, даже если подробные определения предоставлены в другом месте или позже.

7. Предполагается ли, что пространство имен URN или его определение станут составной частью стандарта, разрабатываемого в IETF или каком-либо другом признанном органе по стандартизации.

6.4.2. Синтаксис

Раздел «Синтаксис» шаблона содержит:

1. Описание структуры URN в пространстве имен URN в соответствии с основным синтаксисом URN. Структура может быть описана в терминах формального определения (например, с использованием ABNF [RFC5234]), алгоритма генерации согласованных URN или регулярного выражения для разбора имени на составные части; альтернативно, структура может быть непрозрачной.

2. Любые специальные правила кодирования символов для назначенных URN (например, какой символ всегда следует использовать для кавычек).

3. Правила определения URN-эквивалентности между двумя именами в пространстве имен URN. Такие правила должны всегда иметь эффект устранения ложных негативов, которые в противном случае могли бы возникнуть в результате сравнения. Если это уместно и полезно, можно сослаться на конкретные правила эквивалентности, определенные в спецификации URI [RFC3986], или на раздел 3 этого документа.

Примеры правил URN-эквивалентности включают эквивалентность между прописными и строчными символами в NSS, между дефисированными и не дефисированными группировками в имени или между одинарными и двойными кавычками. Также могут быть особые особенности кодирования пространства имен, особенно для URN, которые содержат встроенные формы имен из систем идентификаторов не-URN. (Обратите внимание, что они не являются нормативными утверждениями для какой-либо передовой практики, связанной с обработкой отношений между символами в целом; такие утверждения ограничены только одним конкретным пространством имен URN.)

4. Любые особые соображения, необходимые для соответствия синтаксису URN. Это особенно применимо в случае существующих систем идентификаторов не-URN, которые используются в контексте URN. Например, если система идентификаторов не-URN используется в контекстах, отличных от URN, она может использовать символы, зарезервированные в синтаксисе URN. В этом разделе следует отметить любые такие символы и наметить необходимые отображения для соответствия синтаксису URN. Обычно это будет обрабатываться путем процентного кодирования символа, как указано в Разделе 2.1 спецификации URI [RFC3986] и как обсуждено в Разделе 1.2.2 этой спецификации.

5. Любые особые соображения относительно значения q-компонентов (например, ключевых слов) или f-компонентов (например, предварительно определенных терминов) в контексте этого пространства имен URN.

6.4.3. Присваивание

Раздел «Назначение» шаблона описывает такие вопросы, как:

1. Механизмы или органы для присвоения URN ресурсам. Должно быть ясно, является ли назначение полностью открытым (например, после определенной процедуры, такой как «первым пришел, первым обслужен» (FCFS)), полностью закрытым (например, для частной организации) или ограниченным различными способами (например, делегированы полномочиям, признанным определенной организацией); если ограничено, следует объяснить, как стать присваивателем имен или как запрашивать присвоение имен у существующих органов по присвоению.

2. Методы обеспечения уникальности URN в пространстве имен URN. Например, имена могут назначаться последовательно или в соответствии с каким-либо четко определенным процессом одним полномочным органом, назначение может быть разделено между делегированными полномочиями, которые индивидуально отвечают за соблюдение правил уникальности, или URN могут создаваться независимо, следуя алгоритму, который сам гарантирует уникальность.

6.4.4. Безопасность и конфиденциальность

В разделе «Безопасность и конфиденциальность» шаблона описываются любые потенциальные проблемы, связанные с безопасностью и конфиденциальностью, связанные с назначением, использованием и разрешением имен в пространстве имен URN. Примеры таких проблем включают в себя:

• Последствия получения ложных отрицательных и ложных положительных результатов во время сравнения для URN-эквивалентности (см. раздел 3.1 данной спецификации и «Проблемы сравнения идентификаторов для целей безопасности» [RFC6943]).
• Утечка личной информации, когда имена сообщаются в общедоступном Интернете.
• Потенциал для сбора каталогов.
• Различные вопросы, обсуждаемые в руководствах по соображениям безопасности в RFC [RFC3552] и соображениям конфиденциальности для интернет-протоколов [RFC6973]. В частности, обратите внимание на текст соображений конфиденциальности для пространства имен Глобальной ассоциации систем мобильной связи (GSMA) / Международной идентификации оборудования мобильной станции (IMEI) [RFC7254], который может послужить полезной моделью для таких случаев.

6.4.5. Взаимодействие

Раздел «Взаимодействие» ДОЛЖЕН указывать любые известные потенциальные проблемы, связанные с совместимостью. Примеры включают возможную путаницу с другими пространствами имен URN, системами идентификаторов не-URN или схемами URI из-за синтаксиса (например, кодирование процентов определенных символов) или области действия (например, перекрывающиеся области интереса). Если это вообще возможно, проблемы, возникающие при регистрации пространства имен URN (например, из-за синтаксиса или области действия системы идентификаторов не-URN), должны решаться как часть или параллельно с процессом регистрации.

6.4.6. Разрешение

Раздел «Разрешение» ДОЛЖЕН указывать, предназначены ли механизмы разрешения для ожидаемых URN, назначенных в пространстве имен URN.

Если предназначено разрешение, то в этом разделе СЛЕДУЕТ указать, намеревается ли организация, которая назначает URN в пространстве имен URN, работать или рекомендовать какие-либо службы разрешения для URN в этом пространстве имен URN. Кроме того, если организация-назначитель намеревается осуществить регистрацию для публично объявленных служб разрешения (например, с использованием системы, разработанной в духе оригинальных архитектурных принципов и описаний служб для разрешения URN [RFC2276] [RFC2483]), то этот раздел ДОЛЖЕН перечислить или ссылаться на требования для публичной рекламы назначающей организацией. Кроме того, в этом разделе СЛЕДУЕТ описать любые особые соображения для обработки r-компонентов в контексте этого пространства имен URN.

6.4.7. Дополнительная информация

Раздел «Дополнительная информация» содержит информацию, которая будет полезна для тех, кто пытается понять эту регистрацию или ее связь с другими регистрациями, например сравнения с существующими пространствами имен URN, которые могут показаться перекрывающимися.

Этот раздел шаблона не является обязательным.

7. Соображения IANA

7.1. Схема URI

В этом разделе обновляется регистрация схемы URI «urn» в постоянном реестре URI [URI-Registry].

Имя схемы URI: URN

Статус: постоянный

Синтаксис схемы URI: см. Раздел 2 RFC 8141.

Семантика схемы URI: схема «urn» идентифицирует унифицированный ресурс

Имена, которые являются постоянными, независимыми от местоположения идентификаторами ресурса.

Вопросы кодирования: см. Раздел 2 RFC 8141.

Приложения / протоколы, использующие это имя схемы URI: унифицированные имена ресурсов используются в самых разных приложениях, включая библиографические справочные системы и в качестве имен для пространств имен расширяемого языка разметки (XML).

Вопросы совместимости: см. Раздел 4 RFC 8141.

Вопросы безопасности: см. Разделы 6.4.4 и 8 RFC 8141.

Контакт: рабочая группа URNBIS [mailto: urn@ietf.org]

Author / Change Controller: эта схема зарегистрирована в дереве IETF. Таким образом, IETF поддерживает контроль изменений.

Рекомендации: нет.

7.2. Регистрация пространств имен URN

Этот документ описывает процессы регистрации пространств имен URN и имеет значение для IANA с точки зрения ведения реестров (см. Особенно раздел 6). Во всех случаях IANA следует назначить соответствующий NID (формальный или неформальный) после завершения процедур, описанных в разделе 6.

7.3. Список обсуждений для новых и обновленных регистраций NID

Как обсуждалось в другом месте в этом документе, список обсуждений, указанный в RFC 3406 (urn-nid@apps.ietf.org), прекращается и заменяется списком обсуждений urn@ietf.org.

8. Вопросы безопасности и конфиденциальности

Определение пространства имен URN должно учитывать потенциальные проблемы безопасности и конфиденциальности, связанные с назначением, использованием и разрешением имен в пространстве имен URN (например, некоторые средства распознавания URN могут назначать специальное значение определенным символам в NSS); см. раздел 6.4.4 для дальнейшего обсуждения.

В большинстве случаев пространства имен URN предоставляют способ объявления публичной информации. Обычно эти объявления будут иметь относительно низкий профиль безопасности; однако всегда существует опасность «подделки» и предоставления дезинформации. Информация в этих декларациях должна рассматриваться как консультативная.

9. Ссылки

9.1. Нормативные ссылки

[RFC20] Cerf, V., «ASCII format for network interchange», STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.

9.2. Информационные ссылки

[DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, «The «doi» URI Scheme for the Digital Object Identifier (DOI)», Work in Progress, draft-paskin-doi-uri-04, June 2003.

[IANA-URN] Saint-Andre, P. and M. Cotton, «A Uniform Resource Name (URN) Namespace for IANA Registries», Work in Progress, draft-saintandre-iana-urn-01, February 2013.

[ISO.27729.2012] ISO, «Information and documentation — International standard name identifier (ISNI)», ISO 27729:2012, Technical Committee ISO/TC 46, Information and documentation, Subcommittee SC 9, Identification and description, March 2012.

[ISO.3166-1] ISO, «Codes for the representation of names of countries and their subdivisions — Part 1: Country codes», ISO 3166-1:2013, November 2013.

[RFC1737] Sollins, K. and L. Masinter, «Functional Requirements for Uniform Resource Names», RFC 1737, DOI 10.17487/RFC1737, December 1994, <http://www.rfc-editor.org/info/rfc1737>.

[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, «Uniform Resource Locators (URL)», RFC 1738, DOI 10.17487/RFC1738,
December 1994, <http://www.rfc-editor.org/info/rfc1738>.

[RFC1808] Fielding, R., «Relative Uniform Resource Locators», RFC 1808, DOI 10.17487/RFC1808, June 1995,
<http://www.rfc-editor.org/info/rfc1808>.

[RFC2141] Moats, R., «URN Syntax», RFC 2141, DOI 10.17487/RFC2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>.

[RFC2276] Sollins, K., «Architectural Principles of Uniform Resource Name Resolution», RFC 2276, DOI 10.17487/RFC2276, January 1998, <http://www.rfc-editor.org/info/rfc2276>.

[RFC2483] Mealling, M. and R. Daniel, «URI Resolution Services Necessary for URN Resolution», RFC 2483, DOI 10.17487/RFC2483, January 1999,
<http://www.rfc-editor.org/info/rfc2483>.

[RFC2648] Moats, R., «A URN Namespace for IETF Documents», RFC 2648, DOI 10.17487/RFC2648, August 1999,
<http://www.rfc-editor.org/info/rfc2648>.

[RFC3044] Rozenfeld, S., «Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace», RFC 3044, DOI 10.17487/RFC3044, January 2001, <http://www.rfc-editor.org/info/rfc3044>.

[RFC3187] Hakala, J. and H. Walravens, «Using International Standard Book Numbers as Uniform Resource Names», RFC 3187, DOI 10.17487/RFC3187, October 2001,
<http://www.rfc-editor.org/info/rfc3187>.

[RFC3188] Hakala, J., «Using National Bibliography Numbers as Uniform Resource Names», RFC 3188, DOI 10.17487/RFC3188,
October 2001, <http://www.rfc-editor.org/info/rfc3188>.

[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, «Uniform Resource Names (URN) Namespace Definition Mechanisms», BCP 66, RFC 3406, DOI 10.17487/RFC3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>.

[RFC3552] Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.

[RFC4854] Saint-Andre, P., «A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)», RFC 4854, DOI 10.17487/RFC4854, April 2007, <http://www.rfc-editor.org/info/rfc4854>.

[RFC5122] Saint-Andre, P., «Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)», RFC 5122, DOI 10.17487/RFC5122, February 2008,
<http://www.rfc-editor.org/info/rfc5122>.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.

[RFC6120] Saint-Andre, P., «Extensible Messaging and Presence Protocol (XMPP): Core», RFC 6120, DOI 10.17487/RFC6120,
March 2011, <http://www.rfc-editor.org/info/rfc6120>.

[RFC6288] Reed, C., «URN Namespace for the Defence Geospatial Information Working Group (DGIWG)», RFC 6288, DOI 10.17487/RFC6288, August 2011,
<http://www.rfc-editor.org/info/rfc6288>.

[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, «Deprecating the «X-» Prefix and Similar Constructs in Application Protocols», BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012,
<http://www.rfc-editor.org/info/rfc6648>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.

[RFC6943] Thaler, D., Ed., «Issues in Identifier Comparison for Security Purposes», RFC 6943, DOI 10.17487/RFC6943, May
2013, <http://www.rfc-editor.org/info/rfc6943>.

[RFC6963] Saint-Andre, P., «A Uniform Resource Name (URN) Namespace for Examples», BCP 183, RFC 6963, DOI 10.17487/RFC6963,
May 2013, <http://www.rfc-editor.org/info/rfc6963>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, «Privacy Considerations for Internet Protocols», RFC 6973, DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.

[RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. Gosden, «A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)», RFC 7254, DOI 10.17487/RFC7254, May 2014,
<http://www.rfc-editor.org/info/rfc7254>.

[RFC7282] Resnick, P., «On Consensus and Humming in the IETF», RFC 7282, DOI 10.17487/RFC7282, June 2014,
<http://www.rfc-editor.org/info/rfc7282>.

[RFC7320] Nottingham, M., «URI Design and Ownership», BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014,
<http://www.rfc-editor.org/info/rfc7320>.

[RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and P. Kyzivat, «URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)», RFC 7462, DOI 10.17487/RFC7462, March 2015, <http://www.rfc-editor.org/info/rfc7462>.

[RFC7613] Saint-Andre, P. and A. Melnikov, «Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords», RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.

[UAX31] The Unicode Consortium, «Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax», Unicode 9.0.0, June 2015, <http://unicode.org/reports/tr31/>.

[UNICODE] The Unicode Consortium, «The Unicode Standard», <http://www.unicode.org/versions/latest/>.

[URI-Registry] IANA, «Uniform Resource Identifier (URI) Schemes», <http://www.iana.org/assignments/uri-schemes>.

[XML-BASE] Marsh, J. and R. Tobin, «XML Base (Second Edition)», W3C Recommendation REC-xmlbase-20090128, January 2009, <http://www.w3.org/TR/2009/REC-xmlbase-20090128>.

[XML-NAMES] Thompson, H., Hollander, D., Layman, A., Bray, T., and R. Tobin, «Namespaces in XML 1.0 (Third Edition)», W3C Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.

Приложение А. Шаблон регистрации

Namespace Identifier

Идентификатор пространства имен: Запрашивается IANA (формально) или присваивается IANA (неформально).

Version

Версия: версия регистрации, начиная с 1 и увеличиваясь на 1 с каждой новой версией.

Date

Дата: Дата, когда в IANA запрашивается регистрация, в формате ГГГГ-ММ-ДД.

Registrant

Регистрант: лицо или организация, которые зарегистрировали NID, включая имя и адрес регистрирующей организации, а также имя и контактную информацию (адрес электронной почты, номер телефона или почтовый адрес) назначенного контактного лица. Если регистрант является признанной организацией по разработке стандартов, научным обществом или аналогичным органом, запрашивающим ускоренную процедуру регистрации (см. Раздел 6.3), эта информация должна быть четко указана в этом разделе шаблона.

Purpose

Цель: описана в разделе 6.4.1 настоящего документа.

Syntax

Синтаксис: описан в разделе 6.4.2 этого документа. Если регистрация явно не описывает семантику r-компонентов, q-компонентов и f-компонентов в контексте этого пространства имен URN, эта семантика не определена.

Assignment

Назначение: Описано в разделе 6.4.3 этого документа.

Security and Privacy

Безопасность и конфиденциальность: Описаны в разделе 6.4.4 этого документа.

Interoperability

Функциональная совместимость: описана в разделе 6.4.5 настоящего документа.

Resolution

Решение: описано в разделе 6.4.6 настоящего документа.

Documentation

Документация: указатель на RFC, спецификацию, опубликованную другой организацией по разработке стандартов, или другой стабильный документ, который предоставляет дополнительную информацию об этом пространстве имен URN.

Additional Information

Дополнительная информация: Описано в разделе 6.4.7 этого документа.

Revision Information

Информация о редакции: Описание изменений предыдущей версии. (Применимо только в том случае, если более ранние регистрации были пересмотрены.)

Приложение B. Изменения по сравнению с RFC 2141

Этот документ вносит существенные изменения в синтаксис и семантику [RFC2141]:

B.1. Изменения синтаксиса от RFC 2141

Синтаксис URN, представленный в [RFC2141], был определен до обновления спецификации URI в [RFC3986]. Определение синтаксиса URN обновлено в этом документе, чтобы сделать следующее:

• Обеспечить согласованность с синтаксисом URI.
• Облегчить использование URN с параметрами, аналогичными запросам и фрагментам URI.
• Разрешить параметры, влияющие на разрешение URN.
• Облегчить использование URN с системами идентификаторов не-URN, которые включают символ «/».

В частности, эта спецификация делает следующее:

• Расширяет синтаксис URN для явного разрешения символов «/», «?» и «#», которые были зарезервированы для будущего использования в RFC 2141. Это изменение также эффективно разрешает несколько компонентов синтаксиса URI, хотя и не обязательно связывает эти компоненты с Семантика URI.
• Определяет общий синтаксис для дополнительного компонента, который может использоваться во взаимодействиях со службой разрешения URN.
• Запрещает «-» в конце NID.
• Позволяет использовать символы «/», «~» и «&» в NSS.
• Делает несколько небольших изменений синтаксиса.

B.2. Другие изменения из RFC 2141

• Формально регистрирует «урну» как схему URI.
• Позволяет так называемые r-компоненты, q-компоненты и f-компоненты.

Кроме того, часть текста была обновлена, чтобы соответствовать определению URI [RFC3986] и процессам регистрации информации в IANA [RFC5226], а также более современным руководствам в отношении безопасности [RFC3552], конфиденциальности [ RFC6973] и сравнение идентификаторов [RFC6943].

Приложение C. Изменения по сравнению с RFC 3406

Этот документ вносит следующие существенные изменения из [RFC3406]:

1. Ослабляет политику регистрации формальных пространств имен URN с «IETF Review» до «Expert Review», как обсуждалось в разделе 6.2.

2. Удаляет категорию экспериментальных пространств имен URN, в соответствии с [RFC6648]. Экспериментальные пространства имен URN были обозначены префиксом идентификатора пространства имен строкой «X-». Поскольку экспериментальные пространства имен URN никогда не регистрировались, удаление экспериментальной категории не влияет на существующие реестры. Поскольку экспериментальные пространства имен URN не управляются, строки, соответствующие синтаксису URN в экспериментальных пространствах имен URN, не являются допустимыми URN. Действительно экспериментальное использование может, конечно, использовать «примерное» пространство имен [RFC6963].

3. Добавляет некоторую информацию, но в целом упрощает шаблон регистрации пространства имен URN.

Подтверждения

Большое спасибо Марку Бланше, Лесли Дейглу, Мартину Дюрсту, Юхе Хакале, Теду Харди, Альфреду Хоунсу, Полу Джонсу, Барри Лейбе, Шону Леонарду, Ларри Масинтеру, Китаю Муру, Марку Ноттингему, Джулиану Решке, Ларсу Свенссону, Генри С. Томпсону, Дейл Уорли и другие участники рабочей группы URNBIS за их вклад. Альфред Хоэнс, в частности, отредактировал более раннюю версию этого документа и был сопредседателем рабочей группы URNBIS.

Юха Хакала заслуживает особого признания за его приверженность успешному завершению этой работы, равно как и Эндрю Ньютон и Мелинда Шор в их качестве сопредседателей рабочей группы и Барри Лейба в его роли в качестве регионального директора, а затем в качестве сопредседателя.

Авторы

RFC 2141, который послужил основой для синтаксической части этого документа, был создан Райаном Моатсом.

RFC 3406, который послужил основой для части пространства имен этого документа, был создан Лесли Дейглом, Дирком-Виллемом ван Гуликом, Ренато Яннеллой и Патриком Фальтстромом.

Их работа с благодарностью признана.

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

Peter Saint-Andre
Filament
P.O. Box 787
Parker, CO 80134
United States of America
Phone: +1 720 256 6756
Email: peter@filament.com
URI: <https://filament.com/>

John C. Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
United States of America
Phone: +1 617 245 1457
Email: john-ietf@jck.com