摘要

  • 在 AUTOMATIC-FAILURE 下，一位参与者的 PARTSTAT=FAILED 或未完成任务逾期，都可能把组织者副本中的整体 VTODO 状态改为 FAILED。
  • SERVER 把状态选择交给各实现的业务规则；CalDAV 可公布支持模式，并以 HTTP 403 拒绝未支持的模式。

这不是只有日历里的期限在起作用。RFC 10051 预期 iTIP 请求中的每位 ATTENDEE 都执行这项任务；但 AUTOMATIC-FAILURE 把单个参与者的失败状态转成整个 VTODO 的失败状态。系统把个人回复写进了共享工作的总账。

另一种信号来自时钟：任务未完成且有效截止时间已过，服务器也应将其标为 FAILED。截止时间取自 DUE，或 DTSTART 加 DURATION。VSTATUS 可以记录变更原因、子状态和时间戳；只有顶层状态时，后续读者只能看到结论，找不到缘由。

2026 年 10 月发布的 RFC 10051 更新 iCalendar 的 VTODO，覆盖项目任务和工作流，也包括个人提醒。属性 TASK-MODE 指定状态变更方式；缺省时按 CLIENT 处理，服务器保留客户端提交的状态。其他模式将部分决定交给服务器。

在 AUTOMATIC-COMPLETION 下，所有参与者报告完成后，服务器应将任务改为完成状态；该模式中的失败由客户端处理。AUTOMATIC 合并完成和失败两种自动行为。

SERVER 模式把空间留给各实现：服务器在收到回复或截止时间到达时，根据自己定义的业务规则选择状态。RFC 10051 没有规定宽限期、部分完成怎么判、重试几次，或未解决依赖应如何处理。同一条任务记录进入两套服务，可能得到不同结论。

CalDAV 给客户端提供了一种查看边界的办法。服务器可以通过 CALDAV:supported-task-mode-set 公布支持的模式。客户端若尝试保存服务器不支持的模式，服务器必须返回 HTTP 403，并用 DAV 错误列出可用模式。遇到不认识的 TASK-MODE，客户端应安全忽略。

这个公布的模式集合是客户端可用的证据；若要确认某项服务是否具备该能力，需要查看它当前返回的支持列表。

新标准还把截止窗口和工作量估计分开。DTSTART 与 DUE，或 DTSTART 与 DURATION，定义可工作的时间窗口；ESTIMATED-DURATION 表示预计耗时。一次预计两小时的维修可以放进四小时的处理窗口里，任务本身不必被写成“四小时工作”。

对运维团队而言，FAILED 只是记录的一部分。触发转换的模式、截止时间的计算方式、参与者回复，以及 VSTATUS 中的原因、子状态和时间戳，同样决定这条记录能否被复核。状态能随任务在系统间流动，产生状态的政策却可能留在原地。

来源