Calendar Availability
updates
Extracted elements (28)
The CALDAV:calendar-availability Inbox property holds a single VAVAILABILITY component for simple cases, while more complex scenarios (multiple overlapping rules) are handled by storing multiple VAVAILABILITY components directly in the user's calendar collections. This two-tier approach avoids a single-property schema that would be too restrictive for complex availability patterns.
The existing VFREEBUSY component was insufficient because it can only represent fixed busy-time periods and lacks support for repeating patterns. VAVAILABILITY was designed to express recurring available or unavailable windows (e.g., standard office hours) that integrate naturally into free-busy lookups without requiring generation of a large set of VFREEBUSY instances.
VAVAILABILITY uses the PRIORITY property (0=lowest/undefined, 1=highest, 9=lowest explicit) to allow higher-priority components to override lower-priority ones without modifying the base availability. This enables a 'default' schedule (priority 0) to be temporarily overridden (e.g., for travel) by a higher-priority component covering the exception period.
RFC 7953 does not define how VAVAILABILITY components are used in iTIP scheduling messages. Future specifications are expected to define iTIP use of VAVAILABILITY.
A CalDAV server MUST advertise support for VAVAILABILITY components in the CALDAV:supported-calendar-component-set property on calendars that allow storing such components.
A CalDAV server MUST support CALDAV:free-busy-query REPORTs that aggregate information from any VAVAILABILITY components in the targeted calendar collections, following the procedure in Section 5.
A CalDAV server supporting VAVAILABILITY MUST advertise support by including 'calendar-availability' as a token in the DAV response header returned by an OPTIONS request.
CalDAV servers MUST limit the complexity of VAVAILABILITY data stored by a client, particularly for components with multiple overlapping time ranges, to prevent resource exhaustion from expensive availability calculations.
DTSTAMP and UID are REQUIRED in VAVAILABILITY components and MUST NOT occur more than once.
During CalDAV iTIP free-busy request processing, VAVAILABILITY components from all contributing calendar collections AND from the CALDAV:calendar-availability property on the targeted user's Inbox MUST all be included in the free-busy calculation.
In both VAVAILABILITY and AVAILABLE components, DTEND and DURATION MUST NOT occur together in the same component. DURATION MUST NOT be present if DTSTART is absent.
Support for the CALDAV:calendar-availability property is REQUIRED if the CalDAV calendar-auto-schedule feature is supported. The server MUST use the VAVAILABILITY component in this property when determining free-busy information for an iTIP free-busy request.
The iCalendar object containing a VAVAILABILITY component MUST include appropriate VTIMEZONE components for each unique TZID parameter used in any DATE-TIME property across all components, unless RFC 7809 (timezones by reference) is in effect.
To avoid having to readjust PRIORITY values when inserting new override components between existing ones, priority values SHOULD be spaced out over the full range of 1–9 rather than assigned consecutively.
When two or more VAVAILABILITY components with the same PRIORITY overlap, the effective busy type follows the precedence order BUSY > BUSY-UNAVAILABLE > BUSY-TENTATIVE. An absent PRIORITY property or a value of 0 implies the lowest priority.
Within a VAVAILABILITY or AVAILABLE component, DTSTART and DTEND MUST be DATE-TIME values expressed as either UTC or local time with a timezone reference (TZID). DATE-only values are not permitted.
Free-busy and availability information can be used to infer a calendar user's whereabouts or activity level. Any calendar system exposing free-busy or availability information MUST limit access to that information to only authorized users.
iCalendar VFREEBUSY information generated from VAVAILABILITY components MUST NOT include anything other than busy or free time periods; user-specified property values such as SUMMARY, LOCATION, and DESCRIPTION MUST NOT be copied into the free-busy result.
When VAVAILABILITY components are shared with other users, calendaring systems MUST provide a mechanism to remove nonessential properties (e.g., SUMMARY, LOCATION, DESCRIPTION) before sharing, since recipients may not need or should not see that detail.
The AVAILABLE subcomponent is nested inside VAVAILABILITY and marks periods of free time within the enclosing component's range. It REQUIRES DTSTAMP, DTSTART, and UID, and supports recurrence properties (RRULE, RDATE, EXDATE, RECURRENCE-ID) to express repeating availability.
The BUSYTYPE property specifies the default busy-time type for a VAVAILABILITY component. Valid values are BUSY, BUSY-UNAVAILABLE, and BUSY-TENTATIVE; the FREE value is not permitted. If omitted, the default is BUSY-UNAVAILABLE.
The CALDAV:calendar-availability WebDAV property (namespace urn:ietf:params:xml:ns:caldav) is defined on a CalDAV scheduling Inbox collection. Its value MUST be a valid iCalendar object containing exactly one VAVAILABILITY component and optionally VTIMEZONE components; no other iCalendar components are permitted.
The VAVAILABILITY component is a new iCalendar component that groups available-time subcomponents over a specific time range. Time covered by VAVAILABILITY is busy by default (using the BUSYTYPE value, defaulting to BUSY-UNAVAILABLE), except for periods marked free by enclosed AVAILABLE subcomponents.
Time-range filtering for VAVAILABILITY in CalDAV queries uses overlap conditions based on the presence of DTSTART, DTEND, and DURATION: e.g., if both DTSTART and DTEND are present the overlap condition is (start < DTEND AND end > DTSTART); if neither DTSTART nor DTEND is present the condition is always TRUE (unbounded component).
One new iCalendar property is registered in the iCalendar Properties Registry (RFC 5545, Section 8.3.2): BUSYTYPE, with status 'Current' and reference RFC 7953 Section 3.2.
Two new iCalendar components are registered in the iCalendar Components Registry (RFC 5545, Section 8.3.1): VAVAILABILITY and AVAILABLE, both with status 'Current' and reference RFC 7953 Section 3.1.
An attacker able to inject availability information into a calendar user's data could cause the user to always appear busy or free at inappropriate times. Calendar systems MUST ensure that availability information can only be modified by authorized users.
Free-busy calculation proceeds in four steps: (1) mark the entire requested period FREE; (2) for each VAVAILABILITY ordered by PRIORITY low-to-high, mark its covered range BUSY (using BUSYTYPE) unless overridden by a higher-priority component; (3) for each un-ignored VAVAILABILITY, expand AVAILABLE subcomponent recurrences and mark corresponding slots FREE; (4) overlay VEVENT and VFREEBUSY components using normal free-busy processing.