URN

Идея URN возникла из-за существенных недостатков системы URL. Ресурсы во Всемирной паутине и Интернете перемещаются, а ссылки в виде URL остаются, указывая на уже отсутствующие ресурсы. Старые URL также делаются бесполезными при реструктуризации ресурсов, переименовании, удалении, перемещении в другой домен DNS. Для решения этой проблемы была разработана эффективная система PURL (англ. Persistent Uniform Resource Locator — постоянный URL), сейчас широко используемая, а также система DOI (англ. Digital Object Identifier — идентификатор цифрового объекта). Но это всё же лишь частичные решения проблемы. Принципиальным же решением должен стать стандарт единообразного именования ресурсов URN.

URN указывает неизменное имя ресурса без указания его местонахождения и способа обращения. В результате URN-имена постоянны, они не зависят от конкретных серверов и протоколов. Другими словами, URN концептуально обозначает сам ресурс, а не место, где находится какой-то ресурс (а может, уже не находится), как это делает URL. Допустим, есть человек по имени Михаил Петров, который живёт в Москве по адресу ул. Земляной вал, 14. Если кто-то спросит его: «Вы кто?», он, разумеется, ответит «Я — Михаил Петров». Он ведь не скажет: «Я человек, живущий на Земляном валу, 14». Так вот, URN идентифицирует человека как «Михаил Петров», а URL лишь сообщает, что кто-то живёт по адресу ул. Земляной вал, 14 (а может, там находится и организация… URL этого не сообщает).

Для нахождения ресурсов по URN-имени нужна «система разрешения URN-имён» (англ. URN resolution). Тогда человек (или программа), знающий точный URN ресурса, введёт его в систему разрешения и немедленно получит множество конкретных мест (серверов или, скажем, интернет-магазинов), где этот ресурс можно найти. В 2002 году была предложена система DDDS (англ. Dynamic Delegation Discovery System; система динамического обнаружения ресурсов), которая разрешает имена URN в URL-ссылки на конкретные местонахождения ресурсов. При этом и URN, и URL являются частью одной системы идентификации ресурсов URI.

В 1994 году вышел запрос RFC 1737, в котором описывались концептуальные и функциональные требования к разработке URN. Сама идея URN родилась несколько раньше, но до 1994 года не была никак сформулирована. После выхода RFC 1737 было потрачено очень много времени и усилий на разработку URN. Рабочая группа URN при IETF (англ. Internet Engineering Task Force) включает в себя очень много заинтересованных сторон (включая крупные конкурирующие компании), поэтому достижение всеобщего согласия представляется очень затруднительным. Тем не менее, уже в мае 1997 года вышла спецификация RFC 2141, описывающая первую версию синтаксиса URN. Хотя разработка URN ещё далеко не завершена, и достичь консенсуса по всем вопросам пока не удалось, но базовые черты URN вырисовываются уже довольно чётко.

В 1999 году был опубликован запрос комментариев RFC 2483, который в общих чертах обрисовывал систему разрешения URN-имён. В октябре 2002 года вышла целая серия документов: RFC 3401, RFC 3402, RFC 3403, RFC 3404, RFC 3405. В этих документах определялась система разрешения URN-имён DDDS (см. выше) — последнее необходимое звено для внедрения URN. Примерно в то же время вышла и спецификация RFC 3406, уточняющая спецификацию пространств имён URN.

В настоящее время применение URN приобрело уже значительные масштабы. Имена URN стали неотъемлемой частью расширяемого языка разметки XML. Всё чаще и чаще URN реализуются в популярном программном обеспечении.

Единообразные имена ресурсов имеют следующую структуру:

<URN> ::= "urn:" <NID> ":" <NSS>

В этой записи:

<NID>

идентификатор пространства имён (англ. Namespace Identifier); представляет собой синтаксическую интерпретацию NSS, не чувствителен к регистру.

<NSS>

строка из определённого пространства имён (англ. Namespace Specific String); если в этой строке содержатся символы не из набора ASCII, то они должны быть закодированы в Юникоде (UTF-8) и предварены (каждый из них) знаком процента «%» (подробнее см. URL).

При этом начальная последовательность символов "urn: " не чувствительна к регистру. А идентификаторы пространства имён «urn» и «URN» запрещены вообще, чтобы не возникло путаницы с этой начальной строкой "urn: ".

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

Такие URN используются:

• в составе magnet-ссылки;
• в HTTP-заголовке X-Content-URN, предложенном в «HTTP Extensions for a Content-Addressable Web»^[1] и нашедшем применение в p2p-сети Gnutella2;
• согласно RFC 2169^[2] в Gnutella2 используются URL-ссылки, которые также содержат такой URN.

• URN книги, идентифицируемой номером ISBN

urn:isbn:5170224575

• URN технической спецификации RFC 3406 (англ. Request For Comments — запрос комментариев, см. RFC) организации «IETF»

urn:ietf:rfc:3406

• URN Российской Федерации, определённой по коду OID.^[3]

urn:oid:2.16.643

• URN конкретного файла MP3, идентифицируемого хеш-кодом по алгоритму SHA1

urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

• URN, идентифицирующий ресурс через идентификатор UUID (версии 1)

urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66

• URN конкретного файла AVI, идентифицируемого хеш-кодом по алгоритму TTH

urn:tree:tiger:SLW7H5LWXRCK3WFX5USVWIUYCOLSBTZRYGCAOJY

В показанных примерах «isbn», «ietf», «oid», «sha1», «uuid» и «tree» — это пространства имён, т. н. <NID> (см. выше), а строки за вторым двоеточием — это <NSS>.

• URI
• URL
• PURL
• DOI
• IRI
• XRI
• XML
• TTH
• Нормализация URL

• RFC 2141 — Синтаксис URN
• RFC 1737 — Функциональные требования к URN
• RFC 2483 — Системы разрешения URI для URN
• RFC 3406 — Определение пространств имён для URN
• RFC 3986 / STD 66 — Спецификация URI
• Рабочая группа URN в IETF
• Пространства имён URN, зарегистрированные в IANA