要約

  • IETFのEPP over HTTPS草案04版では、EPP処理層が応答を生成した場合、そのEPP結果が成功でも失敗でも外側のHTTPは200を返す。HTTP 200はレジストリ処理の成功判定ではない。
  • 有効なEPP応答が届かず、命令が処理層に到達した可能性を排除できない場合、結果は「失敗」ではなく未確定である。完全な命令と拡張の冪等性を理解するEoHクライアントだけが、条件付きで再試行を判断できる。
  • HTTPの試行、EPPトランザクション識別子、順序の停止、冪等性の根拠、担当者、最終照合を結ぶ「命令処分票」が必要になる。

運用画面では、緑色の200が仕事を終わらせる。アラートは閉じ、可用性の数字は戻り、次の処理へ進める。だが、EPPの命令をHTTPSで運ぶ場合、その緑色が示すのは外側の通信が成功クラスの応答を返したという事実にすぎない。ドメインなどのレジストリ・オブジェクトに何が起きたかは、内側のEPP応答を読まなければ分からない。

2026年9月3日公開のdraft-ietf-regext-epp-https-04は、この境界を明文化した。HTTP要求がEPP処理層に到達し、EPP応答が作られたなら、サーバーはEPPの成功・失敗にかかわらずHTTP 200で返す。つまり、200は「EPPの答えを運べた」という意味であり、「EPP命令が成功した」という意味ではない。

逆向きの推論も成り立たない。ゲートウェイ障害、過負荷、レート制限、非対応のメディア型などはHTTP層の結果である。命令がEPP処理まで届いた可能性があるのに、有効なEPP応答だけが得られなかったなら、外側の失敗から内側の不実行を証明することはできない。草案はこの状態をindeterminate、すなわち未確定とする。

未確定とは、曖昧な運用を認める言葉ではない。手元に権威あるEPP結果がなく、しかも処理済みの可能性を除けないという、証拠に即した結論である。ここで汎用的な再試行機能が「失敗したのだからもう一度」と判断すると、EPPの意味を知らない中間装置がレジストリ命令の再発行権を握ることになる。

Webらしい入口の奥に、順序を持つセッションがある

RFC 5730が定義するEPPは、共有中央リポジトリのオブジェクトを扱う、状態を持ったXMLプロトコルである。セッション管理、参照系の問い合わせ、作成・更新・更新期間の延長・移管・削除などの変換命令が、クライアント起点の要求応答として順番に進む。命令は原子的で、冪等にできるよう設計されている。これは、すべての実装と拡張の組み合わせが無条件に再送可能だという宣言ではない。

HTTPSへの写像では、最初に空のPOSTを送る。EPP greetingを含むHTTP 200が返り、CookieでHTTPセッションが確立して初めてEoH接続になる。その後、EPPのloginが成功して認証済みEPPセッションが始まる。以後は一つのPOSTに一つのEPPメッセージを入れ、処理後の一つのHTTP応答に一つのEPP応答を入れる。

443番ポートや一般的なロードバランサーを使えることは、クラウド環境で大きな利点になる。しかし、草案がこの方式をトンネルと表現する点を見落としてはいけない。HTTP基盤は運搬を担うのであって、EPPの状態機械を置き換えるのではない。キャッシュ、マルチプレクシング、認証、ログ、再試行といったWeb基盤の機能は、そのまま持ち込めない。

無効なセッション識別子の例は分かりやすい。空または無効なCookieを持つ命令でもEPP処理層まで届けば、サーバーはHTTP 200の中にEPP 2002、command use errorを入れて返す。外側と内側に似た数字が現れても、コード体系も権威も別物である。

「未確定」を失敗欄へ押し込まない

運用の集計は二値を好む。成功か失敗なら、SLAにも月次報告にも載せやすい。未確定の欄は、担当を残し、照合を続け、終了時刻を遅らせる。だが、欄をなくしても不確実性は消えない。見えなくなった不確実性を、後でレジストラ、登録者、サポート担当や監査人が引き受けるだけである。

未確定になった命令では、三つの抑制が必要だ。第一に、EPP成功応答か十分な照合証拠が得られるまで、オブジェクトの変更完了を約束しない。第二に、レジストリが返していない拒否を記録しない。第三に、前の命令の処分が開いたまま、後続命令を通して因果関係を複雑にしない。

後からオブジェクトを照会するのは有用だが、常に原因を確定するとは限らない。その状態が以前から存在した可能性、別の正当なクライアントが変更した可能性、処理が保留中である可能性がある。現在状態の証拠と、特定命令の処分証拠は同じではない。だからタイムアウトを瞬間的な通信エラーとして捨ててはいけない。

冪等性の審査対象は拡張を含むメッセージ全体

RFC 9110はPOSTを冪等メソッドに分類していない。非冪等メソッドを自動再試行するには、実際の要求意味が冪等だと分かるか、最初の要求が適用されなかったと検出できる必要がある。プロキシは非冪等要求を自動的に繰り返してはならない。

04版はEPP向けに条件を絞る。EoHクライアントが再試行できるのは、障害が一時的かもしれず、受信したHTTP状態の意味が再試行と矛盾せず、さらに拡張を含む完全なEPP命令がアプリケーション上で冪等だとクライアントが知っている場合だけである。再試行では同じ命令を使い、元にclTRIDがあれば同じ値を入れる。有効な応答を得るかEPPセッションを放棄するまで、次の命令を送ってはならない。

「拡張を含む」という条件は重い。基本命令の名前だけを見て安全と分類しても、拡張が条件、時刻、追加効果や別オブジェクトとの関係を持ち込むかもしれない。判断記録には、実際のXML全体、拡張の版、サービス側の約束と、その時点で有効だった根拠が必要だ。

プロキシやロードバランサーには、普通その判断材料がない。通信の切断点やバックエンドの応答時間は知っていても、EPP拡張の意味、対象オブジェクト、セッション内の次命令までは所有しない。このため草案は、管理下のHTTP中間装置がEPP POSTを自動再試行しないよう運用者に求める。可用性機能という名前だけで、業務上の再命令権を与えてはならない。

同じclTRIDは追跡の軸であり、万能の重複防止鍵ではない

RFC 5730では、クライアントが任意のclTRIDを付け、自らの識別子空間で一意性を管理する。サーバー応答はその値と、サーバーが割り当てる一意なsvTRIDを組み合わせる。両者は命令と応答の同期完全性を支えるため、記録、保持、保護が推奨されている。

許可された再試行で同じclTRIDを使うのは、複数のHTTP試行を一つの意図に結び付けるうえで不可欠だ。しかし、参照した仕様は、同じclTRIDなら全サーバーが二度目の実行を必ず抑止するとは述べていない。実装や二者間サービス契約が強い重複排除保証を持つなら、その適用範囲、版、拡張への扱いを証拠として残すべきである。

相関、冪等性、重複排除は別の問いだ。相関は「どのメッセージが同じ案件か」を示す。冪等性は「複数回の実行が同じ意図された効果になるか」を示す。重複排除は「サーバーが追加実行を実際に止めるか」を示す。一つの識別子を三つの答えにしてはいけない。

待つことは、因果関係を保存する制御である

HTTP/2とHTTP/3は同時に複数のストリームを運べる。だがEoHは、同じEPPセッションで未完了のHTTP要求を二つ以上持つことを禁じる。中間装置が並行要求を作ってしまう場合、サーバーは失敗させるか直列化するかを定義しなければならない。

これは単なる性能制約ではない。更新は作成の成功を前提にするかもしれず、移管は次の更新を出せる主体を変えるかもしれない。最初の命令が未確定のまま次が進むと、最終状態を説明する実行順序が複数できる。一つの未解決事項が、枝分かれした推測問題へ変わる。

セッション放棄は、その枝を増やさないための停止措置である。既に出した命令の処分を決めるものではない。サーバー側トランザクション記録、回収された応答、範囲を限定したオブジェクト照会、運用者間確認など、合意済みの方法で別途照合する必要がある。新しいセッションは通信を再開するが、古い未確定を消去しない。

二層をつなぐ命令処分票

一般的なHTTPログは、URL、応答元、状態、遅延、再試行回数を中心に作られる。EPPログは命令XML、結果コード、トランザクション識別子を中心に作られる。トンネル方式で必要なのは、どちらか一方を増やすことではなく、両方を同じ案件として結ぶことである。

クライアントからEPP命令が出るたびに、少なくとも次の項目を持つ処分票を作るべきだ。

  1. 命令種別、対象オブジェクト、全拡張を含むEPPメッセージの正規化指紋。
  2. EPPセッション、clTRID、各HTTP試行の識別子。
  3. 送信開始時刻と、「未到達」を最後に証明できた境界。
  4. HTTPの観測結果、実際にその応答を生成した中間装置またはサーバー。
  5. 有効なEPP応答がある場合の結果コードとsvTRID。ない場合は欠落を明記する。
  6. 確定成功、確定失敗、未確定の三値処分。
  7. 完全な命令を冪等とした根拠、版、拡張の範囲。
  8. 未確定中に後続命令を止めた順序バリア。
  9. 再試行、セッション放棄、照合を承認した担当者またはクライアント方針。
  10. 案件を閉じた証拠、時刻、確信度、クライアントとレジストリの残存差分。

世界共通のチケット製品を要求する必要はない。Lu Hengの最小初期仕様という考え方に沿えば、共通化すべきなのは責任を保つ最小の区別と識別子であり、保存方式や照合手順は各組織に委ねられる。署名イベント、二者間のケース、保護されたログ結合のいずれでもよい。「まだ分からない」を統計上の都合で「失敗」に変えないことが要件である。

The Policy Mirrorは、設定の背後にある権力を映す。誰が命令を繰り返す権限を得るのか。最初の命令が既に実行済みなら、誰が損失と復旧費用を負うのか。誰が証拠を見て異議を述べられるのか。基盤側が可用性指標の利益を得て、レジストラや登録者へ照合コストを移すなら、その自動再試行は既にリスク配分の政策である。

草案の権威も、処理結果と同じ精度で扱う

04版はREGEXT作業部会の活発なInternet-Draftで、Standards Trackを意図している。RFCではなく、IESG審査も完了しておらず、2027年3月7日に失効する。2026年9月の出版申請というマイルストーンは目標であり、申請や承認の完了を示さない。

実装状況にはVerisign EPP SDKとIIT-CNR/Registro.itの実装が記載される。ただしRFC 7942に基づく注意書きは、寄稿者提供の情報をIETFが検証していないこと、推薦を意味しないこと、製品一覧ではないことを明記する。実装経験が報告された証拠にはなるが、すべての本番環境で中間装置の再試行が止められ、全拡張の冪等性が確認済みだという証明にはならない。

IANAのEPP拡張レジストリについても、草案は登録内容を提案している段階である。提案文を既存の有効な登録項目として扱ってはならない。HTTPとEPPを区別する厳密さは、仕様の現状を説明するときにも必要だ。

出典

  1. IETF Internet-Draft — EPP Transport over HTTPS 04版
  2. IETF Datatracker — 文書の状態
  3. IETF Datatracker — 更新履歴
  4. IETF REGEXT作業部会
  5. RFC 5730 — Extensible Provisioning Protocol
  6. RFC 5731 — EPP Domain Name Mapping
  7. RFC 5734 — EPP Transport over TCP
  8. RFC 9110 — HTTP Semantics
  9. RFC 7942 — Improving Awareness of Running Code
  10. IANA — Extensions for EPP
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng — The Policy Mirror