摘要

  • IESG 于 2026 年 8 月 17 日批准 draft-ietf-regext-ext-registry-epp-10 以“当前最佳实践”发布。它提高了 EPP 扩展的登记、审查和维护标准，却没有把 IANA 目录变成全球服务器能力表。
  • Active 表明至少有一组注册局与注册商或服务器与客户端正在实现并使用该扩展。特定服务器是否公布 URI、特定账号是否有权协商、某条指令是否被接纳，仍须逐层验证。

真记录也能触发假结论

开篇场景是假设，不是对某个注册局事故的报道。它揭示的是自动化设计中很容易发生的类别错误：系统读取了一项真实的公共事实，却借此回答了另一项只能由目标端点回答的问题。

IANA 注册表负责协调。它说明扩展叫什么、稳定规范在哪里、登记人是谁、申报的 TLD 范围是什么、是否披露知识产权信息、当前标为活跃还是非活跃。由此，开发者可以发现既有方案、避免命名空间冲突，并找到可追责的维护线索。

服务器欢迎消息负责描述当下能力。它列出协议版本、语言、对象 URI 以及可选的扩展 URI。登录成功后，客户端身份、权限和本次会话所选服务才得到确认。再往后，指令响应才会说明某一对象在当前本地政策下是否完成操作。

这些证据不能相互代替。注册条目完全正确，服务器也可以不提供该扩展；服务器公布了 URI，某个账号仍可能无权使用；会话完成协商，一条格式正确的指令仍可能违反注册局政策。

新规范提高的是登记质量

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 将申请交给指定专家。专家评估架构是否合理，安全与隐私问题是否有充分文档；遇到利益冲突时必须回避，无法解决的分歧则交回公开社区讨论。

新版还明确了 URI 管理。XML 模式、模式 URI 和命名空间 URI 都必须在语法与语义上成立，并通过 IETF XML Registry 正确登记。IETF 保留的命名空间只供 IETF 流程文件使用；私有规范或其他发布渠道不能借用其权威外观。

这些改动能让实施者更有把握地识别一项扩展并找到可执行规范。这是实质性的制度能力，但它依然没有检查互联网上每一台 EPP 服务器。

Active 有含义，但范围有限

每个条目记录名称、文件状态、参考资料、登记人、TLD 字段、IPR 信息、状态和备注。非 RFC 规范的文件状态应写成 Other，不能套用 Informational RFC 所具有的精确含义。

状态字段不是装饰。Active 表示扩展目前已经实现并投入使用；Inactive 表示没有实现或没有使用，也可用于所引规范已经无法取得的情况。

关键在于证据边界。只要至少一组注册局与注册商，或服务器与客户端完成部署，专家就应采取较宽容的登记态度。这足以证明扩展不是纸面构想，却不足以证明所有注册局、所有客户端账号和所有 TLD 都提供同样功能。

TLD 字段也需要按字面理解。列出具体 TLD，是说明扩展申报的适用范围；Any 表示它不局限于某一个 TLD；N/A 表示它与域名处理无关。Any 绝不是“处处强制支持”的同义词。

因此，可靠的系统不能只保存“已登记：是”和“状态：活跃”两个布尔值。它还要保存观察对象、观察时间和证据所能支持的范围，否则准确目录也会变成错误的全局开关。

允许相似扩展，是因为目录不是裁判席

EPP 以较小的共同核心配合扩展机制，原因在于各注册局采用不同的技术和商业规则。相近需求因此可能产生不同扩展。RFC 7451 建立目录的一个目的，正是让这类重叠可以被发现。

新版程序并不假装能够消灭重复。未部署的提案如遇相似既有扩展，专家应建议申请者重新考虑；但只要其他条件满足，相似本身不应成为拒绝理由。如果扩展已经在一组服务器与客户端之间运行，审查更应尊重现存实践。

这是协调上的务实选择，不是互操作声明。一个条目不会宣告某项扩展胜出，也不会使两个相近命名空间彼此替代。涉及资格、价格或国际化域名的两个扩展，可能有不同数据结构、政策和结果。客户端应匹配服务器公布的精确 URI 及其对应规范，而不是依赖模糊的功能名称。

在线权威链从欢迎消息开始

RFC 5730 规定了 EPP 服务器的欢迎消息。服务菜单列出支持的协议版本和语言、服务器能够管理的对象命名空间 URI，以及可选的扩展命名空间 URI。同一文件也允许服务器按客户端身份限制对象管理权限。

随后，客户端在登录中选择与欢迎消息一致的版本和语言，并声明这次会话要使用的对象与扩展 URI。登录成功后，会话才持续保留身份和授权上下文。

即便如此，未来的指令也没有保证。EPP 结果码会区分本地政策禁止、对象依赖、按服务器政策判断的语义错误、服务尚未实现、数据管理政策冲突，以及临时或终止性服务器故障。用一个“支持”字段把它们压平，会丢失生产控制最需要的信息。

更稳健的证据阶梯依次是：规范已登记；条目当前状态；目标服务器的最新欢迎消息；指定客户端成功协商；指令结构被接纳；交易成功；下游对象状态得到核验。每往下一层，结论都更具体、更接近实际运行。

当前目录不保存完整历史

获批程序规定了新增、修改、停用和删除操作。由 IETF 共识产生的登记如需删除，必须获得 IESG Approval。其他条目可以在 IESG 批准后处理，也可由原登记人在咨询专家后请求删除或停用。责任方消失时，专家可以修正登记人信息。

条目可以在 Active 与 Inactive 之间变化。如果公开规范持续无法访问，专家应先把条目标为非活跃，直至可靠参考恢复。这些机制维护的是注册表当前视图。

文件同时承认一个更难的问题：注册表没有历史机制，条目删除后无法继续从中追踪。依赖目录作出部署决定的运营者，必须自己保存带时间的观察、规范副本或哈希、欢迎消息、会话选择和迁移决定。否则，曾经支撑接入审批的证据会消失，依赖它的代码却依然存在。

制度边界由此清晰：IANA 与指定专家按规则维护公共协调记录；服务器运营者控制实时公布的能力与本地政策；注册商控制其客户端选择哪些协商功能。任何一方都不应替另一方证明其无法观察的事实。

来源