摘要

  • RFC 5262 把完整状态与差异更新纳入同一版本序列，可以发现漏项；这份连续性只属于特定观察者与订阅上下文。
  • 可辩护的凭据应绑定基线、每个版本、观察者、授权政策、重建和过期状态，并把后续联系尝试与人的真实反应另行记录。

没有丢包，视图仍然过时

一台客户端从完整版本 567 开始，按顺序收到 568、569 和 570。没有缺号，所有补丁都成功。界面于是显示“状态同步”。

问题发生在 567 之前。那份完整文档来自旧的订阅缓存，授权范围也已改变。后续序列越完整，错误基线就被重建得越稳定。

版本连续性解决的是链条问题，不是起点问题。若没有基线字节、哈希、馈送身份和政策版本，“连续”只能说明从某个未知前提出发没有漏步。

完整文档与差异文档共用一个计数器

RFC 5262 为 application/pidf-diff+xml 定义 pidf-full 与 pidf-diff。前者建立本地合成基线，后者利用 add、replace、remove 只传输变化部分。

启用可选的 version 后，相邻更新递增一，完整文档与差异文档共用同一序列。接收方因而可以排序，并在预期 569 却收到 570 时发现缺口。

计数器不检查基线中的陈述是否准确，也无法显示被政策隐藏的信息，更没有测量现实变化到发布之间的延迟。

不同观察者可以拥有不同而正确的序列

在线状态可能包含敏感信息。外围协议应决定在何时向哪个观察者披露哪些字段。因此，一个缺失字段可能为假，也可能只是不得披露。

版本号只对获准出现的投影排序，不能穿透授权边界。内部值班人员与外部合作方可以各自收到无缺口序列，却看到不同联系方式；两条链都可能合规。

所以凭据要保存 watcher、订阅与授权决策。除非系统明确证明两条馈送共用范围和版本空间，否则不能用相同数字推断相同状态。

发现缺口不是完成恢复

缺号会触发警报，但不会自动创造可信基线。应用仍要决定暂停展示、请求新的 pidf-full、丢弃中间结果，还是在明示降级的条件下继续。

恢复回执应包含首个异常版本、缺失范围、最后可信哈希、新完整状态的哈希，以及它何时替代旧视图。告警从红变绿，不足以证明一致性如何恢复。

协商支持不等于应用成功

SIMPLE 系统可以协商部分通知的媒体类型。协商只说明双方理解格式。某个 diff 仍可能没有到达、选择器失败、仅在内存中完成，或未写入读者实际访问的状态。

接收、XML 操作、持久化和公开可见是四个边界。只有把接收序号、操作结果、中间哈希、存储确认和下游读取连起来，才能说清系统真正完成了什么。

良构 XML 不是现实中的可用性

文档必须良构并且应当通过模式校验。这些是表示层保证。它们不能证明终端仍在线、用户仍愿意接听，或后续会话建立成功。

最准确的说法是：“该观察者重建了这条馈送中最新收到的状态。”若要说“这个人可联系”，还需要邀请、协商、交付与人的回应。

在线状态增量回执

至少保存：

  • presentity、watcher、订阅、对话与馈送身份；
  • 授权政策、版本、决定与允许字段范围；
  • 已接受的媒体类型和字符集；
  • 完整基线字节、哈希、版本、接收时间与过期时间；
  • 每个 diff 的字节、哈希、版本、顺序和接收时间；
  • 预期版本、收到版本与缺口；
  • 操作、选择器、前像和执行结果；
  • 中间状态与最终重建文档哈希；
  • 恢复请求、新基线与弃用状态；
  • 存储确认和下游可见性；
  • 后续联系、协商、交付和人员或服务结果。

这张回执不会让在线状态变成确定事实。它阻止一条馈送的连续性冒充完整的组织真相。

Sources