摘要

  • 拟取代 RFC 7451 的最新草案要求指定专家在扩展已由至少一组注册局/注册商或服务器/客户端实施并部署时采取宽松态度；草案也明确允许功能相同或相近的多个 EPP 扩展登记，不能只因相似就拒绝合格申请。
  • 登记证明的是：这个标识有可持续取得的规范、有可追溯的申请者，也经过了规定的专家审查。它并不选定最佳设计，不赋予 Standards Track 地位，不证明行业普及，更不保证两个实现可以在某一生产环境中互换。
  • IANA 现行注册表已经展示这种共存：备注称 CORE 的 IDN 与隐私扩展在语法和功能上分别与 TANGO 对应扩展相同，但使用不同 XML 命名空间。运营者需要的是保留这些差异的“共存图”，而不是从表格中臆造冠军。

官方注册表常被读成排行榜。一个扩展有名称、引用文件和“Active”状态，看起来就像通过了权威认证；若另一行解决同一类问题，读者便自然追问：哪一个才是标准答案？

但 EPP 扩展注册表承担的不是评奖任务。EPP 的基础协议允许注册局、注册商及软件供应商围绕实际业务继续扩展。不同参与者可能在不同时间、不同关系中形成各自的 XML 设计。IANA 把这些标识放进公共目录，是为了让实现者能找到规范、避免未登记字符串互相碰撞，并为后续变更保留责任人。它没有得到授权替行业作出采购决定。

2026 年 8 月 17 日发布的 draft-ietf-regext-ext-registry-epp-10 把这一边界写得很清楚。即使已经有功能相同或相似的扩展，新的合格申请仍然可以登记；相似本身不应成为拒绝理由。只要至少一组注册局和注册商——或更一般地说，一组服务器和客户端——已经实施并部署，专家就应倾向于放行。

这个门槛排除了纯粹占位，却没有进行市场投票。

一组对端只能证明“已经发生”

EPP 是双边协议。服务器独自支持而没有客户端使用，或者客户端准备好了但没有服务器回应，都不足以构成完整操作。以一组已经工作的服务器/客户端为最低证据，能够证明规范不只停留在纸面，也确实穿过了协议两端的接缝。

然而，一组对端无法证明普遍采用。它不说明多少注册商能连接该注册局，不说明哪些 TLD 启用了该功能，也不说明交易量、失败率或软件覆盖。它更不能保证另一个注册局对相同可选字段、错误码和版本升级作出一致解释。

“Active”也只能按注册表自己的定义理解：扩展已实施并正在使用。“Inactive”表示没有实施或使用，或者规范已经无法取得。这是生命周期标识，不是市场份额。把 Active 翻译成“行业支持”，等于给注册表添加了一个它没有采集过的统计结论。

TLD 列表能缩小声称的范围，却仍不是兼容性矩阵。运营团队还需要知道具体服务器版本、客户端版本、功能是否必选、网关是否转换命名空间、哪些字段会在转换中丢失。登记给出坐标；部署材料才说明这条路能走多远。

“Specification Required”保障可解释性

RFC 8126 所说的 “Specification Required” 要求登记请求附带永久、公开可取得的规范，并接受指定专家审查。新草案允许引用 RFC，也允许真正长期可得的专有规范，但必须有英文版本。普通 Internet-Draft 不能作为未来登记的永久规范；RFC 7120 的早期分配机制也不能替代这条路径。

这些条件不是为了把注册表变成标准认证清单，而是防止公共命名空间堆满无人能解释的字符串。多年以后，开发者在日志里看到一个 XML 命名空间时，应当仍能查到它原来要表达什么。因此，注册表记录名称、文件状态、引用、登记人、适用 TLD、知识产权信息、Active/Inactive 状态与备注。

专家审查并非走过场。草案要求检查架构是否合理、隐私影响是否得到说明、URI 的语法和语义是否稳妥，以及 IETF 或非 IETF XML 命名空间是否使用正确。通常由一名主要指定专家处理；若其无法履职，后备专家组以简单多数共识作出决定。专家认为自己存在利益冲突时必须回避，疑难申请还可在 REGEXT 邮件列表公开讨论。

这套程序能够产生可问责的准入决定，却不能产生优胜者。专家可认定某个扩展资料完整、设计足以进入共享目录，也可因隐私或命名空间问题要求修改；他们没有义务比较供应商份额、部署规模或商业优势。登记回答“这个标识指向什么”，不回答“所有人今后应当采用什么”。

规则本身目前也处于过渡期。第 10 版仍是有效 Internet-Draft，拟定状态为 Best Current Practice，已经提交 IESG，并在 RFC Editor 队列中等待分配编辑。如果最终批准发布，它将取代 RFC 7451。在那之前，把草案描述成已生效 RFC 会抹去一项真实的不确定性。

CORE 与 TANGO 把重叠写在表内

截至 2026 年 9 月 4 日更新的 IANA EPP Extension Registry 同时列有 Standards Track 与 “Other” 文件，也保留 Active 与 Inactive 条目。更有价值的是，它没有回避功能重叠。

在国际化域名管理方面，注册表备注称 CORE 扩展与 TANGO 对应扩展在语法和功能上相同，但采用不同 XML 命名空间。CORE 与 TANGO 的隐私扩展也有同样说明。两组记录并存，不是因为 IANA 忘了合并，而是线上身份确实不同。

命名空间属于报文的一部分。客户端会发送其中一个空间下的元素，服务器也会声明自己识别的空间。即便两个模式今日看起来完全对应，支持 CORE 的服务器也不会因此自动接受 TANGO 报文。测试套件、版本周期、变更控制和具体部署范围都可能不同。

“功能相同”因此是一项有来源、有范围的证据，而不是无条件互换保证。备注不能证明每一项操作、可选字段、异常路径和未来版本都相同；它也没有解释两条技术谱系为何形成。历史先后、既有部署、组织控制、合同关系或迁移成本，都可能使不同命名空间持续存在。

从目录中删除其中一行，只会制造视觉整洁。旧软件、旧合同和旧交易日志仍会携带被删掉的空间，却失去可查询的来历。注册表保存并存，反而给迁移与审计留下了入口。

用“共存图”回答运营问题

IANA 表格应继续作为登记事实的权威来源，但运营决策需要额外一层。我把它称为“共存图”。这是本文提出的分析工具，并非 IETF 草案或 IANA 的正式要求。

第一层按持久功能分组，例如 IDN、隐私、启动期、费用或联系人处理，同时保留每个扩展的独立身份。第二层记录线上身份：XML 命名空间、规范版本、涉及的命令与响应，以及必要的模式位置。共同功能不能遮住不同命名空间。

第三层记录登记来历：永久引用、文件状态、登记人、专家处理日期与审查路径。若曾经使用后备专家组，或在 REGEXT 列表讨论，这些程序事实也应保留。

第四层专门存放部署证据：哪一个服务器/客户端组合、何种软件和版本、哪些 TLD、哪个日期。证据若只覆盖一组对端，就必须原样写成“一组”，不能润色成“已经行业部署”。

第五层说明重叠主张来自哪里。是登记人自述、IANA 备注、模式对比、互操作测试，还是生产流量观察？“相同”覆盖所有命令，还是只有核心字段？把来源和边界写出来，才能让强证据保持强，而不会被无限外推。

第六层是当前支持矩阵，包括服务器、客户端和可能存在的命名空间转换。若网关能够映射，应写清控制者和损失；若无法转换，这项负面事实同样重要。第七层保存时间线与快照，记录修改、停用和删除。

这样便能把四句话拆开：扩展已经登记；它曾在某处部署；本系统现在支持；它可在本场景替代另一扩展。这四句话可能依次一真一假，不能由注册表的一行共同担保。

删除可能带走理解旧系统的钥匙

新草案区分新增、修改、停用与删除，并要求状态变更给出理由。若条目来自 IETF 共识，删除需要 IESG 批准；非 IETF 条目可由 IESG，或原登记人与指定专家共同推动删除或停用。

这些程序承认注册表是运营依赖。但草案同时坦承，注册表没有历史机制；条目一旦删除，之后便无法在表内追踪。当前目录变干净了，过去却更难解释。

停用和删除因此不是同一动作。Inactive 能提醒新项目不要建立依赖，同时仍让旧日志找到坐标；删除则让坐标退出当前视野。如果引用规范也消失，未来调查者甚至无法判断一段 XML 是合法旧扩展、版本偏差还是任意自定义字符串。

现行注册表协调现在，带日期的快照协调过去。缺少后者时，每次“清理”都可能成为不可逆的证据销毁。

来源