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. Тем не менее, некоторые пользователи Интернета могут по-прежнему пользоваться преимуществами, если связанные