Summary

  • RFC 5225 的 co_repair 报文用 CRC-7 覆盖重建后的完整未压缩头部链，同时用独立的控制 CRC-3 覆盖适用控制字段；后者可能没有参与本次解压，所以前者无法替它作证。
  • 管理层应把“接受当前结果”“推进持久状态”和“发送正反馈”视为三个可分离决定，并为每个决定保存范围明确的证据。

绿色结果之后，还有一个没有亮灯的决定

某个报文已经顺利解压，重建头部的 CRC-7 校验通过，接收端准备给出正反馈。此时，大多数运维界面都会把事件标成成功，然后丢弃过程细节。

RFC 5225 却在 co_repair 格式里保留了第二个问题。CRC-7 对重建后的完整未压缩头部链计算；control_crc3_encoding 则对适用控制字段的拼接结果计算 CRC-3。两者不是同一结论的高低等级，而是分别审查两个不同对象。

标准解释得很清楚：被更新的控制字段不一定参与承载它们的那个头部的解压，所以也不一定被 CRC-7 覆盖。如果没有独立控制校验，就可能出现一个危险组合——当前头部解压成功、正反馈已经发出，控制字段却被错误更新。

这一次结果是真的；下一次所依赖的前提仍可能是假的。

上下文是一项持续运行的资产

ROHC 的效率来自共享上下文。压缩端不再重复发送可以推导的信息，解压端则依靠既有状态还原头部。上下文不是一次计算留下的副产品，而是后续报文解释方式的一部分。

RFC 5225 的状态机没有把“成功解压”与“完全信任上下文”强行合并。在 Repair Context 状态，报文已经能够成功解压，但解压端尚不信任完整上下文。通过规定的 CRC-7 或 CRC-8 验证，系统才可回到 Full Context。标准还允许顺序上较晚到达的旧报文成功解压却不更新状态，也可以不为它发送确认；上下文损坏如何被发现，则由实现决定。

这些细节共同说明：事件成功和状态可信是两类时间跨度不同的命题。前者描述刚刚发生的输出，后者决定一串尚未发生的输出。若日志只留下前者，未来出现偏差时，系统已经主动销毁了最需要的因果边界。

每一种校验都有明确主语

运维语言喜欢说“校验通过”，仿佛校验结果能给整个事务罩上一层真实性。真正有用的问题是：究竟哪些字节、字段和状态变化进入了计算？

在 co_repair 中，CRC-7 的主语是重建后的未压缩头部链；控制 CRC-3 的主语是适用控制字段。二者都不是密码学签名，不能证明来源身份、应用交付、服务质量或某个具体实现没有缺陷。尤其不能把一种校验的结论借给另一种校验的对象。

因此，一条合格的回执必须写明：被审查的对象、计算使用的先前状态、计划写入的字段、实际校验范围、校验结果以及该结果授权了什么行动。只写“通过”与只写“已审核”“模型成功”一样，都省略了真正被验证的命题。

延迟出现的错误最难追责

若当前输出本身错误，故障往往出现在原因附近。若当前输出正确，而状态转移错误，真正失败可能要等到很多个报文之后才出现。那时，正反馈已经促使两端沿着同一个错误前提继续运行。

这种延迟会改变事故调查。团队会检查故障显现的最后一个报文，而不是更早写坏未来状态的那次“成功”事务。自动清理可能已经删除成功路径的中间证据。重试会让分叉扩大。代码回滚可以恢复程序，却未必清除旧程序生成的派生状态。

所以控制目标不只是发现错误，还要保留因果。记录必须让调查者回答：哪一项证据允许接收当前输出，哪一项证据允许改变状态，又是谁允许系统在两项证据范围不相同时继续前进。

把接收、推进与反馈拆开

RFC 5225 不是通用企业架构规范，但它提供了一项可迁移的判断方法。凡是既产生可见结果、又修改隐藏状态的操作，都应分别回答四个问题：当前输出是否满足自身有效条件？计划写入的字段是否得到真正覆盖这些字段的校验？是否应该确认当前结果？是否应该推进、隔离或重新建立供未来使用的持久状态？

四个答案不必相同。某项结果可以被使用，而伴随它发生的学习、缓存、策略或控制状态更新被拒绝。反过来，状态变化内部一致，也不能证明用户得到预期结果。为了操作便利把四个决定绑在一个成功位上，会诱使组织把有限证据描述成全面确定性。

证据边界

RFC 5225 没有证明某个厂商、手机、调制解调器、无线网络或具体实现错误处理控制状态，也没有提供现实部署率、故障数量、数据包轨迹或体验结果。IANA 登记能够证明编号存在，不能证明采用。

独立控制校验的存在也不证明每个修复报文都发生了控制字段错误。它只证明第一项校验的范围不能覆盖第二项校验的对象。设计中的防护措施与现实中已经发生的事故，必须作为两类证据处理。

保存一张双联成功回执

对每项重要的有状态操作，保存两张相互引用的回执。输出回执记录输入、重建或计算过程、精确校验范围、结果与交付边界。状态转移回执记录先前状态标识、拟修改字段、独立校验、接受或拒绝的变更、已发送反馈、结果状态标识以及授权继续的责任人。

成功输出但拒绝状态更新、有效更新但没有交付证明、晚到输入未推进状态、确认被扣留、触发修复和重新建立上下文，都应保留。它们不是噪声，而是成功结论真实适用范围的一部分。

Lu Heng 对运行事实、现实优先和委托代理问题的强调在这里形成同一条原则：机构自信不是运行证据，协议标签也不能承担责任。必须有一个可归责主体，对“今天的输出证据是否足以授权明天的状态”作出决定。

Sources

补充标准记录

  1. RFC 5225 纯文本
  2. RFC 5225 信息页
  3. RFC 5225 Datatracker 记录
  4. RFC 5225 历史记录
  5. RFC 5225 勘误
  6. RFC 5225 行内勘误视图