Summary

  • 2026年11月2日のRPP core草案・第01版は、ドメイン名など共有データベースの対象を操作する方法をHTTPへ対応付ける。データオブジェクト草案が対象モデルを別に定める。現在はIETF作業草案だ。
  • ドメイン移管はスポンサーとなるクライアントの変更だが、RPPでは独立したライフサイクルを持つ手続きとして扱う。申請側はPOST /domainNames/{name}/processes/transferProcessesを送り、例では201 Createdと手続きのURLが返る。
  • 申請者は保留中の移管を取り消せる。現在のスポンサーは却下または承認できる。持続するメッセージキューは後の非同期結果を知らせ、取得と確認は別の操作になる。

ドメインを「別のレジストラへ移す」と言うと、一つの動作に聞こえる。IETFのRPP core記録が示す提案は、その間にいくつもの区切りを置く。申請から判断へ進み、必要なら完了の知らせが届く。最初のCreatedは、草案の例では移管手続きのための資源を作ったという意味だ。ドメインのスポンサー欄が既に書き換わったという証明ではない。

RPPはEPPの別名ではなく独立したプロトコルとして設計され、EPPバックエンドへの橋渡しは別に扱う。core草案はURL、HTTPメソッド、ヘッダー、結果コードを定め、対象のデータモデルや具体的な表現形式は別文書に分ける。運用ログを見る側は、成功したHTTP操作が何を進めたのかを見極めなければならない。

できたのは移管の作業票

第16.9.5節は移管をスポンサーとなるクライアントの変更と定義し、その作業に独立したライフサイクルを与える。移管を求める側はドメイン配下のtransferProcessesへPOSTする。例の応答は201 CreatedとRPP結果コード、さらに/transferProcesses/latestで終わるLocationだ。この場所は最近の移管手続きをたどる入口になる。ドメインの最終的なスポンサーを読み取った結果とは異なる。

クライアントはGETで手続きの状態を調べられる。保留中なら申請者がDELETEで取り消せる。現在のスポンサーにはtransferRejectとtransferApproveが用意される。それぞれの操作に別の権限が載る。新しいレジストラは申請を始められても、現在のレジストラの承認を自分の画面上で作り出すことはできない。申請、状態、判断、最後のドメイン記録をつないで初めて移管の経緯が分かる。

URLの存続も条件付きだ。サーバーが手続きのインスタンスを公開するなら、最新のものをlatestで参照できなければならず、永続的なIDを付けてもよい。永続的な手続き資源を公開しないなら、草案は201 Createdではなく200 OKを要求する。すべてのレジストリで長く残る作業票URLを期待するのは誤りだ。それでも取引識別子、参照可能な状態、最終的なスポンサーの読み取りは、連続した証拠として残せる。

通知を開いただけでは受領済みにならない

草案はクライアント向けの非同期メッセージを持続的なキューに置く。別の当事者の承認を要する移管の完了が、その用途の一例だ。クライアントはGETでメッセージを取り出し、特定の一通へDELETEを送って確認する。取り出しただけの通知は、明示的な確認までキューに残る。「目に入った」と「処理した」を一つにしない設計である。初期の移管申請応答と完了通知も別々の記録になる。

通常の操作に伴って手続きが生じた場合、第15節はrel="rpp-process"を持つLink応答ヘッダーで知らせる。processは種類を示し、永続IDが割り当てられればprocessIdも載る。latestはその種類の最新の手続きを指す。次に追うべき作業を示すリンクであり、その作業の結末を示す印ではない。

公式資料には、実際のレジストリで完了した移管の計測記録はない。管理下のドメインで試すなら、POST応答、手続きのGET結果、現行スポンサーの判断、キューの完了通知、その確認、最後のドメインのスポンサー欄を同じ時系列に並べる。顧客画面で「申請済み」を「移管完了」に替えられるのは、その最後の状態が確認された時だ。移管のURLができても、ドメインはまだ元の窓口にいるかもしれない。

RPP core第01版 · Datatracker記録 · RPPデータオブジェクト · RFC 5730