Scheduling Extensions to CalDAV
Extracted elements (30)
This specification adopts 'implicit scheduling': the server is responsible for sending and processing all scheduling messages on behalf of clients. A client simply creates, modifies, or deletes a calendar component and the server derives and dispatches the appropriate iTIP operations (REQUEST, REPLY, CANCEL, ADD), removing the need for client-driven iTIP.
This specification defines scheduling only within a single CalDAV server's user base. Cross-server scheduling is out of scope, but the protocol is designed to be compatible with servers that use iMIP (RFC 6047) for exchanging scheduling messages with external users via email.
Servers MUST allow Attendees to make exactly eleven categories of iCalendar changes including: their own PARTSTAT, TRANSP, PERCENT-COMPLETE, COMPLETED, VALARM, CALSCALE, PRODID, EXDATE (removing instances), DTSTAMP/CREATED/LAST-MODIFIED, SCHEDULE-STATUS on CLIENT-agent attendees, and adding overridden recurrence components. All other modifications MUST be rejected with CALDAV:allowed-attendee-scheduling-object-change (403).
Servers MUST automatically process incoming scheduling messages using iTIP (RFC 5546) rules, creating or updating scheduling object resources on the Inbox owner's calendars. The scheduling message is additionally retained in the Inbox collection so the client can acknowledge it.
Servers MUST automatically resolve conflicts with inconsequential scheduling changes when If-Schedule-Tag-Match is present: if the header value matches the current CALDAV:schedule-tag, the server MUST merge any ATTENDEE property changes for other attendees into the submitted resource. If the values do not match, the server MUST return 412 Precondition Failed.
Servers MUST ensure that Attendees only receive scheduling message content for recurrence instances in which they are explicitly listed as an Attendee. When an Attendee is excluded from an instance, that exclusion is communicated via an EXDATE in the master component rather than inclusion of the overridden instance.
Support for the CALDAV:calendar-user-address-set property is REQUIRED on principal resources. It maps calendar user addresses (e.g., mailto: URIs) to principal resources and their associated scheduling collections. If absent, the calendar user is not enabled for scheduling.
When an Attendee modifies a scheduling object resource and changes PARTSTAT values on any component, or adds an EXDATE to effectively decline a recurrence instance, the server MUST deliver an iTIP REPLY to the Organizer reflecting the updated participation status.
When an Organizer creates a scheduling object resource, the server MUST inspect each ATTENDEE property and send an iTIP REQUEST to every attendee whose SCHEDULE-AGENT is SERVER (the default). The server MUST add or update SCHEDULE-STATUS parameters on each ATTENDEE property to reflect delivery status, and MUST NOT set SCHEDULE-STATUS on attendees for which no delivery was attempted.
When an Organizer modifies a scheduling object resource, the server MUST compare original and modified ATTENDEE properties per-instance and dispatch iTIP messages according to a defined transition table: moving to SERVER triggers REQUEST or ADD; removing a SERVER attendee triggers CANCEL; switching to CLIENT or NONE also triggers CANCEL.
When processing an Attendee reply, the server MUST update the PARTSTAT of each matching ATTENDEE property in the Organizer's scheduling object resource and MUST set or add the SCHEDULE-STATUS parameter to the reply's REQUEST-STATUS value (defaulting to '2.0' if absent).
Freebusy data is sensitive personal information. Access is controlled by the CALDAV:schedule-query-freebusy privilege on the target's Inbox. Servers MUST check this privilege before returning or disclosing any busy time data to the requesting calendar user.
CALDAV:calendar-user-type is an optional WebDAV property on principal resources that carries the same values as the iCalendar CUTYPE parameter (e.g., INDIVIDUAL, ROOM, GROUP). Clients use it to filter principal-property-search results by user type.
CALDAV:schedule-default-calendar-URL is a WebDAV property on the scheduling Inbox collection that specifies the calendar collection into which new scheduling object resources are automatically placed. Servers MUST reject deletion of the calendar collection referenced by this property.
CALDAV:schedule-inbox-URL is a WebDAV property on principal resources that identifies the URL of the principal's Scheduling Inbox collection. If absent, the calendar user is not enabled for reception of scheduling messages on the server.
CALDAV:schedule-outbox-URL is a WebDAV property on principal resources that identifies the URL of the principal's Scheduling Outbox collection. If absent, the calendar user is not enabled for sending scheduling messages on the server.
Freebusy information is requested by POSTing a VFREEBUSY/METHOD:REQUEST iCalendar object to the Organizer's scheduling Outbox. The response is an XML document rooted at CALDAV:schedule-response containing one CALDAV:response per requested calendar user, each with delivery status and optionally a VFREEBUSY component.
New scheduling ACL privileges on Inbox collections: CALDAV:schedule-deliver (aggregate), CALDAV:schedule-deliver-invite (controls Organizer request delivery), CALDAV:schedule-deliver-reply (controls Attendee reply delivery), and CALDAV:schedule-query-freebusy (controls freebusy queries). Corresponding Outbox privileges mirror these for send-side control.
SCHEDULE-FORCE-SEND iCalendar property parameter forces the server to send a scheduling message even when it would not normally do so (e.g., allowing an Organizer to re-invite an Attendee who previously declined, without modifying the event itself).
SCHEDULE-STATUS delivery codes are carried as an iCalendar property parameter: 1.0 (pending), 1.1 (sent, delivery unknown — typical for iMIP), 1.2 (delivered), 3.7 (unrecognized calendar user address), 3.8 (insufficient privileges), 5.1 (temporary failure, retry possible), 5.2 (permanent routing failure), 5.3 (scheduling rejected permanently).
The CALDAV:schedule-tag WebDAV property, the Schedule-Tag HTTP response header, and the If-Schedule-Tag-Match HTTP request header form a conflict-avoidance mechanism. The schedule-tag value is intentionally NOT changed when a resource is updated solely as a result of processing an Attendee reply (an 'inconsequential' change), letting clients detect and merge such changes safely.
The SCHEDULE-AGENT iCalendar property parameter on ATTENDEE or ORGANIZER properties controls who handles scheduling message delivery: SERVER (default — the CalDAV server delivers), CLIENT (the client handles delivery itself), or NONE (no scheduling messages sent). It governs which iTIP method the server sends for each operation.
The Schedule-Reply HTTP request header (values: T or F) lets an Attendee suppress the iTIP REPLY when deleting a scheduling object resource. If omitted or set to T, the server sends a REPLY; if set to F, no reply is sent, enabling silent removal.
The Scheduling Inbox Collection holds copies of incoming scheduling messages from Organizers and Attendee replies. It MUST report DAV:collection and CALDAV:schedule-inbox in its DAV:resourcetype, MUST NOT contain sub-collections, and MUST NOT be a child of a calendar collection. UID uniqueness constraints from RFC 4791 do not apply here.
The Scheduling Outbox Collection is used as the target for freebusy requests (via POST) and to manage outgoing scheduling privileges. It MUST report DAV:collection and CALDAV:schedule-outbox in its DAV:resourcetype property, and MUST NOT be a child of any calendar collection.
Three new HTTP message header fields are registered with IANA: Schedule-Reply (request header, controls reply suppression), Schedule-Tag (response header, opaque scheduling resource version token), and If-Schedule-Tag-Match (request header, conditional scheduling tag precondition).
Three new iCalendar property parameters are registered: SCHEDULE-AGENT, SCHEDULE-FORCE-SEND, and SCHEDULE-STATUS. Three new iTIP REQUEST-STATUS codes are registered: 1.0 (Pending), 1.1 (Sent), 1.2 (Delivered). Two new IANA registries are created: Schedule Agent Values (SERVER, CLIENT, NONE) and Schedule Force Send Values (REQUEST, REPLY).
Servers MUST verify that the ORGANIZER property value in any scheduling message or freebusy request matches an authenticated calendar user address of the submitting principal, to prevent spoofing. For freebusy POSTs, the ORGANIZER must match the owner of the targeted Outbox collection.
Servers should guard against DoS attacks by limiting the number of Attendees per scheduling message and the rate of scheduling messages. Large recurring events with many attendees can generate substantial server-side processing and message traffic on each modification.
The server MUST reset the PARTSTAT of all non-Organizer ATTENDEEs to NEEDS-ACTION whenever a reschedule occurs. A reschedule is triggered by any change to DTSTART, DTEND, DURATION, or DUE; by RRULE or RDATE changes that add new instances or shift existing ones; or by EXDATE removal that reinstates instances.