要約

  • RFC 9083では、RDAPオブジェクトにport43という文字列を含め、対象を見つけられる可能性のあるWHOISサーバーのホスト名またはIPを示せる。
  • これはサービスの場所を示す値であり、稼働状況、データの同等性、クライアントの自動切替を保証しない。

WHOISの前身であるNICNAMEは、ネットワーク上の人や組織を一行の問いで探す仕組みとして始まった。1982年のRFC 812はNICNAMEサービスを説明し、1985年のRFC 954はSRI-NICでの運用を記録する。クライアントが一行の検索を送り、サーバーは人が読めるテキストを返して接続を閉じる。検索構文は必要に応じて変わり、アスタリスクで組織やホストに属する利用者の一覧を求めることもできた。便利さの一方、その出力は安定した機械処理向けの形式ではなかった。RFC 812、RFC 954

RFC 3912はWHOISをTCPポート43上の単純な要求・応答プロトコルとして記述した。要求は一行で、サーバーが接続を閉じることで応答の終わりを示す。文字コード、国際化、強い認証の仕組みはプロトコル自体に定められていない。RFC 3912 軽量さと広い普及が利点だったが、サービスごとに異なる検索構文やテキスト出力を利用者側で扱う必要があった。

RDAPは別の運用モデルを採る。HTTPサービスとして問い合わせを行い、予測可能なパスとJSON応答を用いる。RFC 7480はHTTP転送と応答を、RFC 7481はアクセス制御、認証、完全性などのセキュリティ機能を扱う。RFC 9082は問い合わせ形式を、RFC 9083はJSON応答の構造を定義する。RFC 7480、RFC 7481、RFC 9082

RFC 9083の4.7節では、port43はWHOISサービスを表すJSON文字列である。値はホスト名またはIPアドレスで、その対象を当該サーバーでも見つけられる可能性を示す。WHOIS用のURIスキームが存在しないため、この値はURIではないと明記されている。RFC 9083 つまりWHOISをRDAPに包み込む仕組みでも、移行完了の証明でもない。構造化されたオブジェクトに旧照会面への手掛かりを残す設計である。

したがって、この項目から読み取れるのは「問い合わせ先になり得るサーバーの場所」までだ。エンドポイントが現在も稼働するか、WHOISとRDAPの記録が同等または同期しているか、クライアントが必ず参照をたどるかは示さない。RFC 9083は形式を定義しており、個々のレジストリの導入状況や実利用を報告していない。フィールドが標準にあることは互換性を選べるよう設計された証拠であり、運用実態は別途確認する必要がある。