要約

  • RFC 9517 は正式な URN 名前空間 ddi を登録し、承認済み機関、機関内の資源、明示的な版の三要素で名前を作る。
  • 解決では機関名を ddi.urn.arpa 配下へ変換し、DNS/DDDS と NAPTR の委任を追い、サービスを選んで元の URN を送る。
  • 正しい名前は、実際の割当、サービスの稼働、保管者の権限、オブジェクトの完全性、長期保存を証明しない。それぞれ別の記録が要る。

「永続識別子あり」という項目だけが緑だった。構文は正しく、名前空間も登録済みだった。しかし一つ目のサービスは応答せず、二つ目は古い版のメタデータしか返さなかった。名前は壊れていない。名前の背後にある運用と、緑色が表す範囲の定義が壊れていた。

RFC 9517 は2024年1月、Independent Stream の Informational RFC として公開された。Data Documentation Initiative の標準に従う資源のため、ddi を正式登録する。IETF Standards Track の標準でも、IETF コミュニティの合意でもない。実務上の核心は、識別・発見・提供・保存の権限が同じ主体にないことを明確にした点にある。

文法は割当記録ではない

形は urn:ddi:<機関>:<資源>:<版> である。機関識別子は逆ドメイン名の考え方を使い、DDI Alliance が承認する。その機関が自分の範囲で資源と版、必要なら下位機関を割り当てる。

一意性は二段の責任でできる。Alliance は機関どうしの衝突を防ぎ、各機関は内部の衝突を防ぐ。パーサーが確認できるのは文字と区切りだけだ。RFC 8141 が示すように、urn: から始まる整った文字列でも、自動的に割当済み URN にはならない。登録 NID と、定められた管理手続の両方が必要である。

比較規則も一様ではない。urn、ddi、機関部分は大文字小文字を区別しない。資源と版は区別する。全体を小文字化すれば別の資源を統合しかねず、機関部分の大小を区別すれば同じ権限を重複登録する。原文、分解結果、正規化手順を記録しなければならない。

区切り文字は保存装置ではない

RFC 9517 は、識別子の永続性を機関レベルの適切な解決委任と機関割当の継続に結び付ける。参照される資源の保存は機関の責任である。論文中の URN が残っても、DNS、カタログ、ファイル、利用許可は消えうる。

版識別子も証明書ではない。機関の規則で改訂を区別するが、リポジトリがその版を返したこと、複数拠点のバイト列が一致すること、今も権威ある版であることは別問題だ。返却識別子、ハッシュ、来歴、保存記録を照合する必要がある。

下位機関への委任は柔軟だが、責任の境界を増やす。親機関が登録済みでも、下位機関の運営者やサーバーが変わっている場合がある。監査記録は DDI という一語ではなく、完全な権限経路を残すべきだ。

解決は複数の引き渡しである

クライアントは機関部分を取り出し、大小を正規化し、点区切りの順番を逆転して .ddi.urn.arpa を付ける。DNS が DDDS データベースになる。問い合わせは urn.arpa、DDI Alliance、対象機関の名前サーバーへと委任される。

NAPTR は利用可能なサービスを示す。終端 u は URI を返せる。s は SRV 問い合わせへ進ませる。クライアントは用途に合うサービスを選び、元の URN を送る。ここで得られるのは接続情報であり、資源そのものでも、サービスが稼働中で正当だという証拠でもない。

記録すべきなのは、リゾルバー、時刻、TTL、キャッシュ年齢、検証状態、NAPTR の順序・優先度・フラグ・サービス・置換、SRV 結果、選択理由、TLS 身元、最終応答である。「解決した」だけでは、誰がどの権限で答えたか分からない。

資源、説明、所在地を同じ成功にしない

I2R は資源の実体、I2C は特徴や要約、I2L は一つの所在地、I2Ls は複数の所在地を返しうる。詳細なサービスタグは将来の定義に残されている。

説明が正しくても実体が失われていることはある。URL が生きていても別の版を指すことがある。複数の所在地が異なる内容を返すこともある。I2R のバイト列さえ、期待した保管者と保存記録への照合なしでは権威を持たない。

全てを found=true に変換すると、応答の種類が消える。リポジトリ停止時に、取得できたという理由だけで I2C のメタデータを I2R の証拠物として扱う危険も生まれる。

DoH は研究資料を署名しない

文書は公開情報を対象とするため安全性の輪郭を低いとする一方、DNS 解決の安全性は一般の DNS と同程度だと述べる。DoH はクライアントから選択したリゾルバーまでの盗聴や改変を抑えられる。

しかし DoH は機関、サービス、最終オブジェクトを認証しない。DNSSEC、暗号化された問い合わせ、サービス TLS、機関の委任、オブジェクト署名やハッシュは別々の事実である。

名前空間登録、構文、機関承認、資源割当、DNS 委任、サービス種別、終端認証、正確な版への応答結合、オブジェクト検証、利用判断という順に証拠を積む。永続名はこの問いを安定させるが、上位の結論を代行しない。

出典