摘要

  • RFC 9876 为大部分 CoAP Content-Format 编号引入专家审查和语义核验，修补旧流程曾接受错误组合的问题。
  • 登记证明编号与媒体类型、参数及可选内容编码之间形成受协调的对应关系；它不证明解析器、负载、应用配置或实际效果。
  • 上线决定必须另存处理器版本、适用配置、安全边界、资源预算、本地授权、回滚责任与运行观察。

一批环境传感器升级后，消息仍携带同一个 Content-Format 编号。中央清单能查到它，新固件也声称支持它；但三个园区分别部署了不同版本的解码库。此时最危险的捷径，就是把“编号存在”当成“三处行为一致”。

RFC 9876 是 2025 年 10 月发布的 IETF Proposed Standard，更新了 RFC 7252 的登记规则。CoAP 用一个无符号整数同时表示 Media Type、参数和可能存在的 Content Coding，节省链路开销。编号越紧凑，错误对应关系被自动传播的成本也越低。

旧有先到先得流程没有明确要求核验类型与编码组合在语义上是否成立。RFC 9876 说明，这种缺口已经造成错误登记。新规则的价值，是把原本被误认为“文书动作”的判断工作写成公开清单。

审查究竟确认了什么

IANA CoRE 参数登记表把 16 位空间分为不同区域。稀缺的 0–255 采用 Expert Review；256–9999 需要 IETF Review 加 Expert Review，或 IESG Approval 加 Expert Review；10000–19999 与 33000–64997 也需要专家审查。

20000–32999 仍可先到先得，但申请必须极其简单：媒体类型已经登记，没有参数，没有 Content Coding，而且未在该表中使用过。64998 与 64999 专供文档示例。65000–65535 只供实验，不得用于生产部署。

专家要检查是否重复、媒体类型是否已登记或符合有限的临时条件、参数名称和值是否合法、字符串格式是否规范、内容编码是否存在。短编号还要考虑稀缺空间的消耗。

通过审查，能够证明一份特定申请在当时符合这些条件。它不能证明某款芯片上的解析器没有越界问题，也不能证明发送者可信、密钥有效、字段符合本地业务约束。登记系统协调共同词典；它并不远程操作每台读这个词典的设备。

临时状态不会自动抵达固件

如果所引用的 Media Type 尚属 provisional，Content-Format 登记也标为临时。完成规定流程并成为正式媒体类型后，临时标记才会移除；申请或临时类型被放弃时，编号可按相应区段规则回到 Unassigned。

网页上的状态变化不会修改已出厂设备。网关可能缓存旧表，固件可能锁定早期定义，供应商也可能停止维护。RFC 8126进一步指出，专家审查针对某个时间点上的某个文档版本；实质修改可能需要复审。因此证据不能只写“已批准”，还要保留版本与时间。

编号会越过 CoAP 的边界

RFC 9193允许 SenML 用 CoAP Content-Format 整数说明嵌入二进制数据的表示方式。这样，数据经过多个中间方或长时间保存后，仍可能被自动解释。反面是：过时对应关系也会一起进入消息代理、归档、分析系统和数字孪生。

因此系统应区分七个状态：登记表已知、处理器已安装、应用配置支持、保护已验证、负载语义有效、本地动作获准、实际效果已观察。Unknown、unsupported 与 invalid 不能合并。把未知内容悄悄退化为通用字节流，只是保存了字节，并未获得解释或执行它们的权限。

RFC 9876 新增的 Media Type 列提高了溯源能力，但链接只指向规范来源，不指向发送者信誉。格式正确的对象仍可能被篡改；签名对象仍可能来自不受信任的密钥；合法读数仍可能要求超出设备许可范围的动作。

安全链条应由编号选择候选解析器，再由版本化配置核验字段、安全机制确认来源与完整性、本地策略决定影响，最后用遥测确认效果。编号只负责第一步。