要約

  • IESG は 2026 年 8 月 17 日、draft-ietf-regext-ext-registry-epp-10 を Best Current Practice として発行することを承認した。EPP 拡張の登録、審査、保守は強化されるが、IANA の一覧が全サーバー共通の能力表になるわけではない。
  • Active は、少なくとも一組のレジストリ／レジストラまたはサーバー／クライアントで実装され利用中であることを示す。対象サーバーによる URI の提示、クライアント権限、個別トランザクションの成功は、それぞれ別の証拠で確かめる必要がある。

正しい台帳から誤った実行判断が生まれる

冒頭は仮想事例であり、実在するレジストリの障害を報じたものではない。焦点は、公開台帳の役割を越えて判断を自動化する危険にある。

IANA のレジストリが答えるのは調整上の問いだ。拡張の名称、安定した仕様、登録者、申告された TLD の範囲、知的財産情報、現在の状態、注記を一か所で確認できる。これにより実装の発見可能性が高まり、名前空間の衝突を減らせる。

一方、サーバーの greeting はその時点の運用状態を示す。対応するプロトコル版と言語、管理できるオブジェクト URI、任意の拡張 URI が並ぶ。login が成功すると、特定クライアントの本人性、権限、セッションで選択したサービスが定まる。コマンド結果はさらに狭く、そのオブジェクトと現在のローカル方針に対する可否を示す。

したがって、登録が正しくてもサーバーが拡張を提示しないことはある。提示していてもアカウントに権限がない場合がある。セッションで選択済みでも、正しい形式のコマンドが方針違反として拒まれることがある。

承認された文書が改善するもの

IESG が承認した “Extension Registry for the Extensible Provisioning Protocol” は、RFC Editor が発行するまでは Internet-Draft である。RFC 7451 を廃止し、文書の位置付けを Informational から BCP へ引き上げる予定だ。

審査手続も更新される。公開討議の場は旧 eppext リストから REGEXT へ移る。今後の申請では Internet-Draft を恒久的な仕様として使えず、RFC 7120 の早期割り当ても対象外となる。参照仕様は永続的で容易に取得できなければならず、他言語版があっても英語版へのリンクが必要だ。

登録方針は RFC 8126 の Specification Required を維持する。IANA が申請を Designated Experts に送り、専門家はアーキテクチャの健全性、安全性とプライバシーの記述を確認する。利害関係があれば審査から外れ、解決できない異議は公開コミュニティへ戻す。

XML の URI 管理も明確になった。スキーマ、スキーマ URI、名前空間 URI は構文と意味の両面で適切で、IETF XML Registry に登録されていなければならない。IETF 用の名前空間は IETF stream の文書に限られ、独自仕様や Independent Submission は別の適切な名前空間を使う。

これらは、公開記録から実装可能な仕様へたどれる確度を高める。しかし、個々の稼働サーバーを検査する制度ではない。

Active が証明する範囲

登録項目には名称、文書の状態、参照先、登録者、TLD、IPR、運用状態、注記が入る。RFC ではない仕様の文書状態には Other を用い、Informational RFC と同じ意味を装わない。

Active は実装され、現在使われている拡張を表す。Inactive は実装または利用がない場合を表し、参照仕様が入手不能になったときにも使える。この区別自体は有用だ。

ただし、証明の母集団は小さくてよい。少なくとも一組のレジストリとレジストラ、またはサーバーとクライアントで導入済みなら、専門家は登録に寛容であるべきだとされる。現実の導入を台帳に反映するための合理的な基準だが、普遍的対応を意味しない。

TLD 欄も同様である。特定の TLD は申告範囲、Any は一つの TLD に限定されないこと、N/A はドメイン名処理と無関係であることを表す。Any を「どこでも利用可能」と読む根拠はない。

運用システムが「登録済み」「Active」という二つの値だけを残せば、誰がどこでいつ使っていたかという証拠の境界が消える。公開台帳の正確さを保ったまま、実行判断だけが不正確になり得る。

重複を排除しないことには理由がある

EPP は小さな共通部分と拡張点を組み合わせる。レジストリごとに技術要件と事業規則が異なるためだ。その結果、似た課題に別々の拡張が作られる。RFC 7451 による一覧化は、その重なりを見つけやすくする役目も持っていた。

新手続でも、未導入の提案に類似する既存拡張があれば、専門家は再考を求める。しかし、他の要件を満たす限り、類似しているだけで拒否すべきではない。サーバーとクライアントの組み合わせで既に導入されているなら、その事実を尊重する。

これは台帳の現実性を守る判断で、互換性の認定ではない。価格、登録資格、国際化ドメイン名など同じ領域に見える拡張でも、データ構造や規則、結果は違い得る。クライアントは機能名ではなく、サーバーが提示した正確な URI と、その URI に結び付く仕様を照合しなければならない。

実運用の権限は greeting から始まる

RFC 5730 の greeting に含まれるサービスメニューは、対応する版と言語、管理対象オブジェクトの名前空間 URI、任意の拡張 URI を示す。同じ RFC は、クライアント別にオブジェクト管理権限を制限することも認める。

クライアントは greeting と一致する版と言語を login で選び、利用するオブジェクトと拡張の URI を指定する。成功すると、本人性と認可情報を保持したセッションが始まる。

それでも後続コマンドの成功は保証されない。結果コードは、ローカル方針による禁止、オブジェクト依存、サーバー方針上の意味エラー、未実装サービス、データ管理規則違反、一時的または終端的な障害を区別する。一つの「対応」フラグは、この制御情報を失わせる。

証拠は、登録された仕様、現在の登録状態、対象サーバーの最新 greeting、指定クライアントでの交渉成功、コマンド形式の受理、トランザクション成功、下流オブジェクト状態の確認、という順に積むべきだ。後段ほど主張は狭く、運用に近い。

現在の表示と履歴は別物である

新手続は登録、変更、非活性化、削除を定める。IETF consensus による登録を削除するには IESG Approval が必要だ。それ以外は、IESG の承認、または専門家との協議を伴う元登録者の依頼で削除・非活性化できる。責任者が消えた場合、専門家が連絡先を修正できる。

参照仕様が継続的に取得できなくなれば、回復するまで Inactive とする。こうした規則は現在の表示を健全に保つ。

ただし文書は、登録表に履歴機能がなく、削除後の項目を追跡できないことも明記する。依存する運用者は、観測時刻、仕様の写しまたはハッシュ、greeting、セッション選択、移行判断を自ら保存する必要がある。現在の台帳だけに依存すれば、導入根拠が消えてもソフトウェア上の依存は残る。

責任分界は明快だ。IANA と専門家は公開調整記録を維持する。サーバー運用者は提示能力とローカル方針を決める。レジストラはクライアントが何を選ぶかを管理する。それぞれが観測できない結論まで引き受けるべきではない。

出典