Summary

  • In AUTOMATIC-FAILURE, one attendee’s PARTSTAT=FAILED or an overdue incomplete task can change the Organizer’s overall VTODO status to FAILED.
  • SERVER mode hands status choices to implementation-defined business rules; CalDAV lets clients check supported modes and rejects an unsupported one with HTTP 403.

The assignment itself is shared: RFC 10051 says every ATTENDEE in an iTIP REQUEST is expected to perform the task. Yet one attendee’s PARTSTAT=FAILED can trigger a task-wide FAILED status in AUTOMATIC-FAILURE. A person-level reply becomes the record attached to the whole job.

The second trigger is a clock. When the task remains incomplete after its effective due date, the server should also set FAILED. That date comes from DUE, or from DTSTART plus DURATION. VSTATUS can retain the reason, substate and timestamp behind the change; the top-line status alone is a thin account of what happened.

Published in October 2026, RFC 10051 updates iCalendar’s VTODO component for workflow and project tasks as well as personal reminders. TASK-MODE tells the server how to handle status changes. If absent, the default is CLIENT: the server follows the status supplied by the client. AUTOMATIC-COMPLETION asks the server to mark the task complete when every attendee reports completion; a client handles failure in that mode. AUTOMATIC combines completion and failure behavior.

SERVER is the open-ended mode. It tells the server to choose an appropriate status as attendee replies arrive or deadlines pass, using business rules defined by that implementation. RFC 10051 supplies no common policy for grace periods, partial completion, retries or the meaning of an unresolved dependency. Two services can exchange the same task and still apply different SERVER-mode rules.

The standard gives clients a way to discover some of that boundary. A CalDAV server can publish its supported task modes in CALDAV:supported-task-mode-set. If a client tries to store a task with a mode the server does not support, the server must return HTTP 403 with a DAV error that identifies the supported modes. A client that does not recognize TASK-MODE is expected to ignore it gracefully.

That advertised set is the evidence a client can use; a current response from a named service would show whether it supports this behavior.

RFC 10051 also separates a deadline from an estimate. DTSTART and DUE, or DTSTART and DURATION, define the window in which work can happen. The new ESTIMATED-DURATION says how much time the task is expected to take. A two-hour repair can therefore have a four-hour completion window without pretending the work itself takes four hours.

For an operations team, the important record is not only the final FAILED label. It is the mode that authorized the transition, the due-date calculation, the attendee response and any status reason or substate recorded in VSTATUS. The label can travel between systems; the rule behind it may remain local.

Sources