摘要

  • RFC 5344 是 Presence 与即时通信跨域互联的用例文档，不定义新协议，也不证明任何联邦已经解决安全问题。
  • 为减少同一 presentity 面向大量远端观察者的重复流量，完整 Presence 文档和隐私规则可以交给对端过滤；这只是迁移执行位置，不是把用户授权转让给对端。
  • 可靠控制必须把策略版本、数据版本、观察者身份、规则匹配、字段变换和撤销结果绑定在同一条可审计记录中。

一次撤销跨越了两条时间线

Presence 的权限不是“看”或“不看”两个值。RFC 5025 所描述的规则可以分别控制人物、设备、服务、活动、心情、地点、关系和备注等信息。某个同事可以看到在线状态，却不能看到地点；家人可以看到更多；被屏蔽者可能只收到礼貌性阻断的贫乏视图。

当规则只在本域执行时，策略服务器读取当前观察者身份和当前策略，再生成目标视图。跨域规模改变了成本。RFC 5344 指出，如果远端网络里很多观察者都订阅同一个人，本域可能不得不发送许多不同版本。优化方式之一是只发送一次完整文档，并把用户的隐私规则交给远端，让远端为本地观察者生成各自视图。

带宽下降，时钟却增加了。完整文档有生成时间，规则有版本和生效时间，观察者身份映射有自己的更新时间，跨域传输有延迟，远端缓存还有过期策略。撤销并不只是一条数据库写入；它要穿过这条链，终止或重算已有订阅，并处理已经排队的通知。

因此，“远端遵守了规则”是不完整的表述。要问它遵守的是哪一版，针对哪个身份，在什么时间处理了哪一版文档，并输出了哪些字段。

用户仍是规则的委托人

RFC 6271 把 RFC 5344 的用例进一步写成需求，并明确提出：跨服务提供者共享用户隐私设置，必须得到该用户的明确同意。这个限定十分重要。网络间合同可以约定技术行为，却不能代替 presentity 对自身信息的授权。

同意共享策略，也不等于同意无限期保存策略、把完整文档用于其他目的，或允许任何联邦成员读取。它应当包含接收方、目的、期限、字段范围、撤销方式和二次转交条件。否则一次为节省流量而作的许可，会变成永久的数据托管权。

RFC 4745 把授权规则拆成条件、动作和变换。请求者的认证身份可以进入条件；所有匹配规则合并后，决定是否允许以及显示哪些信息。这意味着远端不是简单“转发”，而是在替用户执行判断。它必须能证明输入身份、所用规则和输出变换。

网络身份与观察者身份也不能合并。对端 TLS 证书能说明哪个系统建立了连接；联邦成员资格能说明哪个行政域受到协议约束；它们都不能单独证明 Alice 的外域标识就是规则里预期的那个人。别名、账户合并、电话 URI 与 SIP URI 的差异，都会让技术上有效的身份落到错误主体。

完整文档是危险的中间态

对大多数观察者而言，完整 Presence 文档可能从来都不应可见。它之所以到达远端，只因为远端承担了过滤工作。这个中间态可能包含地点、设备、活动、关系和时间模式，一旦泄露，损失大于任何单一授权视图。

安全传输只能证明其中一段。SIPS 或 TLS 在特定信任条件下保护链路和端点，不证明远端内部管理员无法读取，不证明缓存按期删除，也不证明变换代码没有多放出一个字段。RFC 5344 自己把这些安全解决方案留在范围之外，并提醒策略迁移可能暴露谁在某人的黑名单里。

运营记录应把完整文档单独列为敏感资产：来源 presentity、文档版本、策略版本、接收对端、加密上下文、保留期限和删除证据。生成的每个视图再记录观察者身份、匹配规则和实际披露字段。审计目标不是永久保存所有明文，而是留下足以证明执行边界的最小证据。

如果采用另一种优化——不同视图分别绑定一组观察者——风险从“共享整套策略”变成“文档与名单的原子绑定”。名单和文档可能走不同路径，也可能在到达时使用不同快照。没有共同版本或摘要，远端无法证明这份视图是为这组观察者生成的。

列表地址不是一份集体授权

RFC 5344 还讨论个人列表、公共列表和临时列表。观察者订阅一个列表 URI，看起来只有一次请求；列表服务却会把它展开为多个目标。RFC 5363 强调完整性、保密性、访问控制和放大风险，RFC 5360 则把一对多 URI 变换视为同意问题。

个人观察列表只说明观察者想看谁，不说明每个 presentity 愿意展示什么。公共列表的管理员有管理成员的权力，却不自动拥有成员的隐私授权。临时会议列表会在会中变化，一次展开的成员快照不能代表整个订阅期。

所以授权要在列表展开后逐一判断。收据至少应保留列表版本或成员摘要、展开时间、操作者和逐目标结果。对拒绝成员的回报还要防止反向泄露名单。速率限制也应覆盖展开后的总量，因为一个小请求可以制造大量通知。

策略正确，语义仍可能错误

跨域 Presence 不只要保存字段，还要保存含义。RFC 6271 举出早期网关把一个系统的“请勿打扰”映射为另一个系统的“忙碌”。这两个状态并不完全相同。PIDF 提供标准格式，但格式正确不能证明从专有系统到标准值的映射准确。

变换记录需要包含输入值、映射表版本、输出值和执行组件。空字段也要区分：原始数据不存在、策略删除、网关不认识，还是数据过期。若全部显示为空，后续调查会把四种原因误作一个事实。

策略版本与文档版本同样要区分。最新策略过滤旧文档，结果可能过时；旧策略过滤最新文档，结果可能越权。只有将两者与决策时间绑定，才能判断披露当时是否成立。

中央 Clearing House 不是最终事实源

RFC 5344 设想中央式联邦可提供网络识别、日志、多方聊天和合法拦截。它可以减少双边互联复杂度，也会聚合完整文档、规则、名单、消息和元数据。

“中央有日志”并不等于日志完整。它可能只记录进入 hub 的请求，不记录目标域拒绝；可能去重重试，丢失时序；可能记录列表地址，不记录展开成员；可能把对端服务器接受写成用户收到。日志必须声明覆盖范围、时钟、排序、事务标识、保留和访问策略。

更可靠的做法是对账：源网络记录发送，hub 记录接受、展开和变换，目标网络记录接收与处置，客户端在可行时提供独立事件。三方数量不一致时，用重试、过期、去重和策略拒绝解释，而不是默认中央记录天然正确。

消息“成功”也有层级

RFC 5344 同时列出 pager-mode SIP MESSAGE 和会话式 MSRP。它们不是同一种交付模型。SIP 响应能证明某个协议组件对请求作出处理，不能证明目标用户阅读。MSRP 有会话和自己的事务、报告语义，也不能自动推出业务结果。

仪表盘应分别显示：发送到对端、对端服务接受、分发到设备、客户端处理、显示或确认、用户回应。Presence 也应分别显示发布、订阅接受、视图生成、NOTIFY 发送和客户端呈现。缺失的层级保持未知，不能被“联邦链路正常”填成成功。

证据边界

这些来源说明 IETF 文档的模型、要求和机制，不证明任何具名产品、联邦、网络或账户目前如何运行。本文的故障情景是架构测试，不是已报告事件。RFC 5344 属于信息性文档，并明确没有给出安全解决方案。

标准能帮助界定应当分别测量的事实；部署是否做到，必须由实际收据回答。