摘要

  • 在 Jonathan Rosenberg 参与建立的在线状态模型中，OPEN 对即时消息有一个很窄的含义：相关收件箱已经准备好接受消息。它不证明人的位置、身份、注意力、沟通意愿或回复。
  • PIDF 可以同时包含多个 tuple，甚至允许同一 contact 一个为 OPEN、另一个为 CLOSED。RFC 4479 因而把人、服务和设备分开，让属性归属于它所描述的对象，而不是简单归属于上报它的设备。
  • 可审计的系统应分别保存订阅授权、通知、tuple 来源、服务状态、设备活动、消息接收与交付、显示、阅读和回应。绿点可以是有用提示，但不能替它没有观察过的人作证。

绿点把主语省略了

某个协作系统显示三名同事，其中一人是绿色。调度程序于是把紧急任务交给他。消息服务返回接收成功，二十分钟后仍没有回复。复盘报告写下：“在线人员未及时响应。”

这句话至少跨过了三道没有证据的门槛。绿色可能只来自某个服务 tuple 的 OPEN；接收成功只说明服务入口收下消息；没有回复则只说明结果未出现。至于人是否在电脑旁、是否看见通知、是否正在另一台设备上工作，记录都没有回答。

在线状态标准的价值，并不是把这些不确定性变成一个万能判断。它的价值是给不同对象和不同阶段取了不同名字。问题在于，产品界面常把这些名字压扁成一个“可用”。

最初的 OPEN 指向收件箱

RFC 2778 由 Mark Day、Jonathan Rosenberg 与 Hiroyasu Sugano 共同撰写，是一份信息性模型。它建立共同词汇，而不是独自规定一个互操作协议。模型区分发布状态的 presentity、分发信息的 presence service、接收信息的 watcher、即时消息服务、发送方和 instant inbox。

在即时消息语境中，OPEN 的定义是：相关地址对应的 instant inbox 已准备好接受一条即时消息。CLOSED 则表示该收件箱不能接受。对于其他通信方式，文档只允许存在类似含义，并没有代为定义。

这个定义的主语是收件箱。它没有声称某个人物理在场，也没有声称人刚刚操作过设备、认得发送者、愿意被打断或保证回答。即便“准备接受”随后变成“服务已经接受”，也还没有证明消息被持久保存、送达终端、显示在前台或被阅读。

因此，把协议值直接存成 person_available=true 并不是格式转换，而是语义扩张。新增的判断来自界面或业务规则，必须由它们承担责任。

一个 PIDF 文档可以同时保留分歧

RFC 3863 定义 Presence Information Data Format。PIDF 文档可以包含多个 tuple。每个 tuple 有状态，还可以带 contact、时间戳、注释和扩展。基础状态只有 open 与 closed。

多个 tuple 并非冗余。它们可能来自不同设备、同一设备上的不同应用，或不同时间生成的数据。标准甚至明确允许：两个 tuple 带着同一 contact，却一个 OPEN、一个 CLOSED。

遇到这种情况，watcher 需要自己的解释规则。它要知道哪个 tuple 发生了变化、来源是谁、时间戳是否可比、组合器采用什么政策，以及之后的通知是否取代了此前状态。标准没有授权界面挑选更好看的那一个，再称之为“人的真实状态”。

tuple 的 id 只用于在同一 presentity 内区分和关联 tuple。RFC 3863 说明它是任意字符串，没有更广的意义。它不是人的身份标识，也不是设备证书。若把它提升为跨系统的人物主键，系统就在凭空增加权威。

只保存最终颜色，会让所有这些差异消失。至少应留下订阅、通知序号、tuple ID、组件类型、contact、原始值、发布与接收时间、来源和组合规则版本。这样，“当前绿色”仍可被重新解释，而不是覆盖证据。

获准观看，不等于看见了一个人

Rosenberg 独立撰写的 RFC 3856 用 SIP 的 SUBSCRIBE 与 NOTIFY 承载在线状态。presence agent 必须认证订阅请求，之后再做授权决定。订阅可能成功、被拒或处于等待；通知还要同时表达订阅状态与 presentity 状态。

这里至少有四个不同问题：watcher 是谁；它可以看到什么；观察关系是否有效；所披露的状态是什么。认证 watcher 并不会认证状态中所描述的那个人。授权访问也不会证明那个人在场。收到 NOTIFY 只证明状态信息到达 watcher，不证明信息来自对人的直接观察。

隐私政策还会改变可见范围。设备活动字段缺失，可能是发布者不愿披露，而不是设备空闲。订阅终止，可能是观察权限被撤销，而不是所有服务下线。把“看不到”渲染成“人离线”，会将隐私选择反向变成对人的判断。

RFC 4479 给事实分了三类

Jonathan Rosenberg 撰写的 RFC 4479 把 presentity 分成人、服务和设备三个组件。核心规则不是“谁上报，属性就属于谁”，而是“属性描述什么，就属于什么”。

手机可以上报用户正在开会，但“开会”描述的是人，应放在 person 组件。电池电量描述设备。可供联系的即时消息、电话或短信入口描述服务。测量来源与语义对象是两列不同的数据。

这套类型边界拦住了常见推断。设备开机不保证服务可用；服务 OPEN 不保证人愿意沟通；设备位置不必等于人的位置。RFC 4479 明确指出，人和设备都可以有位置，而且两者可以不同。

它对“人”这个名称也十分克制。person 组件只是单个人的模型外观，系统无法验证背后真的是一名人类，还是一群人甚至别的参与者。一个多人值守的服务台也可以被建模成一个 person。presence URI 是协调用的句柄，不是生物身份凭证。

分开并不会妨碍汇总。产品仍可把服务开放、设备活动和人员声明组合成一个建议，但原始类型必须留下。出现偏差时，团队才知道应检查收件服务、设备采集、隐私政策还是人员层面的信息。

活动记录只能改善估计

RFC 4480 由 Henning Schulzrinne、Vijay Gurbani、Paul Kyzivat 与 Rosenberg 共同撰写，为 PIDF 增加丰富状态。user-input 可以依据一个可配置阈值报告 active 或 idle。采集范围可能只是一款应用，也可能覆盖整个设备；最后输入时间还可以被省略。

这份标准给出一个关键边界：很久没有被使用的 tuple 仍可能保持 OPEN。watcher 可以优先选择既开放、近期又有活动的 URI，用两项证据估计用户更可能回应。

“更可能”不是“已经证明”。活动可能发生在另一个窗口，自动程序也可能制造输入；人可以读到信息却没有触发所观察的动作，也可以在输入时完全没注意到那条消息。不同阈值产生的 active 也不能直接比较。

好的界面不必隐藏复杂性。它可以分别写“服务可接收消息”和“十分钟内观察到设备活动”。这比一个含义不明的绿色更利于决策。

对 Rosenberg 的归属也要保持边界

截至 2026 年 9 月 9 日，IETF Datatracker 上 Jonathan Rosenberg 的公开档案列出 72 份 RFC，并显示当时没有活跃职务。RFC 3856 与 RFC 4479 只列他一名作者；RFC 2778 与 RFC 4480 则是多人合作。档案证明长期标准贡献，不证明他控制 IETF 共识、任何具体产品或用户行为。

Five9 的官方作者页面和公开头像用于建立配图的身份来源。页面上的旧人物简介不被用来断言当前职位。图片来源和任职时效是两种不同的证据，不能互相替代。

把每个动词写成自己的记录

一次完整判断可以拆成：watcher 已通过认证；watcher 获得某一范围的授权；通知已到达；某个服务 tuple 发布 OPEN；设备近期有输入；消息服务已接受；客户端已收到并显示；人已阅读；人已回复。

现实中经常缺少其中几项。缺少就应保持未知。“服务开放，消息已接收，阅读未知，尚无回复”仍能支持排障。“在线的人拒绝回应”则把空白写成动机。

绿点并没有失去用途。它只需要把被省略的主语补回来：开放的是服务，不是一个由协议直接观察的人。

来源