要約

  • RFC 7451を置き換える予定の現行草案は、少なくとも一組のレジストリ／レジストラ、またはサーバー／クライアントがEPP拡張を実装・配備していれば、指定専門家は許容的に審査すべきだとしている。同じ、あるいは似た機能の拡張が複数登録されることも明記する。
  • 登録によって分かるのは、永続的な仕様、識別子、申請者と審査経路である。設計上の優勝、Standards Trackとしての承認、広範な普及、個別環境での相互運用性までは証明しない。
  • IANAの現行表にはすでに共存の実例がある。COREとTANGOのIDN拡張およびプライバシー拡張は、構文上・機能上は同一だがXML名前空間が異なると注記されている。この差を消さずに判断材料へ変える「共存マップ」が必要だ。

レジストリの一行は、仕様書そのものより強い印象を与えることがある。名称、参照先、Activeという表示が並ぶと、IANAがその拡張を選び、品質を保証し、業界標準として認めたように見える。似た行が二つあれば、どちらが本物かを決めたくなる。

しかしEPP Extension Registryは審査員席ではなく、共有座標系である。EPPは基礎となるコマンドやオブジェクト写像を拡張できる。レジストリ、レジストラ、ソフトウェア事業者は、それぞれの運用関係の中で必要な機能を作る。公開レジストリは名前の衝突を避け、後から仕様をたどれるようにするが、既に存在する複数の系譜を一つに統合する権限までは持たない。

2026年8月17日付のdraft-ietf-regext-ext-registry-epp-10は、この役割を明確にした。同一または類似の機能を持つ拡張は複数登録できる。他の条件を満たす申請を、似ているという理由だけで退けるべきではない。さらに、少なくとも一組のレジストリ／レジストラまたはサーバー／クライアントが実装し、配備した拡張については、専門家に許容的な判断を求める。

ここで確認されるのは実在であって、優位ではない。

一組の接続が示す範囲

EPPは相手のあるプロトコルだ。サーバーだけが実装してもクライアントが理解できなければ処理は成立せず、その逆も同じである。動作する一組を最低条件とすることで、紙上の提案と実際の対話を区別できる。共有名前空間に痕跡を残す基準として合理的だ。

ただし、一組から市場全体を推定することはできない。全レジストラの対応、対象TLDの利用率、取引量、障害率、複数ベンダー間の互換性は別の証拠を要する。同じクライアントでも接続先レジストリごとにバージョンや任意項目の扱いが違うかもしれない。

Activeという状態も採用率ではない。草案では、実装され使用中ならActive、実装・使用されていない、または仕様を入手できない場合はInactiveとなる。Activeは「どこかで生きている」と読めても、「どこでも使える」とは読めない。

TLD欄も対応表の代わりにはならない。そこに名前があっても、どのサーバー版が提供し、どのクライアント版が受け取り、必須か任意か、名前空間を変換する装置があるかは分からない。レジストリが示すのは入口であり、通行可能性は運用側が確かめる必要がある。

仕様必須という制度の意味

RFC 8126の「Specification Required」は、永続的で公開取得可能な仕様と、指定専門家による審査を求める。現行草案はRFCのほか、継続して容易に入手できる独自仕様も認めるが、英語版を必要とする。通常のInternet-Draftは将来の登録に使う恒久仕様とはみなされず、RFC 7120の早期割当も適用されない。

この条件が守るのは、識別子の意味を将来も説明できることだ。レジストリには名称、文書状態、参照、登録者、対象TLD、知的財産情報、Active／Inactive、注記が並ぶ。ログに未知のXML名前空間が残ったとき、実装者が元の意図へ戻れるための索引になる。

専門家は書式だけを見るのではない。アーキテクチャの妥当性、プライバシーの記述、URIの構文と意味、IETFまたは非IETFのXML名前空間の正しい利用を審査する。通常は主担当の専門家が扱い、不在時は代替専門家の集団が単純多数の合意で決める。利益相反を自覚した専門家は辞退し、必要ならREGEXTメーリングリストで公開議論を行う。

それでも、この審査は比較選考ではない。どの事業者の設計が最も洗練されているか、最も売れているかを決める手続ではない。登録は「この名前が何を指すか」を安定させる制度であり、「誰もが採用すべき名前」を選ぶ制度ではない。

しかも、この手続を更新する文書自体はまだRFCではない。第10版は有効なInternet-Draftで、Best Current Practiceを目指し、IESGへ提出済みでRFC Editorの編集者割当待ちにある。承認・刊行されればRFC 7451を廃止する予定だ。現在地を省いて確定規範のように扱えば、制度が管理しようとしている文書状態の違いを自ら消してしまう。

COREとTANGOは「同じ」と「違う」を同時に示す

2026年9月4日に更新されたIANAの現行EPP Extension Registryには、Standards TrackとOther、ActiveとInactiveが同じ表に存在する。特にCOREとTANGOに関する注記は、機能の重複を具体的に示している。

IDN拡張について、COREのものは対応するTANGO拡張と構文上・機能上同一だが、異なるXML名前空間を使うと記載される。プライバシー拡張にも同様の注記がある。

この「同一」は、名前空間まで一つになるという意味ではない。XML名前空間は通信上の識別子であり、クライアントが一方の要素を送っても、他方だけを実装したサーバーが自動的に理解するわけではない。現時点のスキーマが似ていても、配備範囲、試験項目、更新主体、将来版の進み方は分岐し得る。

注記は強い関係証拠だが、すべてのコマンド、任意項目、エラー経路、将来の改訂まで交換可能だとは述べていない。二つの系譜ができた理由も一行からは分からない。先行実装、別々の運用共同体、契約、変更管理、移行費用などがあり得る。

一方を消して表をきれいにしても、古いソフトウェアや取引記録から名前空間は消えない。むしろ参照先を失う。二行の共存は混乱ではなく、過去から将来へ安全に渡るための手掛かりになり得る。

共存マップは四つの主張を分離する

IANA表は登録事実の基準であり続けるべきだ。ただし採用や移行を決める人には、別の表示が要る。ここでは著者の分析道具として「共存マップ」を提案する。IETFやIANAの正式要件ではない。

最初に、IDN、プライバシー、ローンチ、料金など持続的な機能クラスで拡張を束ねる。ただしXML名前空間は統合せず、仕様版、対象コマンド、応答面とともに表示する。次に、恒久参照、文書状態、登録者、審査日、公開議論や代替専門家の利用といった登録経路を置く。

配備証拠は独立欄にする。どのサーバー／クライアント、ソフトウェア版、TLD、日付で実証されたか。証拠が一組なら一組と書く。業界採用という表現へ膨らませない。

重複関係にも出典が必要だ。IANA注記なのか、登録者の説明なのか、スキーマ比較なのか、相互運用試験なのか。本番観測なのか。「機能同一」がどこまでを含むか、任意項目やエラーまで確認したかも記す。

さらに現在のサーバー／クライアント対応と、名前空間間の変換を示す。変換があれば責任主体と情報損失、なければその事実を残す。最後に、状態・参照・注記の時系列を保存する。

この構造なら、「登録済み」「どこかで配備済み」「当環境で対応」「別拡張と置換可能」という四つの命題を混同せずに済む。平面の一行が直接証明するのは最初だけである。

削除が証拠を失わせるとき

草案は登録、変更、非アクティブ化、削除の手順を分け、状態変更に理由を求める。IETF合意による項目の削除にはIESG承認が必要で、非IETF項目はIESG、または元の登録者と専門家によって削除・非アクティブ化できる。

一方、レジストリ自体には履歴機能がなく、削除された項目は後から追跡できないと草案は認める。この制約によって、整理は証拠管理の問題になる。

Inactiveは新規利用を控える信号を出しつつ、古い記録を読む座標を残す。削除は現在の表から座標をなくす。仕様まで入手不能になれば、将来の調査者は正当な旧拡張と私的な独自要素を区別できないかもしれない。

現在のレジストリは現在を調整する。日付付きスナップショットは過去を説明する。両方がなければ、今日の整頓は明日の障害解析を難しくする。

出典