URN
URN (англ. Uniform Resource Name) — уніфікована назва (ім'я) ресурсу. На англійський манер вимовляється як слово earn, українською частіше говорять [ у-ер-ен ]. URN — це постійна послідовність символів, що ідентифікує абстрактний або фізичний ресурс. URN є частиною концепції URI (англ. Uniform Resource Identifier) — уніфікованих ідентифікаторів ресурсу. Імена URN покликані в майбутньому замінити локатори URL (англ. Uniform Resource Locator) — уніфіковані визначники місцезнаходження ресурсів. Але імена URN, на відміну від URL, не включають в себе вказівки на місцезнаходження та спосіб звернення до ресурсу. Стандарт 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 [en], яка розв'язує імена 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.
NID | Розрядність | Кодування | Приклад |
---|---|---|---|
tree: tiger | 192 | Base32 | Urn: tree: tiger:7N5OAMRNGMSSEUE3ORHOKWN4WWIQ5X4EBOOTLJY |
Sha1 | 160 | Base32 | Urn: sha1:XRX2PEFXOOEJFRVUCX6HMZMKS5TWG4K5 |
btih | 160 | Base32 | Urn: btih: QHQXPYWMACKDWKP47RRVIV7VOURXFE5Q |
ed2k | 128 | Hex | Urn: ed2k:354B15E68FB8F36D7CD88FF94116CDC1 |
Md5 | 128 | Hex | Urn: md5:834CEF60EF3FD47162420FA25ABF2DFF |
Md4 | 128 | Hex | Urn: md4:bbd810ee7731921c4582daa00bbc531e |
Tiger | 192 | Hex | Urn: tiger: cf13102788e1e6ef6124cb9ca9ef879e4bb04c58fe297dd3 |
aich | 160 | Base32 | Urn: aich: wbtmcm2wrbndylixh3jmwsg4uowzjcqm |
Whirlpool | 512 | Hex | urn: whirlpool: dc38ce741d9c8be87a0d715fad951460c5299da2447c3fa8f1057b560f9253c7a017882dcc2390ab602c3b0f5fcf066d6d35f32ffa9b8e5557e1d2f619506873 |
ripemd160 | 160 | Hex | Urn: ripemd160:93f1cb4a43643136d730a3b94b0ebcec66928c02 |
gost | 256 | Hex | Urn: gost:906fd73511810bafdaa33c05b9957b07edd8dca9b6982c04a86f6c642eb6b062 |
Has160 | 160 | Hex | Urn: has160:85c292d359574b89985b2667c9725edb1c7d12fc |
snefru128 | 128 | Hex | Urn: snefru128:646b932fee2529db11d05425cff21978 |
snefru256 | 256 | Hex | Urn: snefru256:35879fc03ca60db551fa26ce8be6a6a04d542cf5a635ab203f95c6f1affb59a6 |
- URN книги, ідентифікованої номером ISBN
urn: isbn:5170224575
- URN технічної специфікації RFC 3406 (англ. Request For Comments — запит коментарів, див. RFC) організації «IETF»
urn: ietf: rfc:3406
urn: oid:2.16.804
urn: sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
- URN, що ідентифікує ресурс через ідентифікатор UUID (версії 1)
urn: uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
urn: tree: tiger: SLW7H5LWXRCK3WFX5USVWIUYCOLSBTZRYGCAOJY
В показаних прикладах «isbn», «ietf», «oid», «sha1», «uuid» і «tree» — це простори імен, т. зв. <NID> (Див. Вище), а рядки за другою двокрапкою — це <NSS>.
- ↑ HTTP Extensions for a Content-Addressable Web. Архів оригіналу за 28 липня 2011. Процитовано 13 червня 2015.
- ↑ RFC2169 — A Trivial Convention for using HTTP in URN Resolution. Архів оригіналу за 21 квітня 2015. Процитовано 13 червня 2015.
- ↑ OID Repository. Архів оригіналу за 15 червня 2015. Процитовано 13 червня 2015.
- RFC 2141 — Синтаксис URN
- RFC 1737 — Функціональні вимоги до URN
- RFC 2483 — Системи дозволу URI для URN
- RFC 3406 — Визначення просторів імен для URN
- RFC 3986 / STD 66 — Специфікація URI
- Робоча група URN в IETF
- Простори назв URN, зареєстровані в IANA [Архівовано 28 березня 2010 у Wayback Machine.]