摘要

  • 9 月 13 日发布的第三版仍是个人 Internet-Draft，并非 REGEXT 已采纳文件或 RFC。
  • 注册请求改为援引独立发布的冻结规范；数据模型、标识符和线上格式没有变化。
  • 本次核验的 IANA 名录尚无 reliabilityAssessment。在文件中写下请求，不等于申请已被接收、审核或批准。
  • 固定一个名称的技术含义，不意味着取得标准共识，也不替代本地部署与行动授权。

改动发生在参照，而非接口

同一个扩展名称，必须让不同实现读到足够明确的含义。这与技术共同体是否赞成整个设计，是两道不同的问题。RDAP Extension for Structured Reliability Assessment Metadata 第三版把这一区别落实到了发布安排上。

该提案在 RDAP 响应中承载对注册商和域名的评估。9 月 13 日的新版本明确说，数据模型、扩展标识符、JSON 成员名和线上格式均未改变。变化是第 13 节的注册依据：reliabilityAssessment 所指向的规范文本。

第二版原本预期等到 RFC 发布才注册。第三版将这一表述替换为另一种解释：缺少的是稳定参照，不是任何情况下都不可绕开的 RFC 门槛。作者另行发布了 bcsec-RDAP-RA Version 1，据此提出名称注册请求。稳定性要求没有取消；文本声称已经补足该条件。

这还不是注册结果。本次冻结的 IANA RDAP Extensions 名录中没有相应条目。Datatracker显示的是活跃的个人草案，状态为 I-D Exists。文件里的请求也不能证明正式申请已经送达。

稳定规范可以来自 RFC 之外

现行名录实行 Specification Required。RFC 8126要求指定专家审核批准，并有一份永久、公开可获取、足以支持独立互操作实现的规范。RFC 是理想的发布形式，但该政策明确允许 RFC 流程之外的文本。

RFC 7480建立了 RDAP 扩展名录及注册模板。另一份工作组草案 RDAP Extensions提出更明确的稳定参照与评审指导；不能因为个人提案援引它，就把尚在修订的指导当成已经生效的替代规则。

因此，专家审核不是简单占用名称；即使满足注册条件，也不会把个人工作变为 IETF 共识。独立规范明确保留 REGEXT 不采纳该扩展的自由。规范由 Bertoldi Cybersecurity 单独发布，同时通过个人草案说明与 Simon Pietro Romano 的共同技术设计。

冻结文本把纠错变成另一条路径

独立规范承诺不改动权威文本的字节，连编辑性修正也不直接写回。错误放在独立勘误文件中，勘误不具规范效力；影响互操作的修正需要另一个 URL 上的新规范，旧文本继续保留。文件还指定了镜像，并规定发生差异时以权威 URL 为准。

这是发布者的维护承诺，不是本报道已经验证的长期事实。成功下载只能证明当时可获取，不能证明未来永远可获取或字节永远不变。这个安排的价值，在于将“发现错误”与“悄悄改写实现所依据的规则”区分开。

附录 C 声明数据模型相同，却列出了文档层面的差别：对未完成草案的引用改为说明性内容，或重述互操作所需规则；评审邀请和未决问题措辞被删除或改写。独立规范没有单独请求 RDAP JSON Values 注册，个人草案另行推进该事项。技术一致，不等于所有程序用途都可互换。

若将来出现 RFC，注册方表示会请求把名录参照更新为它。这是一个未来决定，不会自动改变已部署实现。该扩展仍只是承载评估结果的共同格式，并不选择评分方法、阈值或执行措施。

来源