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

6. URN 名前空間の定義と登録

6.1. 概要​

URN 名前空間の空間自体が管理されているため、URN 名前空間の定義は以下に特に注意を払うべきです (SHOULD)。

  1. URN 名前空間の目的。

  2. URN 名前空間内で割り当てられる URN の構文。r-component や q-component の内部構文および予想される影響を含みます。(f-component の構文と解釈は RFC 3986 で定義されています。)

  3. URN 名前空間内で URN を割り当てるプロセス。

  4. URN 名前空間内で URN を割り当てること、および割り当てられた URN を使用することのセキュリティ上の影響。

  5. URN 名前空間内で割り当てられた URN に関する潜在的な相互運用性の問題。

  6. 任意で、URN 名前空間内で割り当てられた URN を解決するプロセス。

テンプレートの記入に関する節 (6.4 節) では、これらの事項をより詳細に説明します。登録テンプレートはすべての場合で同じですが、登録の出所に応じて若干異なる手順が使用されます。

6.2. 登録ポリシーとプロセス: コミュニティ登録​

URN 名前空間の基本的な登録ポリシーは、IANA 考慮事項文書 [RFC5226] で定義されている Expert Review です。標準または標準の構成要素となることを意図した URN 名前空間またはその定義については、Expert Review プロセスの出力は、IANA に対する行動の指示ではなく報告書であることが意図されています (以下を参照)。主要な手順は次のとおりです。

  1. URN 名前空間登録テンプレート (6.4 節および 付録 A を参照) に記入します。これは Internet-Draft または別のシリーズの仕様の一部として行うこともできますが、それは要件ではありません。

  2. 記入済みのテンプレートをレビューのために [email protected] ディスカッションリストに送信します。

  3. 受け取ったコメントに対応する必要がある場合、手順 1 と 2 を繰り返します。

  4. Designated Expert が要求を承認し、標準化の行動が関与しない場合、IANA は要求された NID を登録します。標準化が見込まれる場合、Designated Expert は報告書を作成して適切な標準承認機関 (IETF の場合は IESG) に転送します。IANA は、その機関からの指示と Expert Review 報告書の写しを受け取った後にのみ、要求された NID を登録します。

URN 名前空間の登録は、新規登録について上に概説したのと同じ手順に従って登録テンプレートを更新することにより改訂できます。改訂された登録は、以前のバージョンとの相違を記述しなければならず (MUST)、基盤となる技術または URN 名前空間の管理プロセスにおける関連する変更に特に言及すべきです (SHOULD)。

これまでの URN 名前空間登録要求に関する経験は、登録者が当初は URN 名前空間の微妙な点のいくつかを理解していないことがあり、URN 名前空間を仕様の形で定義することが、登録者が意図するユーザーコミュニティとの「契約」を明確に定式化することを可能にすることを示しています。したがって、フォーマルな URN 名前空間の登録ポリシーは Expert Review であり、(登録テンプレートとは別個の) 仕様は厳密には要求されませんが、登録者は、URN 名前空間の定義を文書化し、本書に記述された問題を詳述する安定した仕様を提供すべきです (SHOULD)。

名前付けは難しく、論争の的になり得るため、URN 名前空間の登録者と Designated Expert は、登録要求の扱いについてラフコンセンサス ([RFC7282] を参照) に達するために、誠意と相互理解の精神で協力することが強く推奨されます。また、視点を提供したり問題を解決したりするのに役立つ場合は、追加の専門知識を議論に持ち込むことも推奨されます。

特に登録プロセスでの反復が長期化する場合、Designated Expert は、提案された NID に関する「競合状態」を避けるために合理的な予防措置を講じ、そのような状況が生じた場合には、申請者に当事者間で衝突を解決するよう促すことが期待されています。

6.3. 登録ポリシーとプロセス: 標準開発組織、学会、および類似の団体のためのファストトラック​

IETF は、既存の確立された標準 (特に識別子標準) を組み込むため、あるいは IETF の範囲やその Designated Expert が持ち得る主題知識をはるかに超える知識、用語、または情報を組織化する方法を反映するために、URN 名前空間が作成される状況が生じることを認識しています。登録要求が、認定された標準開発組織、学会、またはその指定者から発せられたものであるか、それらによって承認されている状況では、その団体の選択により、やや異なる手順が利用できます。

  1. URN 名前空間登録テンプレートは、6.2 節の手順 1 および 2 と同様に記入して提出します。

  2. 必要な外部標準や仕様を反映する、またはそれらを指し示す仕様が必要です。RFC シリーズでの公開や IETF プロセスを通じた公開 (例えば Internet-Draft としての投稿) は期待されておらず、ごく異例の状況下でのみ適切でしょう。

  3. ディスカッションリスト上でのレビューおよび Designated Expert によるレビューは厳密に助言的であり、どの助言を受け入れるかについての決定およびプロセスに割り当てる時間の長さは、厳密に外部団体の管理下にあります。

  4. その団体が申請は十分に成熟したと結論付けたとき、その代表者が IANA に NID の登録を完了するよう要求し、IANA がそれを行います。

要求元の実体を標準開発組織または学会として認定するかどうかについての決定は、IESG の責任です。

これに類似したモデルは、メディアタイプの登録を希望する認定された標準開発組織のために既に定義されています。その機構を記述した文書 [RFC6838] は、一般的なアプローチについてもう少し情報を提供しています。

6.4. テンプレートの記入​

URN 名前空間を定義し登録するためのテンプレートは 付録 A に示します。この節では、テンプレートを記入する際の考慮事項を説明します。

6.4.1. 目的​

テンプレートの「Purpose」の節では、次のような事項を記述します。

  1. URN 名前空間内で割り当てられた URN によって識別されるリソースの種類。

  2. URN 名前空間内で割り当てられた URN の適用範囲と適用可能性。これには、利用コミュニティ (例えば特定の国、業界、技術、または組織) に関する情報、割り当てられた URN が公衆ネットワークで使用されるか私設ネットワークで使用されるかなどを含めることができます。

  3. 意図するコミュニティ (およびインターネットコミュニティ全体) が、割り当てられた URN を使用または解決することからどのように利益を得るか。

  4. URN 名前空間が既存の URN 名前空間、URI スキーム、および非 URN 識別子システムとどのように関係し、それらを補完するか。

  5. 割り当てられた URN を使用または解決できるソフトウェアアプリケーションの種類 (例えば、異種の URN 名前空間を区別すること、永続的な方法でリソースを識別すること、または URN 名前空間に関連するサービスを意味のある形で解決しアクセスすることによって)。

  6. 解決サービスが利用可能であるか、または将来利用可能になるか (そして、そうである場合、そのサービスの性質または識別情報)。q-component および (標準化された時点での) r-component の意味論と構文の例は、たとえ詳細な定義が別の場所または後で提供されるとしても、ここで役立ちます。

  7. URN 名前空間またはその定義が、IETF またはその他の認定された標準化団体で開発中の標準の構成要素になることが見込まれるかどうか。

6.4.2. 構文​

テンプレートの「Syntax」の節には、次のものが含まれます。

  1. 基本的な URN 構文に準拠した、URN 名前空間内の URN の構造の記述。構造は、形式的な定義 (例えば ABNF [RFC5234] を使用)、準拠する URN を生成するためのアルゴリズム、または名前を構成部分に解析するための正規表現によって記述できます。あるいは、構造は不透明であってもかまいません。

  2. 割り当てられた URN のための特別な文字エンコーディング規則 (例えば、引用符に常に使用すべき文字)。

  3. URN 名前空間内の 2 つの名前の間の URN 等価性を判定するための規則。そのような規則は、常に、比較から生じ得る偽陰性を排除する効果を持っているべきです。適切で役立つ場合には、URI 仕様 [RFC3986] で定義された特定の等価規則や本書の 3 節を参照できます。URN 等価性の規則の例には、NSS 内の大文字と小文字の間の等価性、名前内のハイフンで区切られたグループとハイフンで区切られていないグループの間の等価性、または一重引用符と二重引用符の間の等価性があります。特に、非 URN 識別子システムからの名前の埋め込み形式を含む URN については、名前空間固有の特別なエンコーディングの考慮事項も存在する場合があります。(これらは、一般的な文字間の関係の扱いに関するいかなる種類のベストプラクティスについての規範的な記述でもないことに注意してください。そのような記述は、1 つの特定の URN 名前空間のみに限定されます。)

  4. URN 構文に準拠するために必要な特別な考慮事項。これは特に、URN の文脈で使用される既存の非 URN 識別子システムの場合に当てはまります。例えば、非 URN 識別子システムが URN 以外の文脈で使用される場合、URN 構文で予約されている文字を利用する場合があります。この節では、そのような文字に言及し、URN 構文に準拠するために必要なマッピングの概要を示すべきです。通常、これは URI 仕様 [RFC3986] の 2.1 節で規定され、本仕様の 1.2.2 節で論じられているように、その文字をパーセントエンコードすることによって処理されます。

  5. この URN 名前空間の文脈における q-component (例えばキーワード) または f-component (例えば事前定義された用語) の意味に関する特別な考慮事項。

6.4.3. 割り当て​

テンプレートの「Assignment」の節では、次のような事項を記述します。

  1. リソースに URN を割り当てるための機構または権限。割り当てが完全に開かれているのか (例えば、先着順 (FCFS) などの特定の手順に従う)、完全に閉じているのか (例えば私的な組織の場合)、あるいはさまざまな形で制限されているのか (例えば、特定の組織が認定した権限に委任されている) を明確にすべきです。制限されている場合、名前の割り当て者になる方法、または既存の割り当て権限に名前の割り当てを要求する方法を説明すべきです。

  2. URN 名前空間内の URN が一意であることを確実にするための方法。例えば、名前は単一の権限によって順次、または何らかの明確に定義されたプロセスに従って割り当てられる場合もあれば、割り当てが、それぞれが一意性の規則を尊重する責任を負う委任された権限の間で分割される場合もあり、また URN が、それ自体が一意性を保証するアルゴリズムに従って独立に作成される場合もあります。

6.4.4. セキュリティとプライバシー​

テンプレートの「Security and Privacy」の節では、URN 名前空間内の名前の割り当て、使用、および解決に関するセキュリティとプライバシーに関連する潜在的な問題を記述します。そのような問題の例には次のものがあります。

  • URN 等価性の比較中に偽陰性および偽陽性を生じさせることの結果 (本仕様の 3.1 節および「セキュリティ目的のための識別子比較における問題」[RFC6943] を参照)。

  • 名前が公衆インターネット上で伝達されるときの私的情報の漏洩。

  • ディレクトリ収集の可能性。

  • RFC のセキュリティ考慮事項に関するガイドライン [RFC3552] およびインターネットプロトコルのプライバシー考慮事項 [RFC6973] で論じられているさまざまな問題。特に、Global System for Mobile Communications Association (GSMA) / International Mobile station Equipment Identity (IMEI) 名前空間 [RFC7254] のプライバシー考慮事項の記述に注意してください。これはそのような場合の有用なモデルを提供するかもしれません。

6.4.5. 相互運用性​

「Interoperability」の節は、相互運用性に関連する既知の潜在的な問題を規定しなければなりません (MUST)。例としては、構文 (例えば特定の文字のパーセントエンコーディング) または適用範囲 (例えば関心領域の重複) のために、他の URN 名前空間、非 URN 識別子システム、または URI スキームとの混同の可能性が挙げられます。可能な限り、URN 名前空間の登録中に生じる懸念 (例えば、非 URN 識別子システムの構文または適用範囲に起因するもの) は、登録プロセスの一部として、またはそれと並行して解決されるべきです。

6.4.6. 解決​

「Resolution」の節は、URN 名前空間内で割り当てられた URN に対して解決機構が意図されているか、または見込まれているかを規定しなければなりません (MUST)。

解決が意図されている場合、この節は、URN 名前空間内で URN を割り当てる組織が、その URN 名前空間内の URN のための解決サービスを運用または推奨することを意図しているかどうかを規定すべきです (SHOULD)。さらに、割り当て組織が、公開して告知される解決サービスのための登録を実装することを意図している場合 (例えば、URN 解決のための当初のアーキテクチャ原則とサービス記述の精神で開発されたシステムを使用する場合 [RFC2276] [RFC2483])、この節は、割り当て組織によって公開告知されるための要件を列挙または参照すべきです (SHOULD)。さらに、この節は、この URN 名前空間の文脈における r-component の扱いに関する特別な考慮事項を記述すべきです (SHOULD)。

6.4.7. 追加情報​

「Additional Information」の節には、この登録または他の登録との関係を理解しようとする人々に役立つ情報を含めます。例えば、重複しているように見える可能性のある既存の URN 名前空間との比較などです。

テンプレートのこの節は任意です。