摘要

  • draft-ietf-regext-rdap-extensions-15 拟在 IANA RDAP 扩展登记表中加入弃用日期。登记联系人可请求弃用自己的扩展，IESG 可请求弃用任何条目；这项权限改变登记状态，不会远程删除部署代码。
  • draft-ietf-regext-rdap-versioning-07 让服务器在 /help 中公布版本、默认项、前后继关系和 start/end，在响应中说明实际版本，也允许客户端提出版本偏好。它能协调迁移，却不能列出所有未知客户端。
  • 退役决策需要一份收据，把登记授权、每台服务器的计划与实况、有限范围内的旧版本需求以及仍不可见的依赖分别保存。这是 Daniel Kade 的治理建议，不是 IETF 要求。

“已弃用”是一个很诱人的终点词。它看起来已经完成了判断、通知和退出。然而在开放查询协议里，这个词最多精确回答一个问题：共享登记表如今如何描述这个标识符。至于服务器还提供什么、客户端还依赖什么，答案分散在别处。

2026 年 8 月 13 日发布的 RDAP Extensions 第 15 版把 RDAP 描述成一个由不同信息权威运营的生态。客户端可能从引导服务经过重定向，再沿引用访问 TLD、注册商或 RIR 的服务器。任何一方都难以看见全路径上的全部软件。

这份文件仍是 REGEXT 工作组草案，目标状态为 Standards Track。Datatracker 显示工作组提出问题、需要修订，且没有负责的 Area Director。7 月 31 日的 RDAP 版本管理第 07 版同样只是工作组 Internet-Draft。它们都不是 RFC，也不证明生产部署。

登记表能决定标识符的公共身份

RDAP 扩展标识符出现在 rdapConformance，也可成为 JSON 名称、路径或参数的一部分。标识符本身是不透明的。尾部数字看似版本号，却不自动证明谁是前身、谁是替代者；这种关系必须由规范明示。

第 15 版拟增加 Deprecation Date 字段，并把申请权限分给两类主体：条目所记联系人可以请求弃用自己的扩展，IESG 可以请求弃用任何 RDAP 扩展，IANA 负责把日期写入登记表。权限链并不模糊。

它的边界也不应模糊。IANA 可以权威地说明一个共享名称不再是当前选择，却不能指挥独立服务器何时关闭兼容接口，更不能更新陌生人电脑里的库。登记动作提供方向，不等于部署动作。

草案要求为两个已标为 OBSOLETED 的 ICANN 标识符补记 2025 年 8 月 21 日：icann_rdap_response_profile_0 与 icann_rdap_technical_implementation_guide_0。截至研究时，IANA 页面最后更新于 2026 年 9 月 1 日，能看到这两个旧标识及版本 1 后继项，但尚无独立弃用日期栏。这不是 IANA 失职的证据，因为新增栏位仍停留在草案中。

登记准入采取 Specification Required 与 Expert Review。第 15 版要求规范稳定、可取得，并足以让独立实现互操作；它还提议至少三位专家，并让另一位专家复核每项申请。这些规则能判断一个公共词汇是否适合进入登记表，不能盘点所有已经安装的软件。

服务器只能承诺自己的支持周期

版本草案提供了另一组证据。versioning_help 可以在 /help 中列出服务器支持的扩展版本、默认值、规范链接、前身与后继，以及开始和结束时间。versioning_data 标记一份具体响应使用了哪个版本。客户端则可通过 versioning_list 表达偏好。

三者分别描述能力、执行结果和请求意图。服务器支持旧版，不等于默认返回旧版；一份响应使用新版，不等于旧版已经移除；客户端没有指定版本，也不等于它理解所有新版字段。把它们合并成一个“迁移完成”灯号，会丢掉最关键的因果关系。

end 是服务端的截止声明。到点后，相应版本对象必须从支持清单中移除；如果没有 end，则表示尚无计划结束支持。它能约束服务器对外说过的话，却不能证明外部客户端已经完成升级。

对于不兼容变化，第 07 版建议先部署中间版本，让旧元素与替代元素共同存在，公布其关系，给客户端迁移时间，然后再移除旧元素。另一条路径是先改变默认版本，同时允许客户端在截止前点名旧版。设计合理，但“足够长”没有全球统一答案。每天运行的受管客户端与一年才启动一次的合规脚本，不共享同一时钟。

第 15 版直接承认：RDAP 客户端与服务器之间没有必然关系，因此无法绝对判断一次破坏性变化不会影响所有客户端。这句话禁止的是虚假确定性，不是赋予匿名客户端永久否决权。永远保留旧接口同样会积累歧义、成本与安全风险。

观察需求，不能借机建立读者档案

服务器日志可以显示某段时间内是否收到旧版本请求，可以比较默认值切换前后的比例，也可以测试重定向与引用路径。对于受管客户端，维护者还可确认升级。这些证据都会减少不确定性，但只能覆盖被测范围。

若为了证明迁移而永久保存查询对象、网络地址、客户端指纹与版本偏好，兼容性治理就会变成监控系统。合适的公开指标应当聚合、限时，并说明覆盖节点、排除项和保留规则。“这些服务器在这段窗口没有观察到旧版请求”是可验证陈述；“互联网已经没有依赖”不是。

三种权限的一份退役收据

收据第一部分记录确切标识符或版本、请求弃用的合格主体、IANA 接受时间和公开登记状态。这是授权收据。第二部分说明前身、后继、破坏性变化、共存方式与稳定规范，不能靠数字后缀猜测。

第三部分按服务器或运营集群保存 /help 快照、默认值切换、start/end、代表性 versioning_data、旧请求的错误处理、回滚条件以及实际移除时间。计划日期与观测事实必须是两个字段。

第四部分只发布受限的需求证据：测量窗口、覆盖服务器、隐私聚合、旧版请求比例、已联系的受管客户端、尚未解决的关键依赖和不可见范围。未知应当保留为未知，而不是伪造成零。

最后，移除决定要写明决策者、证据截止点、例外与事后观察。这样，登记权威、服务器运营者和客户端维护者可以协作，却不会有人借一条日期宣称自己代表另外两方。

来源