摘要

  • IETF 于 2026 年 9 月 28 日收录 draft-ietf-cbor-serialization-09。文件首页称其将在获批后更新 RFC 8949；目前它仍是 CBOR 工作组最后征询阶段的互联网草案。
  • 草案第 7 节拟规定：未来标签定义不得影响标签自身所定义类型之外的既有数据类型。已存在的大整数标签 2、3 被明确豁免。
  • 这条限制在上一版草案中已存在。第 09 版的新闻价值，是更清楚地标示拟更新现行标准，并请求 IANA 将该节列为标签登记参考；两件事都尚未完成。

编号不能越权

现行 RFC 8949 为 CBOR 规定数据模型和二进制编码。公开的 IANA 标签登记表 让实现者查到编号、承载的数据项和语义。标签可以给一个数据项增加特定解释；它不应因为被登记，就能让所有未带该标签的整数、字符串或其他既有类型改换含义。

第 09 版草案 试图把这种边界写清楚。第 7 节要求，未来标签定义不得纳入、修改或以其他方式影响其自身类型以外的数据类型。草案仍允许多个标签相互影响，但条件是各标签的定义权方明确同意。这给协作留下空间，却不把单个新标签的说明书升级为整个格式的修订权。

困难在于历史例外。标签 2 和 3 表示正、负大整数，RFC 8949 用它们延伸整数范围；它们并非完全独立于整数的另一组类型。草案因此没有追溯否定它们，而是单列豁免。豁免解释既有设计如何得以保留，不能被下一位标签作者援引为改动旧类型的通行证。审阅新标签时，关键问题应是：它定义了什么新类型？是否要求解码器在标签不出现时也改变原有解释？

草案要更新什么，登记表又写了什么

第 09 版首页出现 Updates: 8949 (if approved)。第 10 节请求 IANA 在 CBOR 标签登记表中增加对第 7 节的引用，并登记 CDDL 的 .serial 控制运算符。这些是将来可能发生的动作，不是今天已经生效的登记结果。查询时，IANA 标签表的通用登记参考仍是 RFC 8949。

时间顺序也不能写反。第 08 版 已含未来标签约束及大整数例外，因此不能宣称 9 月 28 日才首次提出该规则。IETF 的近期草案清单显示第 09 版的日期和工作组最后征询状态；最后征询不是 IESG 批准、RFC 发布，更不是某款产品完成适配的证据。

同一草案还区分“preferred-plus”与确定性序列化。它们约束的是协议如何输出字节；标签权限约束的是谁能定义数据含义。即使为了确定性编码而排序映射项，解码后的映射也不会因此获得有语义的顺序。本文关心的是旧类型解释权，不把它写成另一篇关于有效 CBOR 字节串及完整字节哈希差异的报道。

来源