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

4. URI 準拠

4.1. URI プロトコルスロットでの使用​

URN は構文的には "urn" スキームの下の URI であるため、理論上、URN は URI を許可する任意のプロトコルスロット (ほんの数例を挙げれば、HTML の "href" 属性と "src" 属性、HTML の base 要素、XML の "xml:base" 属性 [XML-BASE]、および XML 名前空間名のための XML の "xmlns" 属性 [XML-NAMES]) に置くことができます。

しかし、これは、意味論的に、URN を特定の URI プロトコルスロットに置くことが実際に常に妥当であるということを意味するものではありません。特に、URN はリソースの場所を指定しない場合や、リソースを間接的に指すことさえない場合があるため、リソースを指す URI プロトコルスロット (例えば前述の "href" 属性と "src" 属性) に URN を置くことは適切でないかもしれません。

最終的に、"urn" スキーム (またはその他の任意のスキーム) の下の URI をいつ使用するのが適切かに関するガイドラインは、個々の URI プロトコルスロットの仕様の責任です (例えば、XML の "xml:base" 属性の仕様は、そのプロトコルスロットで URN を使用するのは不適切であると勧告するかもしれません)。本仕様は関連するすべてのケースを予見することはできず、個々のプロトコルスロットについて使用を要求または制限するのは本仕様の役割ではありません。

4.2. 解析​

URN の意味論をより一般的な URI 構文から分離していることもあり、汎用 URI プロセッサは RFC 3986 の解析および分析の規則に特別な注意を払う必要があり、特に、スキームとその要件が認識されない限り URI を不透明なものとして扱わなければなりません。後者の場合、そのようなプロセッサは、例えば URN リゾルバーによる、スキームに適した処理を呼び出せる立場にあるかもしれません。URN リゾルバーは、URI リゾルバーが知っている外部リゾルバーである場合もあれば、URI リゾルバーに組み込まれた機能である場合もあります。この要件は、URN が適切に使用される文脈に制約を課す可能性があることに注意してください。4.1 節を参照してください。

4.3. URN と相対参照​

[RFC3986] の 5.2 節は、所与の基底 URI に対して相対的である可能性のある URI 参照を、その参照の対象の「解析済みコンポーネント」に変換し、その後 RFC 3986 の 5.3 節に従って対象 URI に再構成できるようにするアルゴリズムを記述しています。このアルゴリズムは、URN の構文が必要なパスコンポーネントをサポートしていないため、URN にとって問題があります。しかし、このアルゴリズムが特定のスキームから独立して適用される場合、以下の了解事項 (構文の生成規則の用語は RFC 3986 から借用) の下で、URN についても予測可能に機能するはずです。

  1. <relative-ref> の構文に従う <URI-reference> に遭遇したシステムは、それが明示的に "urn" スキームを持つかどうかにかかわらず、RFC 3986 で規定されているようにそれを対象 URI に変換します。

  2. URN の永続性と安定性に関する期待のため、URN を利用する文書などの作成者は、一般的に、RFC 3986 で規定される <URI> に厳密には該当しない任意の <URI-reference> において "urn" スキームを使用することを避けるべきです。特に、<relative-ref> の処理を必要とするものを含みます。

4.4. 転送と表示​

URN が転送および交換されるとき、それらは本明細書で定義される形式で表現しなければなりません (MUST)。さらに、URN を認識するアプリケーションは、(例えばコピーアンドペーストの手法による) 直接的な転記を可能にするために、この正規形式で URN を表示するオプションを提供することが強く推奨されます。そのようなアプリケーションは、より人間に優しい形式で URN を表示することをサポートする場合があり、本仕様で定義される URN 構文では許可されない文字を含む文字集合を使用する場合があります (例えば、人間に URN を表示する際に、そのようなアプリケーションはパーセントエンコードされた文字列を Unicode [UNICODE] などの拡張文字レパートリーの文字に置き換える場合があります)。

ユーザーの混乱を最小限にするために、URI を表示するアプリケーションは、URN NID と URI スキーム識別子の間の混乱がないことを確実にするために、完全な URI (URN の場合、その "urn" スキームと任意のコンポーネントを含む) を表示すべきです (SHOULD)。例えば、"urn:xmpp:" [RFC4854] で始まる URI は、"xmpp:" [RFC5122] で始まる URI とは大きく異なります。同様に、潜在的なデジタルオブジェクト識別子 (DOI) URI スキーム [DOI-URI] は、可能性のある DOI URN 名前空間とは異なり、おそらく完全に無関係です。

4.5. URI の設計と所有権​

前述のように、URN 名前空間内での URN の割り当ては、URN 名前空間自体の割り当てと同様に、管理されたプロセスです。所与の URN 名前空間内で割り当てられる URN の設計は本仕様によって URN 名前空間管理者に委ねられていますが、それを管理された方法で行うことにより、URI の設計と所有権に関する勧告 [RFC7320] に記述されている、URI の管理されない生成に固有の問題を回避できます。