要約

  • 2026年9月13日公開の第03版は、引き続き個人の Internet-Draft。REGEXT 採択文書でも RFC でもない。
  • 登録申請の参照先を独立した固定仕様に変更した。データモデルや通信形式の変更はないと明記している。
  • 確認時点の IANA 一覧に reliabilityAssessment はない。文書に申請内容を掲載したことと、受付・審査・承認は別である。
  • 名前の意味を固定しても、標準化合意や実装導入、評価結果を使った措置の権限までは生まれない。

名前が指す文書を決める

拡張を実装する側には、その名前がどの仕様を指すのか分からなければ困る。しかし、その仕様を標準化共同体が支持するかどうかは別の問いだ。RDAP Extension for Structured Reliability Assessment Metadata 第03版は、この境界を公開文書の構成として示した。

提案は RDAP 応答にレジストラやドメイン名の評価を載せる。最新改訂で変わったのは、第13節にある reliabilityAssessment の登録参照である。データモデル、拡張識別子、JSON メンバー名、通信形式には変更がない。

第02版は RFC 公開後の登録を想定していた。第03版では、問題は安定した参照文書がなかったことだと説明し、別途公開した bcsec-RDAP-RA Version 1を根拠とする。安定性の条件を免除したのではなく、それを満たす文書を用意したという整理だ。

登録完了を報じられる段階ではない。本稿の確認時点で IANA の RDAP Extensions 一覧に該当項目はなく、正式申請が受け付けられた証拠も得ていない。Datatrackerの記録は、活動中の個人草案、状態は I-D Exists である。

RFC だけが仕様の公開経路ではない

現行の登録方針は Specification Required。RFC 8126は、指定専門家の審査・承認と、独立した相互運用実装を可能にする十分な記述を備えた、永続的で公開取得可能な仕様を求める。RFC は理想的な経路だが、RFC 以外の公開文書も明示的に認めている。

RFC 7480は RDAP の登録簿と申請テンプレートを定めた。並行する作業部会草案 RDAP Extensionsは、変更されない参照やレビューについてさらに具体的な指針を提案している。だが草案を、既存規則に代わる最終決定として扱うことはできない。

専門家審査は名前を押さえるだけの事務処理ではない。一方、登録条件に適合することも IETF の合意にはならない。独立仕様は REGEXT が採択しない自由を明記する。公開主体は Bertoldi Cybersecurity 単独であり、個人草案を通じて Simon Pietro Romano との共同技術設計を記している。

誤りを直すにも別の判断が要る

独立仕様は、編集上の訂正を含めて正本のバイト列を変更しないと約束する。誤りは規範的効力のない別の正誤表に載せる。相互運用性に影響する修正なら、異なる URL で新仕様を公開し、旧仕様も残す。ミラーも指定し、食い違いがあれば正本 URL を優先するという。

これは公開者の維持方針であり、将来の不変性を本稿が実証したわけではない。一度取得できた事実は、永続的な可用性を証明しない。それでも、誤りが判明することと、実装が従う文書を黙って書き換えることを区別できる点には意味がある。

付録 C はデータモデルが同じだとしたうえで、文書上の差を挙げる。未完成文書への参照を参考情報にするか、必要な相互運用規則を再記述した。レビュー募集や未解決事項の表現も削除・変更した。独立仕様は RDAP JSON Values の登録を別途申請せず、個人草案がその手続きを追う。技術的な整合性と、手続き上の交換可能性は同じではない。

将来 RFC になれば登録参照の更新を求めると登録者は記している。実現も更新もまだ確認されていない。その更新は、導入済み実装を自動で移行させるものでもない。共通形式は評価結果を運ぶが、採点手法や閾値、措置は選ばない。

出典