要約

  • RDAP Extensions 第15版は、登録済み連絡先が自らの拡張を、IESGが任意の登録を廃止扱いにするようIANAへ要請できる日付欄を提案する。変わるのは登録状態であり、配備済みコードではない。
  • バージョニング草案第07版は、/help で開始・終了・既定値・前身・後継を示し、応答ごとの版を明示し、クライアントにも版の希望を表明させる。これは移行を調整するが、未知の全クライアントを列挙しない。
  • 登録上の権限、各サーバーの宣言と実測、観測された旧版需要、なお見えない依存を分けた退役レシートが必要だ。これはDaniel Kadeの提案であり、IETFの要求ではない。

ソフトウェアの廃止は、管理表では一瞬で終わる。現場では、忘れられたスクリプトが一年後に動き、以前のJSON名を探して停止する。どちらの記録も嘘ではない。管理表は名前の現在地を示し、故障は利用の現在地を示しているからだ。

2026年8月13日付の draft-ietf-regext-rdap-extensions-15 は、RDAPを複数の権威が運営する連鎖として描く。ブートストラップ、リダイレクト、参照を経て、クライアントはTLD、レジストラ、RIRなどのサーバーへ進む。一つの運用者が全経路の実装を把握する前提はない。

同文書はREGEXT作業部会のInternet-Draftで、Standards Trackを意図するがRFCではない。Datatracker上では作業部会から問題が示され、改訂が必要で、担当Area Directorもいない。7月31日付のバージョニング第07版も作業中の草案であり、実装義務を証明しない。

IANA登録が支配する範囲

RDAP拡張識別子は rdapConformance に現れ、JSON名やパス、パラメータの名前空間にもなる。識別子は不透明で、末尾の数字だけから版の系譜を読めない。後継関係は仕様が明示しなければ存在を証明できない。

第15版はIANAのRDAP Extensions登録に Deprecation Date を加える。登録連絡先は自分の拡張について要請でき、IESGは任意の拡張について要請できる。IANAがRFC 3339のfull-date形式で記録する。誰が要請し、誰が記録するかは明確だ。

ただし、その権限は名前の公的状態に限られる。IANAの行がサーバーの互換機能を消すわけではなく、クライアントのライブラリを更新するわけでもない。廃止は方向を示すが、配備完了の証明ではない。

草案は、既に OBSOLETED と表示される icann_rdap_response_profile_0 と icann_rdap_technical_implementation_guide_0 に2025年8月21日を記すよう求める。2026年9月1日更新の現行登録には両識別子と版1の後継があるが、独立した日付欄はまだない。草案段階の命令を用いてIANAの不履行を主張することはできない。

Specification RequiredとExpert Reviewも別の役割を持つ。安定し、取得可能で、独立実装が相互運用できるほど詳しい仕様を求める。第15版は最低三名の専門家と、担当外の専門家による再確認を提案する。これは共有語彙への入場審査であって、利用者名簿ではない。

サーバーは自分の時計だけを公表できる

第07版の versioning_help は、サーバーが扱う版、既定値、文書、前身・後継、start と end を /help に載せる。versioning_data は個別応答に使われた版を示す。versioning_list はクライアントの希望を伝える。

能力、実行結果、希望は別物だ。旧版を支援していても新しい版を既定にできる。新しい応答を一度返しても旧版の削除は証明されない。希望を送らないクライアントは既定値に従っただけで、新版を理解しているとは限らない。

end は支援を終えるサーバー側の予定である。時刻を過ぎれば版オブジェクトを削除し、最後の版なら拡張オブジェクトも外す。end がなければ終了予定はない。この規則はサーバーの表示を精密にするが、外部クライアントの準備を保証しない。

破壊的変更には中間段階が推奨される。旧要素と代替要素を併存させ、関係を説明し、移行後に旧要素を外す。既定版を先に変え、終了までは旧版指定を受ける方式もある。問題は期間である。毎日使う管理クライアントと年一回の監査ツールに、同じ「十分」は通用しない。

第15版は限界を明記する。RDAPクライアントとサーバーの間に関係がないため、破壊的変更が全クライアントに無影響だと絶対に判断する方法はない。これは永久互換を命じる文ではない。見えない利用者を口実に旧仕様を永続させれば、複雑性と意味の衝突も固定される。

観測と監視を混同しない

旧版を明示要求した回数、既定値変更後のエラー、参照先ごとの差、管理下クライアントの更新確認は判断材料になる。しかし、観測されなかった季節業務や、希望を送らず既定値を受けるライブラリまでは数えられない。

移行確認の名目で検索対象、IPアドレス、ソフトウェア指紋を長期間結び付ければ、互換性調査が利用者監視へ変質する。公開値は期間と対象を限定した集計でよい。「この期間、このサーバー群で旧版要求を観測しなかった」は事実になり得る。「依存するクライアントは存在しない」はならない。

退役レシートの構造

第一欄には識別子、版、適格な要請者、IANAの記録日と表示状態を置く。第二欄には前身、後継、互換性、削除される要素、安定仕様を置く。数字の見た目ではなく文書で関係を証明する。

第三欄はサーバー群ごとに、/help の日時付き観測、既定値変更、開始・終了、応答中の versioning_data、旧版要求へのエラー、ロールバック条件、実際の削除を記す。予定と実績を同じ欄に上書きしない。

第四欄には測定期間、対象ノード、集計方法、旧版需要、連絡済みの管理クライアント、未解決の重大依存、プライバシー上の欠落を置く。最後に運用者自身の削除判断と証拠の締切を記す。

この記録なら、IANAは名前の状態に、サーバー運用者は提供する機能に、クライアント管理者は更新に責任を持つ。三者は協調できるが、誰も全経路の代理人を名乗らない。

情報源