摘要

  • PARTSTAT=ACCEPTED 表示某个日历用户地址在排期对象中的参与状态，不是对会议发生时本人行为的观测。
  • 要判断出席，必须把回复人、代理关系、事件版本、重复实例、投递结果与现场信号分别记录。

一份“参会率”报表最容易在数据准备阶段犯错：工程师从日历导出 ACCEPTED，把列名改成“已出席”，再按部门汇总。查询没有报错，数字也很整齐，但结论在改列名的那一刻已经越过了证据边界。

RFC 5545 把 PARTSTAT 定义为日历用户的参与状态。对事件而言，常见值包括 NEEDS-ACTION、ACCEPTED、DECLINED、TENTATIVE 与 DELEGATED。它们解决的是邀约如何协同：尚未答复、接受、拒绝、暂定或委托他人。标准没有声称这些值可以感知门禁、视频会议连接或人的注意力。

为什么要从 Cyrus Daboo 讲起

Cyrus Daboo 的标准工作恰好跨越了这条状态链。他是 CalDAV（RFC 4791）的作者之一，也是 iTIP（RFC 5546）的作者，并与 Bernard Desruisseaux 共同撰写了 CalDAV Scheduling（RFC 6638）。他的 IETF 资料页在本次研究快照中列出 26 篇 RFC；CalConnect 2013 年的服务奖说明则记录了他在 CalDAV 和日历互操作领域的历史贡献。

这里不能把 RFC 5545 也归到 Daboo 名下；该文作者是 Bernard Desruisseaux。Daboo 的关键作用在于 RFC 5546 和 RFC 6638 把用户回复、组织者主对象与服务器处理串了起来，同时没有把它们混成一个事实。

“接受”由谁控制

在 iTIP 模型中，组织者控制排期对象的主版本。创建邀约时，组织者通常把参与者设为 NEEDS-ACTION。参与者在自己的 ATTENDEE 属性上修改 PARTSTAT，通过 REPLY 发回；随后，组织者一侧将回复纳入主对象。事件整体的 STATUS 与每位参与者的 PARTSTAT 是不同变量，控制者也不同。

所以，组织者日历中的 ACCEPTED 能支持一个有限而有用的说法：在该主对象的当前记录里，这个参与者地址带有接受状态。它没有自动回答是谁操作客户端，也没有预言会议开始后的行为。

地址、代答者和实际到场者可以不同

RFC 5546 明确考虑委托。受邀者可以把出席权交给另一位日历用户；SENT-BY 则表示某个日历用户代表指定的参与者或组织者作出回复。行政助理、共享邮箱、自动化代理或受委托同事参与回复，都可能是合规流程的一部分。

因此至少要保留三种身份：邀约写给谁、回复由谁发起、最后由谁出席。若系统只保存“某某接受”，就不是把数据变简洁，而是删掉了判断责任归属所需的字段。

接受状态还有版本和实例范围

会议会改期。RFC 5546 用 SEQUENCE 表示组织者对事件的修订，并规定 REPLY 不增加这个序号。回复携带的序号说明参与者回答的是哪一版。时间、地点或议程发生实质变化后，旧接受不能自然升级为对新版本的承诺。

重复事件更容易暴露误判。一整组会议可以有总体接受状态，同时某个由 RECURRENCE-ID 标识的实例被拒绝、移动或取消。把系列级 ACCEPTED 批量展开到每一次会议，就会凭空生成逐场出席记录。

CalDAV 服务器处理的是排期，不是人

RFC 6638 所说的“隐式排期”允许服务器在排期对象被保存、修改或删除时自动发送必要消息。收到参与者的 REPLY 后，服务器可以在组织者资源中更新相应 PARTSTAT；SCHEDULE-STATUS 可以记录排期消息的投递或处理结果。排期代理还可能是 SERVER、CLIENT 或 NONE。

这些记录非常适合排查“邀请为何没到”或“回复是否被纳入”。但服务器成功处理，不能证明人看见了邀请；消息成功投递，更不能证明人进入了会议。把机器完成的状态迁移记到人的行为账上，会在事件发生之前就制造错误归因。

出席需要另一套证据合同

安全清点、法定人数、认证培训或计费会议确实可能需要出席记录。此时应另行定义观测方法及其误差。门禁卡可能被代刷，在线连接可能无人值守，主持人点名也可能漏记。每一种来源只能证明它真正测量到的信号。

最小可用的证据账本应分列保存：受邀地址、回复值、实际回复人或代理、SEQUENCE、重复实例范围、排期投递状态、事件期间的观测信号、观测方法、时间窗、例外与申诉。ACCEPTED 只能进入“邀约回复”列。没有采集出席信号时，“事件观测”列就应留空。

空白不是数据质量事故。它准确表达了系统不知道什么。