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 , яка розв'язує імена 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 витіснять URL, мабуть, ще далеко, але вже зараз можна сказати, що перспективи у URN відмінні. 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.804

• 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
• DOI
• XML
• TTH
• Нормалізація URL
• IRI
• XRI
• PURL

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