1. はじめに

統一リソース名 (URN) は、"urn" URI スキームおよび特定の URN 名前空間の下で割り当てられる統一リソース識別子 (URI) [RFC3986] であり、URN が永続的で場所に依存しないリソース識別子となることを意図しています。URN 名前空間とは、そのような URN の集合であり、各 URN は (1) 一意であり、(2) 一貫した管理された方法で割り当てられ、(3) 共通の定義に従って割り当てられます。(一部の URN 名前空間は URN としてのみ存在する名前を作成しますが、他の名前空間は、ISBN [RFC3187]、ISSN [RFC3044]、RFC [RFC2648] など、非 URN 識別子システムで既に作成された名前に基づいて URN を割り当てます。)

URN の割り当ては、"urn" スキーム内で URN 名前空間を正式に委任された組織 (場合によっては、アルゴリズムやその他の自動化されたプロセス) によって行われます (例えば、"example" URN 名前空間 [RFC6963] の URN は "urn:example:foo" という形式になるかもしれません)。

この文書は、次の 2 つの重要な前提に基づいています。

1. URN の割り当ては管理されたプロセスである。

2. URN 名前空間の空間自体が管理されている。

他の URI スキームではリソース識別子を自由に選択して割り当てることが許されているかもしれませんが、URN の場合はそうではありません。"urn:" で始まる名前の構文的な正しさだけでは、それを URN とするのに十分ではありません。その名前が有効な URN となるためには、名前空間識別子 (NID) がここで定義する規則に従って登録されている必要があり、URN の assigned-name 部分の残りの部分は、登録された URN 名前空間の規則に従って生成されている必要があります。

URN 構文と URN 名前空間の両方に関する情報を一か所で利用できるようにするため、この文書は次のことを行います。

1. URN 全般の正規構文を (URI 構文と整合する方法で) 定義し、URN 等価性を判定する方法を規定し、URI 準拠について論じます。

2. URN 名前空間を定義し、それを特定の NID に関連付ける方法を規定し、インターネット割り当て番号機関 (IANA) に URN NID を登録する手順を説明します。

URN 構文と URN 名前空間について、この文書は URN 構文の原仕様 [RFC2141] ならびに URN 名前空間の定義と登録の原仕様 [RFC3406] を現代化して置き換えます。これらの変更は、URN の当初の機能記述 [RFC1737] に示された主要な要件と、長年の経験から得られた教訓に基づいています。それらの当初の文書および本書において意図されているのは、URN を一貫した方法で定義し、実用的な範囲で、URN の解析、処理、および解決が、特定の URN が割り当てられる URN 名前空間から独立して行えるようにすることです。

いくつかの主要なユーザーコミュニティからの意見と合わせて、URN の歴史と経験は、RFC 2141 で将来の標準化のために明示的に予約されていた構文の使用を含め、新しい機能をサポートするために URN の定義を拡張することを要請しました。以前の仕様の下で有効であったすべての URN 名前空間および URN は引き続き有効です。ただし、一部の URN 名前空間の定義を更新して新機能を活用することが有用な場合もあります。

以上のような考慮事項、ならびに URN とロケータである URI (具体的には URL) との間のさまざまな相違、および [RFC1738] と [RFC1808] の最終的な後継としての RFC 3986 における URL へのより大きな注目は、RFC 3986 と本仕様の一部の解釈が、特に基本構文そのもの以外の動作や意味論に関して、完全には整合していないように見える (あるいは実際に整合していない) 結果を招く可能性があります。そのような状況が生じた場合、URN および URN 名前空間に関する議論は、RFC 3986 からの外挿ではなく、この文書に従って解釈されるべきです。

RFC 2141 および RFC 3406 からの変更点の概要は、それぞれ 付録 B および 付録 C に示します。この文書は [RFC2141] と [RFC3406] の両方を廃止します。明示的に [RFC1737] や [RFC2276] を更新または置き換えるものではありませんが、それらの文書を参照する読者は、この文書における URN の概念モデルがそれらの古い仕様とは少し異なることに留意すべきです。

1.1. 用語

以下の用語は、以下に述べるように互いに区別されます。

URN: "urn" スキームを使用し、その文書に記述されている "name" の特性ならびに本書に記述されている特性を併せ持つ URI (RFC 3986 で定義)。この用語は、任意のコンポーネントを含む URI 全体に適用されます。読者への注意: "URN" という用語は、他の文脈では URN 名前空間、名前空間識別子、assigned-name、および "urn" スキームを使用しない URI を指すために用いられてきました。これらのうち最後のものを除くすべては、本書の他の箇所でより具体的な用語を用いて説明されていますが、それらの他の用法があるため、この用語は注意して使用し解釈すべきです。

ロケータ: リソースにアクセスする手段を提供する識別子。

識別子システム: 管理された名前の集合。本書では、URN の文脈以外の識別子システムを「非 URN 識別子システム」と呼びます。

URN 名前空間: URN NID に関連付けられた識別子システム。

NID: URN 名前空間に関連付けられた識別子。

NSS: URN の URN 名前空間固有の部分。

assigned-name: "urn:" スキーム、NID、および名前空間固有文字列 (NSS) の組み合わせ。したがって、assigned-name は、URN が追加のコンポーネントを含む場合、(上で定義した) URN の部分文字列です (2 節を参照)。

「名前 (name)」という用語は、ここでは意図的に定義されておらず、非常に非公式にのみ使用されるべきです (そして実際にそのように使用されています)。RFC 3986 はこの用語を、「ロケータ」と区別される URI のカテゴリとして使用していますが (1.1.3 節)、他の文脈でも使用しています。それらの用法を定義的なものとして扱うと、例えば URN 名前空間名 (すなわち NID) の概念や、非 URN 識別子システムに関連する用語と矛盾することになります。

本書では、「リソース」、「識別子」、「識別する」、「逆参照する」、「表現」、および「メタデータ」という用語を、URI 仕様 [RFC3986] で定義されているのとほぼ同じ意味で使用します。

本書では、「解決 (resolution)」および「リゾルバー (resolver)」という用語を、URN のアーキテクチャ原則に関する当初の議論 [RFC2276] で用いられていたのとほぼ同じ意味で使用します。すなわち、「解決」とは、識別されたリソースに関連するサービスを提供する行為であり、例えば永続的な URN をリソースの 1 つ以上の現在のロケータに変換すること、リソースに関するメタデータを適切な形式で配信すること、あるいはさらなる仲介者を必要とせずにリソースの表現 (例えば文書) を配信することなどです。本書執筆時点では、解決サービスは [RFC2483] に記述されています。

表現とメタデータの区別については、[RFC3986] の 1.2.2 節を参照してください。

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 の現代化された定義を提供するコンセンサス仕様を作成するために必要でした (魅力的でない代替案は、広く展開されているにもかかわらず定義を現代化しないことでした)。

以下の小節では、関連する問題のうち 2 つをより詳細に説明します。

1.2.1. 解決

URN に固有の問題 (一般的な名前付けシステムとは対照的) の 1 つは、「解決」というかなり難しい話題であり、1.1 節、2.3.1 節、6.4.6 節、および以下の他の箇所で論じられています。

従来の統一リソースロケータ (URL)、すなわちロケータであるほとんどの URI では、解決は比較的単純です。なぜなら、解決はアクセス機構を決定するために使用され、その機構が次に、関連するリソースの表現 (例えば文書) を (通常は) 取得することによってロケータを逆参照するために使用されるからです ([RFC3986] の 1.2.2 節を参照)。

対照的に、URN の解決はより柔軟で多様です。

重要なケースの 1 つは、URN を 1 つ以上のロケータにマッピングする場合です。この場合でも、最終的な結果は、マッピングされたロケータを 1 つ以上の表現へと逆参照する問題です。ここでの主な違いは永続性です。マッピングされたロケータが変更された場合 (例えば、DNS ドメイン名が所有者を変え、URL が新しい場所を指すように修正されていない場合、あるいはより極端で仮想的なケースとして、DNS が完全に置き換えられた場合) でも、リゾルバーが URN からロケータへのマッピングを最新の状態に保っていれば、URN の利用者は正しい表現 (例えば文書) を取得できます。したがって、ロケータに解決され、そのロケータがさらに逆参照されて表現となる URN については、関連する関係をかなり正確に定義できます。

しかし、本仕様は、他のいくつかの URN 解決のケースや、情報検索システムを伴わないリソースのための URN も認めています。これは、特定の URN について個別に当てはまる場合もあれば、(以下で定義するように) URN 名前空間全体について集合的に当てはまる場合もあります。

基盤となるシステムがリソースの表現を含まないため、ロケータに解決され、そのロケータがさらにリソースに関するメタデータにのみ逆参照される URN の名前空間を考えてみましょう。例としては、関連規格 [ISO.27729.2012] で定義されている識別子システムである国際標準名称識別子 (ISNI) のための URN 名前空間が挙げられ、そこでは既定で URN は ISNI によって識別される公的なアイデンティティを記述するメタデータレコードにのみ解決されます。

また、要求元の実体が表現を取得する権限を持つ場合にのみ表現に解決され、他の実体はリソースに関するメタデータしか取得できない URN も考えてみましょう。例としては、国立図書館の法定納本コレクションに保管されている文書が挙げられます。

最後に、一部の URN はそもそもロケータに解決されることを意図していないかもしれません。例としては、XML 名前空間名を識別する URN (例えば [RFC6288] で規定された "dgiwg" URN 名前空間)、通信プロトコル内でサポートできるアプリケーション機能を識別する URN (例えば [RFC7462] で規定された "alert" URN 名前空間)、およびレジストリ内の値などの列挙型を識別する URN (例えば [IANA-URN] で暫定的に提案されているように、URN 名前空間を使用してすべての IANA レジストリ内の値を個別に識別できる) が挙げられます。

さまざまな種類の URN と、それらに対して利用可能な複数の解決サービスは、URN にとって「解決」の概念を、ロケータに解決されさらに表現へと逆参照されるという単純なケースよりも複雑にしますが、同時にはるかに豊かなものにします。

1.2.2. 文字集合とエンコーディング

同様の一連の考慮事項が、文字集合とエンコーディングにも当てはまります。URN、特にユーザーに提示される識別子として使用される URN は、現地の言語や書記体系で使用するのに便利で、幅広いキーボードや現地の慣習で容易に入力でき、かつ曖昧でないべきです。これらの目標の間にはトレードオフがあり、現時点では、すべての URN にとって最適、あるいは合理的ですらあるような、単純で理解しやすい一連の規則をどのように策定できるかは分かりません。2.2 節の議論では、一般的な解析と処理を可能にする全体的な枠組みを定義するとともに、個々の URN 名前空間の規則に関する推奨事項も示します。