要約

  • AUTOMATIC-FAILUREでは一人のPARTSTAT=FAILED、または未完了のままの期限超過で、オーガナイザー側のVTODO全体がFAILEDになりうる。
  • SERVERは実装ごとの業務ルールに状態を委ねる。CalDAVは対応モードを公開でき、未対応の指定にはHTTP 403を返す。

まず二つの記録を分けて考えたい。ATTENDEEは担当者、PARTSTATはその人の返答、VTODOはタスク全体の記録だ。RFC 10051はiTIPのREQUESTに含まれる各担当者がタスクを実行する前提を置く。AUTOMATIC-FAILUREでは、一人のFAILEDがオーガナイザー側のタスク全体をFAILEDに変えうる。後続の仕組みが読むのも、個人の事情ではなく全体の結果だ。

期限も全体状態を変える。タスクが未完了のまま期限を過ぎたら、サーバーはFAILEDにすることが望ましい。期限はDUEに直接書くか、開始時刻DTSTARTに割り当てた時間DURATIONを足して求める。VSTATUSには理由や時刻を残せる。結果だけが共有される運用なら、その理由も一緒に渡さないと判断の経緯が消える。

2026年10月公開のRFC 10051は、iCalendarのVTODOを更新し、プロジェクトや業務フローのタスクを扱う。TASK-MODEを省略すると既定値はCLIENTとなり、サーバーはクライアントの状態を尊重する。自動化を選ぶと、状態を作る主体が変わる。

AUTOMATIC-COMPLETIONでは全参加者が完了を報告するとサーバーがCOMPLETEDに変えることが望ましく、失敗はクライアントが扱う。AUTOMATICは完了と失敗の両動作を含む。

SERVERはもっと広い判断を実装側に残す。返信が届いたときや期限が過ぎたときに、サーバーは自ら定めた業務ルールで状態を選ぶ。猶予期間、部分完了、再試行回数、未解決の依存関係について、RFC 10051は共通の答えを用意していない。同じタスクを別のサービスに渡せば、結果が分かれることもある。

CalDAVでは境界の一部を確認できる。サーバーはCALDAV:supported-task-mode-setで対応モードを公開できる。対応していないモードのタスクを保存しようとすると、サーバーはHTTP 403と、対応モードを示すDAVエラーを返さなければならない。TASK-MODEを認識しないクライアントは、その属性を安全に無視する。

公開されたモード一覧はクライアントが使える証拠になる。特定サービスの現行応答があれば、その機能の対応状況を確かめられる。

この更新は、作業できる時間枠と作業そのものにかかる見込み時間も分ける。DTSTARTとDUE、またはDTSTARTとDURATIONが時間枠を表し、ESTIMATED-DURATIONは作業時間の見積もりを表す。二時間の修理に四時間の完了枠を設けても、修理自体を四時間と記録する必要はない。余裕時間と作業量を混同しないための区別だ。

運用チームに必要なのはFAILEDのラベルだけではない。状態を変えたモード、期限の算出、参加者の応答、そしてVSTATUSに残る理由・サブステータス・時刻も確認したい。タスクの状態はシステム間を移動するが、その状態を生んだルールは実装ごとに残る。

出典