メインコンテンツまでスキップ

2. URN 構文

上で述べたように、本仕様における URN の構文は、以前の仕様 (直近では [RFC2141]) よりもはるかに多くの機能を許容します。また、一般的な URI 構文 [RFC3986] と調和しています (注意すべき点として、URI 構文は以前の URN 仕様より後に完成しました)。

しかし、本仕様は、ASCII 範囲 [RFC20] 外の文字を直接使用できるように URN 構文を拡張してはいません。この制限は、そのような文字はすべて URI 仕様 [RFC3986] の 2.1 節に記述されているようにパーセントエンコードする必要があることを意味します。

URN の基本構文は、[RFC5234] で規定されている拡張 Backus-Naur 記法 (ABNF) を使用して定義されます。ここで定義されていない規則 (具体的には alphanum、fragment、および pchar) は URI 構文 [RFC3986] の一部として定義されており、ここではそこでの用語との構文的な関係を示すために使用されています。以下で使用される一部の用語の定義は網羅的ではありません。追加の制限は、それらの用語に固有の本書の節 (特に 2.3.1 節の r-component と 2.3.2 節の q-component) にある文章によって課されます。

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-component、q-component、および f-component の内部ではパーセントエンコーディングなしで使用できます。これらのコンポーネントの内部以外では、直後に "=" または "+" が続かない "?" は URN に対して定義されておらず、URN 固有のパーサーやその他のプロセッサはそれを構文エラーとして扱うべきです (SHOULD)。

以下の節では、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:example:1/406/47452/2" のような URN が得られます。

NSS の構文に対するこれらの変更は、[RFC2141] に従って定義された URN 名前空間のエンコーディング規則を変更するものではありません。URN の文脈以外 (すなわち非 URN 識別子システム内) で名前が使用されるそのような URN 名前空間が、その識別子システム内のネイティブ形式で "/"、"~"、または "&" の使用も許可している場合、その URN 名前空間のエンコーディング規則は本仕様によって変更されません。

非 URN 識別子システムおよびそれに関連する URN 名前空間を規定する規則によっては、その識別子システムで有効な名前が、上で参照した "pchar" 生成規則では許可されない文字 (例えば ASCII 範囲外の文字、または RFC 3986 の制限と整合する形で "/"、"?"、"#"、"["、および "]" という文字) を含む場合があります。そのような名前は非 URN 識別子システム内では有効かもしれませんが、その特定の URN 名前空間の規則に準拠する NSS に変換されるまでは有効な URN ではありません。非 URN 識別子システムに別個に存在する名前から形成される URN の場合、名前を「ネイティブ」形式から URN 形式に変換することは、URN 全般に対して定義された正規化およびエンコーディングの方法、またはその URN 名前空間に固有の規則を使用して行われます。名前空間固有の正規化およびエンコーディング規則を認識していないソフトウェアは、非 URN 識別子システムの名前から URN を構築してはなりません (MUST NOT)。

特に、ASCII 範囲外の文字に関して、プロトコル内に現れる URN やシステム間で受け渡される URN は、UTF-8 でエンコードされ、さらに RFC 3986 の要求に従ってエンコードされた Unicode 文字のみを使用しなければなりません (MUST)。可能な範囲で、かつ他の場所で定義および標準化された名前の要件ならびに 1.2 節で論じた原則と整合する限り、名前を表現するために使用される文字は、ASCII の英字と数字、またはアプリケーションにおける国際化ドメイン名 (IDNA) [RFC5890]、国際化文字列の準備、実施、および比較 (PRECIS) [RFC7613]、あるいは Unicode 識別子およびパターン構文仕様 [UAX31] といった広く使用されているモデルの文字と構文のいずれかに制限されるべきです (SHOULD)。

プロトコルが進化し、その周囲の環境が変化する中で URN を可能な限り安定かつ永続的にするために、URN 名前空間は、その特定の URN 名前空間の性質がそのような文字を必要としない限り、ASCII 範囲 [RFC20] 外の文字を許可すべきではありません (SHOULD NOT)。

2.3. 任意のコンポーネント​

本仕様は、URN 構文に 3 つの任意のコンポーネントを含めています。それらは r-component、q-component、および f-component と呼ばれ、以下でより詳細に説明します。本仕様はほぼもっぱら URN 構文に焦点を当てているため、URN 全般に対するこれらのコンポーネントの詳細な意味論は定義していません。しかし、これらのコンポーネントのそれぞれは、任意の URN およびその URN 名前空間から独立した独自の役割を持っています。クライアントがすべての URN についてこれらのコンポーネントを統一的に扱えるようにすることが意図されています。これらのコンポーネントは、URN 名前空間がそれらを明示的にサポートしているかどうかにかかわらず、既存の URN 名前空間の URN と共に使用してもかまいません (MAY)。ただし、RFC 3986 で取られているアプローチと整合する形で、特定の URN 名前空間やリソースにとって未定義または無意味なコンポーネントを含む URN の動作は定義されていません。以下の節では、これらの任意のコンポーネントとその解釈についてより詳細に説明します。

2.3.1. r-component​

r-component は、URN 解決サービス (広義に解釈、1.2 節を参照) にパラメータを渡し、それらのサービスによって解釈されることを意図しています。(対照的に、URN によって識別されるリソースや、そのようなリソースを管理するアプリケーションにパラメータを渡すことは、次の節で説明するように q-component によって処理されます。)

URN の r-component には、他の既知の URI スキームにおける構文的な対応物がありません。

シーケンス "?+" が r-component を導入します。r-component は、"?=" シーケンス (q-component を開始する) または "#" 文字 (番号記号。f-component を開始する) で終了します。これらのいずれも現れない場合、r-component は URN の末尾まで続きます。ASCII 範囲 [RFC20] 外の文字は、汎用 URI 仕様 [RFC3986] の 2.1 節で定義された方法を使用してパーセントエンコードしなければなりません (MUST)。

3 節で説明するように、URN 等価性を判定する際に r-component を考慮してはなりません (SHALL NOT)。ただし、URN 解決サービスに要求を提示する際には、r-component を URN と共に提供しなければなりません (SHALL)。

本書は r-component の構文のみを定義し、将来の使用のために予約します。r-component の正確な意味論および URN 解決プロトコルにおけるその使用は、別個の仕様において標準化される可能性のある事項であり、おそらく解決サービス識別子のための規約とレジストリを定義する仕様を含むでしょう。

解決サービスにパラメータを渡す仮想的な例 (例えば、書籍の物理的な複製を検索する優先国を選択するための ISO alpha-2 国コード [ISO.3166-1]) を考えてみましょう。これはおそらく、国コードを r-component に指定することによって実現でき、次のような URN が得られます。

urn:example:foo-bar-baz-qux?+CCResolve:cc=uk

上記は r-component の意図に関する一般的な説明と例示として役立つはずですが、登録時における特定の URN 名前空間に関連付けられた解決機構との関係など、多くの未解決の問題があります。したがって、r-component は、その意味論が標準化される前に URN に使用すべきではありません (SHOULD NOT)。

2.3.2. q-component​

q-component は、名前付きリソースまたは要求されたサービスを提供できるシステムにパラメータを渡し、そのリソースまたはシステムによって解釈されることを意図しています。(対照的に、URN 解決サービスにパラメータを渡すことは、前の節で説明したように r-component によって処理されます。)

URN の q-component は URI のクエリコンポーネントと同じ構文を持ちますが、"?" 単独ではなく "?=" によって導入されます。ロケータである URI に解決され得る URN について、q-component の意味論はその URI のクエリコンポーネントの意味論と同一です。したがって、q-component を持つ URN に対してロケータである URI を返す URN リゾルバーは、URN から URI のクエリコンポーネントへ q-component をコピーすることによってこれを行います。コピー操作の例を以下に示します。

本仕様は、元の URN が q-component を持ち、URI がクエリ文字列を持つ場合に、URN がロケータである URI に解決されるケースにおける必須の動作を規定していません。状況によって異なるアプローチが必要になる場合があります。リゾルバーは、そのような場合の戦略を文書化すべきです (SHOULD)。

URN がロケータである URI に解決されない場合、q-component の解釈は本仕様では定義されていません。ロケータである URI に解決され得る URN について、q-component の意味論は、その URI を介して位置づけられるリソースへのクエリの意味論と同一です。

RFC 3986 との整合性のために、q-component の一般的な構文と意味論は、URN の URN 名前空間によって定義されたり、それに依存したりしません。RFC 3986 と並行して、構文と意味論の詳細 (例えばどのキーワードや用語が意味を持つか) は、もちろん特定の URN 名前空間や、特定のリソースにさえ依存する場合があります。

シーケンス "?=" が q-component を導入します。q-component は "#" 文字 (番号記号。f-component を開始する) で終了します。その文字が現れない場合、q-component は URN の末尾まで続きます。スラッシュ ("/") と疑問符 ("?") の文字は、q-component 内のデータを表す場合があります。ASCII 範囲 [RFC20] 外の文字は、汎用 URI 仕様 [RFC3986] の 2.1 節で定義された方法を使用してパーセントエンコードしなければなりません (MUST)。

3 節で説明するように、URN 等価性を判定する際に q-component を考慮してはなりません (SHALL NOT)。

URN 名前空間および構文内の関連情報の配置は、解決サービスが q-component を考慮する必要が生じないように設計されるべきです (SHOULD)。名前空間固有の解決システムおよびより一般的な解決システムは、処理のために q-component の情報を渡されることを要求してはなりません (MUST NOT)。

異なる地域の、または異なる期間の天気予報を返すアプリケーションにパラメータを渡す仮想的な例を考えてみましょう。これはおそらく、緯度と経度の座標および日時を URN の q-component に指定することによって実現でき、次のような 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-component​

f-component は、名前付きリソース内の位置または領域の指定としてクライアントによって解釈されることを意図しています。これは、URN によって名付けられたリソースの構成部分を区別します。表現へ逆参照できる 1 つ以上のロケータに解決される URN、または URN リゾルバーがリソースの表現を直接返す URN について、f-component の意味論はその表現のメディアタイプによって定義されます。

URN の f-component は URI のフラグメントコンポーネントと同じ構文を持ちます。f-component を含む URN が、名前付きリソースに関連付けられたロケータである単一の URI に解決される場合、URN からの f-component を (通常はクライアントによって) その URI のフラグメントとして適用できます。URN がロケータである URI に解決されない場合、f-component の解釈は本仕様では定義されていません。したがって、ロケータである URI に解決され得る URN について、f-component の意味論はそのリソースのフラグメントの意味論と同一です。

RFC 3986 との整合性のために、f-component の一般的な構文も意味論も、URN の URN 名前空間によって定義されたり、それに依存したりしません。RFC 3986 と並行して、構文と意味論の詳細 (例えばどのキーワードや用語が意味を持つか) は、もちろん特定の URN 名前空間や、特定のリソースにさえ依存する場合があります。

f-component は番号記号 ("#") 文字によって導入され、URI の末尾によって終了します。f-component 内に現れる ASCII 範囲 [RFC20] 外の文字は、汎用 URI 仕様 [RFC3986] の 2.1 節で定義された方法を使用してパーセントエンコードしなければなりません (MUST)。

3 節で説明するように、URN 等価性を判定する際に f-component を考慮してはなりません (SHALL NOT)。

クライアントは、解決サービスがオブジェクトの取得および解釈の機能も実行しない限り、f-component を解決サービスに渡すべきではありません (SHOULD NOT)。

より大きな実体の一部であるリソース (例えば、本の章) を取得する仮想的な例を考えてみましょう。各部分を f-component に指定でき、次のような URN が得られます。

urn:example:foo-bar-baz-qux#somepart