摘要

  • RFC 5264 让 PUA 用完整状态建立 publication，再用带条件的差分修改它。publication 到期时，合成器必须清除修补后的整份完整状态，而非仅删除最后一次差分。
  • 可审计凭证必须把 entity-tag 链、差分正文、修改前后完整文档哈希、有效期、刷新结果、合成器提交以及对复合状态的影响绑定在一起。

先看消失的是什么

一台终端先发布完整的在线状态。随后，它只发送变化：把某项服务改为开放，删除过期说明，再调整联系方式的优先级。三个消息都很小，也都得到成功响应。

最后一次刷新没有赶上截止时间。合成器中由这台终端贡献的整份 publication 消失了。若只查看最近一次差分，人们很容易说成“最后那个优先级修改到期了”。协议事实并非如此。

到期的是 publication 的软状态租期。差分已经完成使命，成为当前完整文档的一部分；它没有留下一个由协议保证的独立寿命。

差分是传输形式，不是持久化单位

RFC 3903 的 PUBLISH 建立有期限的事件软状态。创建、刷新、修改和删除都围绕 publication 运作。RFC 5264 解决的是另一层问题：完整 PIDF 很大，而一次变化可能很小，重复传送全部内容会浪费带宽。

因此，局部发布机制第一次仍发送 pidf-full，建立完整基线。后续修改才可以发送 pidf-diff，也可以重新发送完整状态。合成器执行差分之后，持有的仍是一份完整 publication。

把差分误当成独立记录，会把网络优化提升成不存在的存储语义。消息体可以是局部的，状态对象仍然是整体的。

Entity-tag 只给 publication 排序

成功的 PUBLISH 会返回新的 SIP-ETag。下一次刷新、修改或删除通过 SIP-If-Match 指明自己所依赖的既有状态。Request-URI、事件包和 entity-tag 一起界定被操作的 publication。

局部 PIDF 本身也有 version 属性，但 RFC 5264 没有把它变成第二套发布版本。两套时钟若互相矛盾，会产生没有清晰处理办法的歧义。规范选择 entity-tag 和条件请求作为顺序依据。

这意味着，单独保存一份差分 XML 并不足以证明状态改变。没有前置标签、请求条件、响应和新标签，就无法证明它针对哪份状态，也无法证明合成器接受了哪条因果链。

合成器保留结果，不承诺补丁历史

有效的 pidf-diff 包含按顺序执行的添加、替换和删除操作。合成器把它们应用到本地完整文档，再把结果交给普通的状态合成逻辑。

RFC 5264 明确说明，合成器不保留用于回滚的已应用补丁记录。因此，这套机制不是版本控制系统。它可以确定地执行变化，却不承诺保存每个历史快照或反向路径。

若业务必须恢复某个早期状态，可靠方法是提交一份新的完整状态，而不是假定平台能够“撤销最后一个补丁”。

到期删除的是当前完整贡献

有效期的变化作用于修补后的完整 publication。若 PUA 没有刷新，合成器必须清除整份完整状态。它不会把最后一个差分从文档中减掉，再猜测出旧版本。

这里有一个容易被指标掩盖的不对称：最后一个差分可能只有几百字节，而依赖刷新存续的完整 publication 可能大得多。小消息并不意味着小的到期影响。

相反，一个很早的差分只要已经进入完整文档，就可能跨越多次刷新一直有效。决定它是否仍在的不是原始差分时间，而是 publication 是否继续存在。

整份 publication 不等于整个资源

边界还必须向另一侧收紧。RFC 3903 允许多个终端为同一资源分别发布状态，合成器再形成复合视图。系统也可能配置不会到期的硬状态。

因此，清除某一份 publication 不必然删除其他发布者的贡献，也不必然让整个资源变成空白。最终可见状态取决于剩余输入与合成策略。

事故记录应写明：哪一份 publication 到期、哪些仍然存活、是否存在硬状态、复合结果前后哈希是什么。笼统写成“整个 presence 被清除”会越过规范能够证明的范围。

接受之前的回退，与到期后的清除不同

若 pidf-diff 被当作初始发布发送，它没有完整基线，必须被拒绝。文档处理错误应返回 400，并可附带 RFC 5261 诊断。若在整份 publication 完成处理前发生其他错误，则返回 500，并恢复原先的本地状态。

这些分支保护的是原子性：尝试没有成功，所以旧状态继续存在。publication 到期发生在变化已经成功接受以后，语义是移除当前软状态，而非拒绝某次尝试。

日志必须区分三类事实：条件不满足或正文无效、修改已提交、publication 后来被显式删除或自然到期。把它们都归为“失败”会丢掉真正的控制边界。

Publication 状态凭证

对于会触发后果的系统，应保留：

  • Request-URI、事件包、发布者、presentity 与 publication 身份；
  • 前置 entity-tag、SIP-If-Match 和响应返回的新标签；
  • 完整或差分内容类型、原始字节、哈希与接收时间；
  • 每个添加、替换、删除操作的顺序与结果；
  • 处理前后完整文档哈希；
  • 请求、批准和实际生效的有效期；
  • 刷新截止时间、发送时间、响应与提交确认；
  • 显式删除或自然到期事件及其清除对象；
  • 其他活跃 publication 与硬状态贡献；
  • 复合结果哈希、策略版本与下游通知；以及
  • 后续界面显示、自动决策或人的行动。

这条证据链遵守现实分层。Entity-tag 证明条件顺序，合成器提交证明本地状态，复合结果证明计算输出，下游接收与人的结果仍需各自证据。任何一层都不应借用另一层的权威。

Sources