要約

  • RFC 3553 は2003年、登録済みプロトコルパラメーターを永続的に識別する urn:ietf:params を設けた。ただし、汎用の解決機構も検証機構も定義しなかった。
  • 名前の意味を守るには、変化する現在値を名前に含めてはならない。永続名が指せるのは値を収める安定したスロットであり、値、レジストリ画面、実装動作は別の証拠である。

urn:ietf:params:xml:ns:... という文字列を見ると、コロンの左から右へ権限が順番に委譲されているように感じる。しかし RFC 3553 は、この名前空間を「主として不透明」とした。コロンには限定された階層表現があるが、一般的なパーサーが文字列を分割しただけでは、各部分を誰が管理し、何を正規形とし、どの仕様が意味を与えるかは決まらない。

この慎重さは当時の実務課題から生まれた。IETF 標準は、IANA に登録されたポート、メディア型、番号、その他のパラメーターをスキーマの中で参照する必要があった。現在のウェブ URL をそのまま識別子にすれば、サーバー移転やファイル再編が意味の変更に見えてしまう。文書ごとに独自 URI を作れば、同じ対象に複数の名前が生まれる。

2003年6月に BCP 73 として公表された RFC 3553 は、RFC 2648 の ietf URN の下に params を追加した。IETF の合意過程が登録を認め、IANA が重複を防いで記録を維持する。割り当て済みの名前は別の目的へ再割り当てしてはならない。これは識別の台帳であって、実装を遠隔操作する仕組みではない。

永続性の条項には、さらに厳しい制限がある。意味が時とともに変わる値を、そのまま永続名にしてはならない。値が変わるなら、名前は値を入れるスロットや概念を指す。値そのものを名前に入れられるのは、版番号のように、その値が永続的かつ一意である場合だけだ。今日の内容を不変の身分証にしてはならないのである。

したがって、同じ文字列であることと、同じ処理結果であることは遠い。RFC 3553 当時の規則は字句同値を厳密な文字列比較に結び付け、必要な大文字小文字変換などを各登録で明記させた。文字列が一致すれば識別子の一致を論じられる。二つの製品が同じ版を理解し、同じポリシーを適用し、同じ結果を出すとは言えない。

文書は解決機構を定義せず、検証機構も定義しなかった。グローバルな範囲は、世界中から自動的に URL へ変換できるという意味ではない。構文に合う文字列、IANA に存在する行、引用仕様の意味、製品の対応、正しい実行、観測された成功は、それぞれ独立した確認段階である。

登録テンプレートは、レジストリ名、仕様、権威あるリポジトリ、URN に埋め込む索引値を求めた。ただしリポジトリは「現在」の場所であり、ファイルやサーバーの移動に伴って変わり得る。これは初期の対応先を示す手掛かりで、永遠のファイル名ではない。運用の住所を交換可能にしたことが、名前の継続性を支えた。

今回凍結した IANA の記録は2026年2月2日更新で、ietf 直下に七つ、params の下に23の登録識別子を載せる。xml、oauth、netconf、scim、acme、jmap、whip、unit などである。この数字は台帳が現在も保守されている証拠にはなる。導入率、相互運用性、製品安全性、特定セッションの成功率にはならない。

RFC 3688 は xml 分岐とその下のレジストリを定め、RFC 6755 は oauth 分岐を登録した。後年の RFC 6924 は ietf 直下の分岐を一枚の IANA 表で見られるようにし、手続名を IETF Review に整えた。RFC 8141 は一般 URN 構文について RFC 2141 を置き換えた。周囲の制度が変わっても同じ名前が同じ概念を指せることこそ、設計の成果である。

監査では、受信した完全な文字列、参照した IANA スナップショット、根拠仕様、実装と版、ローカル判断、実行結果を別々に残すべきだ。URN だけなら意図された対象は分かっても、動作は分からない。リポジトリ URL だけなら、その日に見た場所は分かっても、移転後に守るべき同一性が分からない。

RFC 3553 は、名前に過大な権力を持たせなかった。IANA の台帳は唯一性と意味を守る。実際のコードは認識と振る舞いを示す。両者を分けたからこそ、名前は現在値にも現在住所にも道連れにされず、二十年以上を越えて残った。

情報源