要約

  • REGEXT作業部会のRDAP拡張草案は、転送元サーバーが受け取ったパラメータをリダイレクト先URLへ無条件に写すことを禁じる。相手が処理でき、かつ値を受け取るにふさわしいと分かっている場合に限り渡せる。
  • 権威サーバーを探すために組織をまたぐ拡張機能は、クエリーパラメータだけに必要な意味を載せられない。宛先が既知の直接検索なら、その利用は認められる。

正しい住所に着いた、注文書は変わった

あるクライアントが番号資源の登録情報に追加の表示を求め、拡張用のパラメータを付けて問い合わせる。最初のサーバーは、別の機関が権威ある回答を持つと判断し、HTTPで転送先を示す。基本の登録情報は届くが、追加表示は出ない。これは確認された障害事例ではなく、草案が扱う設計上の場面である。行き先を示すことと、最初の問い合わせを丸ごと相手へ渡すことは別の行為だ。

RFC 9224は、IANAの割当情報を使って権威RDAPサービスを見つける方法を定める。ところがREGEXT草案によれば、この割当図はRIR間で後から移転した資源を反映しない。そこでリダイレクトが、実際に権威を持つRIRへ到達する重要な手段になる。パラメータの扱いは例外的な話ではない。住所を探す通常の道筋そのものに組み込まれている。

RFC 7480は、未知のクエリーパラメータをサーバーが無視するよう定める。拡張草案は転送URLを作る側へ、さらに厳しい条件を置く。元のパラメータを機械的にコピーしてはいけない。値には認証情報や追跡情報が含まれ、次のサーバーには無関係かもしれない。渡すには、相手が処理できると知っていること、値を受け取る適切な相手であると知っていることの両方が必要だ。読める能力と受け取る資格を一つのチェック欄にまとめてはいけない。

この線引きは、拡張機能を売る側には厄介だ。転送元が安全のためにパラメータを落としても、基本レコードの取得は成功し得る。画面に「成功」とだけ表示すれば、利用者は注文した追加表示が消えたことに気づきにくい。逆に追加表示を維持するため全て転送すれば、本来は最初のサーバーだけに渡した値を別の機関に明かしかねない。どちらの結果もHTTPの成功表示だけでは判別できない。

直接送る検索と、宛先を探す検索

草案はパラメータ一般を追放していない。クライアントが権威サーバーを最初から知り、そこへ直接問い合わせる場合には利用できる。例として挙げるのは検索だ。一方、権威サーバーの発見と組織間リダイレクトを前提にする拡張は、パラメータが必ず次へ届く設計にしてはならない。資源を理解するため不可欠な情報を、交差点で外され得るURLの末尾だけに載せるべきではない。

クライアントに転送応答を読ませ、自分で次の問い合わせを組み立てさせる案にも費用がある。草案は、ブラウザー型クライアントの一部が転送応答中のRDAP内容にアクセスできないこと、手動処理には転送ループ、パラメータの衝突、URL符号化への対応が要ることを挙げる。一台の既知サーバーで動いた機能を、権威探索の経路全体へ持ち出すには別の設計が要る。

IETFの文書記録では、改訂17の公開日は2026年10月27日。REGEXT作業部会の有効なInternet-Draftであり、IESGの状態は「I-D Exists」だ。まだRFCではない。パラメータの転送規則は今回の改訂以前から草案にある。ここで問うのは新しい一文の発見ではなく、現行の設計が誰に判断を割り当てているかだ。

特定の事業者で値が漏れた、または消えたと示す公開取引記録は見当たらない。元の要求、Location URL、相手の処理能力と受領方針が揃った実取引があれば、設計上の懸念を具体的な運用評価に変えられる。

出典