摘要

  • RFC 9682 替换 RFC 8610 的收集版 ABNF。其向后兼容的语法扩展容纳旧合规文件，但使用新增写法不保证旧处理器接受。规范说明
  • 发布决策需要追查生成验证器的血缘：模型字节、实际解析器、生成过程与现场加载对象必须能够关联；运行结果则用于检验这些关联背后的假设。

RFC 编号不是解析器版本

CDDL 用于描述 CBOR 或 JSON 数据结构；CDDL 解析器读取的是模型描述，不是线上消息。RFC 8610

RFC 9682 的规范性附录 A 替换 RFC 8610 附录 B 的收集版 ABNF，并非将整份 RFC 8610 作废。它处理 Errata 6278、6526、6527、6543、6575：分别涉及字符范围一致性、刊印时丢失的反斜杠、文本转义、字节串字面量，以及标签和简单值记法中的数值含义。6543 的问题由修订后的处理方式覆盖，并未照搬其拆分规则提案。RFC 9682

新增的 \u{hex} 直接表示 Unicode 标量值。兼容性的方向不能倒置：旧合规文件仍能匹配相应扩展后的语法，不意味着旧程序能理解新写法；“某个旧工具曾经接受”也不等于“符合旧规范”。修复文本中的规则，不会修改已经交付的程序。RFC 9682 第 2、3 节

需要特别保留的是源字节。RFC 5234 第 2.4 节 将外部编码与 ABNF 语法分开；RFC 8610 第 3.1 节 则规定 CDDL 使用 UTF-8，处理不涉及 Unicode 归一化。因此，审计对象应是实际送入解析器的字节，而非编辑器中看起来相同的文字。

例如，按新规则，label = "o" 与 label = "\u{6f}" 约束相同的文本值，源字节却不同。改写后的文件应另行标识，不能沿用原文件的完整性记录。等价解码值不赋予两种源写法相同的版本兼容性；同一源哈希也没有包含解释者的身份。转义示例

从生成物倒查，而不是从仓库顺推

这里讨论采用生成验证器的系统，不把代码生成视为 CDDL 的唯一使用方式。RFC 8610 第 4.2 节 将数据描述的检查深度留给应用设计者与实现者。因而，模式存在、工具生成成功、应用实际执行检查，本来就需要分别核验。

核对不妨从部署消费者开始：它实际调用哪个验证器，加载对象的摘要是什么，是否与发布清单一致？还要确认请求确实经过此验证器；文件存在于镜像中，不是执行证据。若镜像只是载体，验证器在部署时另行提供，镜像摘要便不能单独为加载对象作证。当前运行环境里的解析器版本，也不能单独倒推生成阶段的版本；在只运行生成代码的架构中，消费者甚至不读取 CDDL 源文件。

再沿该验证器追查模式编译记录、代码生成配置和生成器版本，最后定位实际解析调用。版本字符串应与执行文件或库的构建标识关联，解析结果应关联输入文件的精确字节、选项及诊断信息。单独查询环境默认版本，不能替代该次调用记录。若解析前改写了输入字节，仓库文件的哈希便不是那次解析输入的哈希。

这张履历要回答三个不同的问题：解析器是否接受了输入；模式编译如何处理其中的约束；生成阶段交付了哪个验证器。规范发布给出判断依据，不能替代其中任何一次执行记录。一条只有任务名称和绿色状态的持续集成记录，也不足以说明这些步骤是否针对最终交付物发生过。

本文据此建议将来源关系与产物一起交付，并在消费者侧核对。仅在仓库旁存一份说明，无法证明后来复制、打包和加载的对象就是说明所指的对象。哈希适合比对内容，却不能独自证明来源可信、模型适用于当前协议，或谁曾经解释过它。

可复现重建，还要有独立的值与类型检查

可复现重建应以留存的原始模型、解析器构建、编译与生成配置为起点，重复得到可核对的产物，而不是重新执行一个同名任务。原始文件必须仍可取得；只有摘要，不能重建文件。解析器版本不变而生成器改变，或模型字节不变而解析器改变，都应成为独立的比较条件。

比较还应分开字节与语义。重建输出逐字节一致，说明固定条件下能够再生产该产物，不证明规则解释正确。输出不同，也应先定位差异，不能直接断言接受集合已经改变。若差异来自构建时间等非语义字段，应明确记录，不能把这种比较写成“产物完全一致”。

测试设计宜同时覆盖旧写法、新增转义及相邻非法形式，记录预期字面量值、数据类型、接受或拒绝阶段。否则，解析器返回成功，仍可能没有提供足够证据说明它按预期理解了转义。若样本和验证逻辑出自同一生成过程，二者相互吻合也不能排除共同解释错误；需要依据规范独立确定预期。

这种审慎与 RFC 9682 第 4 节 的边界一致：它提醒新旧工具混用可能增加解释混淆，强调核实模型来源及适用性。这是需要核查的风险条件，不是对任何具体产品或已发生漏洞的认定。

让运行时消息反过来检验上游

源文件中的转义不是线上消息的转义协议。RFC 8949 第 3.1 节 规定 CBOR 文本字符串以 UTF-8 编码，字符不以这种转义形式传输；字节字符串与文本字符串也是不同类型。因此，不能因为模型出现 \u{hex}，就推定所有接收消息的消费者都要解析这段源语法。

对于一条待核查的消息，应关联原始报文字节、解码后的类型和值、实际验证器标识、验证结果与应用处理结果。RFC 8949 第 1.2 节 区分格式良好、有效以及符合应用预期：能解码、满足 CBOR 约束、符合应用要求，并非同一个结论。

假设固定同一消息及相关配置后，两个标称等价的部署给出不同验证结果，那么“这两份交付物对该输入行为等价”的假设就被反证。差异可以推动核对加载对象、生成配置、模型解释和消息解码，却不能直接归罪于旧解析器。反过来，两者接受同一个样本，只证明该样本下的结果一致，不证明所有消息的接受集合相同。

互操作观察还要关联交互双方的部署版本、交换消息和各自处理结果。它不能由单侧解析通过代替，更不能反向证明消费者支持未曾接触的新源语法。如此倒查，运行证据才具有纠正上游假设的能力，而不只是给构建报告再添一个绿灯。

借用 Lu Heng 对现实层与象征层的区分，可以把版本标签与实际执行对象分开审视。这是工程类比：标签帮助组织工作，但决定这条消息如何被检查的，仍是现场实际调用的逻辑。