RFC 5196：在线能力不是当前协商就绪证明

摘要

RFC 5196 解决的是一个真实问题。基础 PIDF 中的联系 URI 未必告诉观察者，一个 tuple 代表语音、视频、消息还是别的服务。扩展借用 RFC 3840 的能力词汇，并依照 RFC 4479 的人、服务、设备模型表达动态特征。观察者因而可以在联系前获得更好的线索。

问题不在“线索”二字，而在系统如何给它加上时间。桌面电话最后一次发布视频支持后断网，手机随后成为实际接听端。如果聚合器只保留一个没有来源和到期信息的布尔值，昨天的设备陈述就会被读成今天的人物陈述。数据格式依然正确，语义主体却已经换了。

RFC 5196 没有要求在线状态与真实服务或设备能力始终一致，反而提醒观察者不要期待完全对齐。发布可能不完整或不准确，使观察者错过本可进行的通信，也可能诱发无法完成的尝试。这不是规范在为错误开脱，而是在给自动化划定权力边界。

一条能力至少有多个时间点：源设备观察能力的时间、发布代理发送的时间、服务器接收和变换的时间、聚合器生成视图的时间、观察者收到的时间，以及会话真正发起的时间。把它们压成一个 updated_at，就无法判断陈述在哪一步变旧。

到期同样需要对象范围。服务仍可用，不代表原设备仍在线；人的在线状态没有变化，也不代表媒体栈没有重启。新发布也未必覆盖旧发布的同一主体。只有保留 tuple、服务或设备身份，系统才能知道新值是在替换旧值，还是在描述另一个对象。

因此，设备切换测试不应只看最终页面是否变绿或变灰。它要验证旧源退出后其能力何时失效，新源进入后如何与旧源并存，聚合器如何保留冲突，以及每个观察者的缓存何时完成收敛。

时间之外还有权限。presentity 可以不公布实际拥有的能力。规范举例说明，即使服务支持语音，用户也可能选择不发布。授权规则或在线状态服务器还可以为特定观察者限制或修改信息。因此，同一时刻不同观察者看到不同文档，可能是正确的政策结果。

格式中 supported 表示明确的正面陈述，notsupported 表示明确的负面陈述。规范不鼓励罗列所有无关负项；同一个值若同时出现于两处，观察者可以按支持处理。这里没有任何规则允许客户端把“缺失”无条件改写为“不支持”。

这种改写会同时伤害隐私与可用性。它让下游以为自己获得了一份完整清单，并据此拒绝尝试；同时又可能把某个观察者专属的隐藏结果传播给另一观察者。正确的状态至少应区分：明确支持、明确不支持、未披露、未知、过期和冲突。

RFC 5196 的适用范围把能力信息称为联系前对偏好、意愿和能力的提示，并明确说它不替代 SDP 这样的 SIP 媒体协商。在线状态可以影响“要不要发起、先尝试哪一种”，却不能替会话回答“这一次究竟接受什么”。

一次真实联系还有新的主体和证据：目标 URI、路由到达的端点、SIP 请求与响应、SDP offer/answer、最终选择的媒体，以及当时是否有人愿意接听。即使在线状态完全准确，用户仍可能拒绝；即使某能力没有披露，协商仍可能成功。

语言能力尤其容易被越权解释。一个服务声明可处理某种语言，不等于有一名使用该语言的人正在场并愿意响应。设备支持视频也不等于这一服务、这一观察者、这一时刻已经获得视频许可。语法上的小差异，对自动派单或紧急联系会变成重大的制度差异。

规范承认，合并多个在线状态来源可能丢失信息或产生不匹配。聚合器由此成为一个决策者，而不是透明管道。取并集可能构造出一台现实中不存在的“全能设备”；取交集可能遮蔽真正会接听的终端；“最新值优先”则取决于哪个时钟和哪个主体可以比较。

每个值都应携带发布代理、源版本、主体身份、发布时间、到期时间和授权范围。发生冲突时，输出还要记录输入集合与解决规则。只保存赢家会让结果看上去简洁，却使后续无法证明错误来自源设备、隐私政策、服务器变换、聚合逻辑还是观察者缓存。

最小凭据可以很克制：presentity、watcher、订阅上下文，tuple/服务/设备，PUA，明确的正面、负面或未披露状态，政策版本，服务器变换，聚合输入、冲突决定，观察者可见文档的哈希与接收时间。随后另开一条链，记录联系决策、SIP、SDP、接听端和现场结果。

这套凭据是运行治理建议，不是把 RFC 5196 改写成新的线协议。它遵循 Heng Lu 强调的现实层次：符号应服务于运行中的现实，而不能凭汇总标签夺取现实的权威。能力在线状态的价值正在于提前提供轻量提示；承认它不是协商证明，才不会毁掉这种价值。