要約

  • RFC 3406が登録者に求めたのは、NIDだけではない。構文、一意性、永続性、発行権限、同値規則、検証、そして解決を行うかどうかまで説明することだった。IANA登録は常時稼働するリゾルバの保証ではない。
  • 後継のRFC 8141はExpert Reviewへ手続きを改めても、名前を再利用せず、同じ定義で一貫して発行し、管理組織が去っても継続できるという責任を残した。解決結果は、その時点のサービス記録にすぎない。

入口が消えても、目録番号は消えない

展示室が改装され、資料の保管場所が変わり、検索システムが入れ替わる。利用者の入口は何度も変わるが、目録番号まで毎回付け直せば、過去の論文や貸出記録は読めなくなる。場所と同一性を分けることは、長期保存の前提である。

URNの初期要件を定めたRFC 1737は、永続性と場所からの独立を掲げた。同時に、名前を発行する機関と、名前をURLなどへ写像する解決サービスを別の役割として扱った。解決サービスは複数でもよく、第三者が運営してもよく、権威性や可用性が同じである必要もない。

すると本当の設計課題は、urn:に続く文字列ではなくなる。誰がその空間を定義したのか。誰が発行できるのか。同じ名前を二つの資源へ与えない仕組みはあるか。最初の組織が消えたとき、記録と責任はどこへ移るのか。

Leslie Daigleは、この問いを登録手続きへ落とし込んだ一人だ。IETF Datatrackerには、彼女がRFC 2611とRFC 3406の著者として記録されている。2002年10月にBCP 66として出たRFC 3406は、Daigle、Dirk-Willem van Gulik、Renato Iannella、Patrik Faltstromの共同成果である。したがって、Daigle一人の発明とも、現在のURN全体に対する支配権とも記述すべきではない。

名前の前に二つの管理がある

RFC 3406は、URNの発行が管理された過程であり、URN名前空間の集合も管理されるという二つの前提を置いた。構文に合う文字列を勝手に正式名へ変えないための管理と、名前空間識別子（NID）の衝突を避けるための管理である。

同じ数字列は、出版、科学、産業、通信プロトコルで別々の意味を持ち得る。NIDは、残りの文字列をどの制度で読むかを示す。NIDが違えば、見た目の似たローカル識別子も別のグローバル名として扱える。ただし、NIDが登録されていることと、個々の名前が正規に発行されたことは別の証拠だ。

名前空間の内部では、一つの名前を複数の資源へ与えず、後から別の資源へ回さない。同じ資源にISBNと図書館固有番号のような複数の名前が付くことはあり得る。その逆に、古い名前を新しい対象へ転用すると、過去の引用が二つの意味を持ってしまう。

永続性は、まず「しないこと」で守られる。再割り当てをしない。リゾルバが停止していても、発行記録が保たれていれば名前の意味は残る。反対に、再利用された名前へ高速に応答するサービスは、可用性が高くても歴史的には壊れている。

登録テンプレートは責任分界表だった

RFC 3406のテンプレートは、登録組織と連絡先、構文、関連文書、一意性、永続性、発行過程、解決過程、字句上の同値、検証方法、範囲、安全性を記載させた。項目が多いのは、一つの確認で全てを証明できないからだ。

構文検査は形だけを見る。発行記録は権限と時点を見る。同値規則は、大文字小文字やハイフン、符号化の違いを同じ名前として扱うかを決める。検証はどこまで機械的に確認できるかを示す。解決は、その名前から今どんな結果を得るかという別の処理である。

正式名前空間には、既存空間では足りない理由、対象コミュニティーと一般のインターネット利用者への利益、IANAに求める措置も必要だった。さらに、管理組織の安定性、発行能力、旧名を再利用しない約束、組織が維持できなくなった場合の継続性を考慮する。

この審査は未来予測ではない。技術的に永続性を損なう設計は見つけられても、会社や団体の存続を保証できない。登録が作るのは、公開された約束と更新可能な責任記録だ。IANAが各空間の内部台帳や解決サービスを代行するわけではない。

解決は「どこにあるか」の観測

RFC 3406では、グローバルな解決を望む空間は、別途、解決発見システムへ登録し、認定リゾルバの条件を示す。解決システムへ載せず、当該空間では関係しないと答える選択肢もあった。

一つのURNから返すべき結果は常に一つとは限らない。あるサービスはメタデータを、別のサービスは利用地域に応じた複製を、さらに別のサービスは複数形式を返すかもしれない。利用権や時点で答えが変わるなら、固定URLを名前そのものと見なす方が不自然だ。

したがって、解決の記録には演算子が要る。「どの運営者が、いつ、どの方針で、何を返したか」である。その記録は発行の正当性を証明せず、他のリゾルバとの一致も、将来の到達性も保証しない。リンク先が表示できても、意図した資源だと確定したことにはならない。

古いURNが解決できなくなることと、古いURNを別物へ向けることも違う。RFC 3406は、継続解決を絶対条件にせず、再割り当てや偽・陳腐化した情報への誘導を拒んだ。アーカイブでは、正直な不在の方が誤った成功より安全な場合がある。

2017年版が受け継いだもの

Peter Saint-AndreとJohn KlensinによるRFC 8141は、RFC 2141と3406を置き換え、名前空間部分の基礎を築いたDaigleら四人を明記して謝意を示した。コミュニティー登録はExpert Reviewとなったが、一意性、一貫した発行、共通定義という三本柱は残った。

正式空間の発行組織には、長期間維持できる安定性、または維持不能時の継続策が求められる。発行能力と、割当先や資源が消えても既存URNを有効なままにする約束も必要だ。顧客関係の終了を、名前の再利用理由にはできない。

RFC 8141は、安定した仕様を登録者と利用コミュニティーの契約として位置付ける。目的、構文と同値、発行と一意性、セキュリティーとプライバシー、相互運用性、解決を記述し、改訂では技術や管理過程の変更を明示する。

解決欄は、解決を予定・想定するかを必ず答える。予定するなら、運営・推奨するサービスや公示条件を示す。開示すべきなのは方針と責任であり、全てのURNが永遠に一つのURLへ到達するという約束ではない。

IANAの現行レジストリにはISBN、DOI、プロトコル、業界向けなど異なる空間が並ぶ。取得時点のXMLには正式97件、非正式8件があった。この件数は変動するが、各テンプレートと参照仕様は、その空間が何を約束したかを調べる入口になる。

一回の検索を四つの証拠へ分ける

名前空間の証拠は、NID、テンプレート、仕様の版を保存する。発行の証拠は、認可された主体が規則どおり発行し、再利用していないことを示す。解決の証拠は、サービス、時刻、方針、返答を記録する。資源の証拠は、実際に取得した内容と、目的物だと判断した根拠を残す。

形が正しくても未発行かもしれない。正規発行でもリゾルバがない場合がある。正規リゾルバの結果でも資源が落ちていることはある。表示に成功しても別物かもしれない。四つを分ければ、名前を変えずに壊れた層だけを直せる。

Daigleの仕事から見えるのは、永続名が技術的なラベル以上のものだという点だ。それは、権限、抑制、記録、継承を含む制度である。リゾルバは今日の入口を作る。管理者は、昨日の名前が明日も同じ意味であるようにする。

参照資料