要約

  • 単一結果の rdap-up と rdap-top では、RFC 9910 は関係検索 URL のほか、応答生成時に同じ結果を返した通常のルックアップ URL も許している。
  • リンクを開く前にレジストリ状態が変われば、後の応答は異なり得る。元の応答、関係の文脈、対象 URL、後日の参照を別々に残す必要がある。

ある調査記録には、下位ネットワークの RDAP 応答と受信時刻、それに上位ハンドルを指す rdap-up リンクが入っていた。担当者がリンクを開いたのは数時間後だった。返ってきた上位オブジェクトは下位と整合していたため、システムは二つを「当時の階層」として一枚の図にまとめた。

だが、下位応答を受け取った瞬間の上位応答は保存されていない。後の取得結果が立証できるのは、後の時点でサーバーが何を返したかだけである。最初の時点の表現も、二つの要求の間に変化がなかったことも復元できない。

これは特定のレジストリの事例ではなく、証拠設計を考えるための仮想例である。RFC 9910 が明記した時間の条件を、画面上の一本の線が隠してしまう問題だ。

同 RFC は IP ネットワークと AS 番号について、基本検索、関係検索、逆検索を追加する。rdap-up は対象を包含する直近の、より具体性の低いオブジェクトを探す。rdap-top は最上位の包含オブジェクトを探す。いずれも単一結果で、成功時は直接ルックアップと同じ形のオブジェクトを返し、結果がなければ HTTP 404 となる。

複数結果の rdap-down と rdap-bottom は別の意味を持つ。本稿では境界を示すためだけに触れ、bottom の集合を子孫一覧として読む問題や、ARIN の実測例は扱わない。焦点は一本の上向きリンクにどの時点の意味を与えられるかである。

サーバーは対応する関係検索 URL をリンクにできる。さらに、要求時点でその検索と同じ応答を返す別の URL も使える。単一結果なら、見つかったオブジェクトの通常のルックアップ URL で代替できる。

この選択は効率的である。クライアントは検索式ではなく、簡潔な正規対象へ進める。ただし同一性は応答を作った時点に限られる。RFC 9910 自身が、リンク解決前にデータベース状態が変われば、ルックアップ URL は検索 URL とは異なる結果に至り得ると注意している。

URL の文字列が変わらないことが、かえって誤解を招く。同じ href の背後で選択表現は変化できる。リンクが保存するのは対象への経路であり、対象内容の複製ではない。アドレスだけを残す運用は、参照を保って観測を失う。

RFC 9083 の RDAP リンクは value、rel、href、つまり文脈、関係、対象を持つ。RFC 8288 でも Web リンクは文脈資源と対象資源を結ぶ型付き関係である。関係型は将来取得されるすべての表現を固定しない。

権威サービスの発見も履歴保存ではない。RFC 9224 はアドレス、プレフィックス、ASN の範囲に対して、問い合わせ先となる権威 RDAP サービスを見つける。どこに問うかを定めるのであって、答えを不変にする仕組みではない。

したがって、データモデルに時点を組み込む必要がある。下位応答は一つの観測であり、直後に得た上位応答があれば二つ目、翌日の再取得は三つ目である。それぞれに生バイト、ハッシュ、要求 URL、受信時刻、HTTP 状態、Date、バリデータ、適合宣言、認証済みエンドポイントを持たせる。関連付けはしても上書きはしない。

RFC 9110 の Date はメッセージの生成時刻を表す。ETag や Last-Modified があれば、選択表現の比較や検証に使える。しかしレジストリ取引番号ではなく、変更理由も示さない。提供されない場合や、弱いバリデータの場合もある。

RFC 9111 が扱うキャッシュの鮮度と経過時間も、レジストリ履歴とは別である。新鮮な応答が新しい登録状態を反映することも、再利用可能な応答が調査対象の判断より古いこともある。「stale ではない」は「歴史的に同一」と同義ではない。

status フィルタは見える階層そのものを変える。RFC 9910 では、指定状態を持たないオブジェクトを除外したものとして関係を計算する。active を指定すると、近い包含オブジェクトを飛ばして上の層へ到達し得る。その rdap-up はフィルタ付きの関係であり、無条件の親宣言ではない。

対応状況も観測対象である。未対応の状態フィルタには HTTP 501 が返り得る。そもそも応答に関係リンクを含めることは任意だ。リンクがないからといって、明示的な検索も結果なしとは限らない。任意の表示を否定証拠へ変換してはならない。

収集手順は単純でよい。まず現在の応答をそのまま保存し、その後に文脈、関係語、対象、フィルタを欠落なく読む。直ちに対象へアクセスするなら、それは新しい観測として時間とハッシュで結ぶ。後日の確認は追記し、最初の行を最新値へ更新しない。

バリデータがあれば条件付き要求は有用で、304 はその選択表現について限定的な比較を支えられる。それでも未照会の検索 URL、異なるフィルタ、未保存の過去応答まで同じだったとはいえない。証拠の射程は、それを生んだ要求の範囲を越えてはならない。

この限定は制度上も重要である。RDAP 関係は、権威サービスが特定時刻と特定条件で公開した資源階層を示せる。単独では経路起源、RPKI 認可、アカウント支配、実利用、法的権利、変更理由を立証しない。

Heng Lu の Running-Code Primacy を当てはめれば、仕様は共通の問いを定義し、実際のサーバー状態と保存された応答が一回の答えを作る。Minimum Initial Specification が示すように、共有するのは必要最小限の関係語彙でよい。保存期間や警戒基準は、検証可能な現場判断として残す。

Reality Layers は、精密な記号的事実に別の現実層の権威を与えないための視点になる。Data Sovereignty も、公式記録を管理する力とネットワークを実際に動かす力を区別する。

RFC 9910 は階層をたどりやすくしたのであって、時間を止めたのではない。下位応答、最初の上位応答、後の参照を分けて保存すれば、リンクは複数の観測を正しく結べる。

出典