A recurring calendar component and all its recurrence exceptions are stored as a single calendar object resource rather than as separate resources per instance. This avoids problems of instance limits, sync consistency, and linkage between exceptions and the master component, and reduces data transfer.

Calendar collections are not allowed to be nested within other calendar collections. This simplifies client handling by ensuring a flat structure where all calendar object resources in a calendar are at the same depth.

MKCALENDAR support is RECOMMENDED rather than REQUIRED because some calendar stores support only one calendar per user, which is pre-created at account provisioning time. Servers and clients are strongly encouraged to support it when possible.

Servers MUST support the use of non-standard iCalendar components, properties, and parameters (those with "X-" prefix) in calendar object resources stored via PUT and in CALDAV:calendar-data elements of REPORT requests. Servers MAY reject such names in filter elements and MUST return a CALDAV:supported-filter precondition error if they cannot query on them.

When the stored calendar object resource differs from the submitted one by octet equality (e.g., server normalizes data), a strong ETag MUST NOT be returned in the PUT response, requiring clients to re-fetch the resource and its ETag before making further changes.

http

A CalDAV server MUST support iCalendar as a media type for calendar object resources, WebDAV Class 1, WebDAV ACL with the CALDAV:read-free-busy privilege, transport over TLS, ETags, and all calendaring reports defined in Section 7.

http, security

A server supporting CalDAV MUST include "calendar-access" as a field in the DAV response header from an OPTIONS request on any resource that supports any calendar properties, reports, method, or privilege. This value MUST indicate that all MUST-level requirements are supported.

http

CalDAV servers are REQUIRED to support the "i;ascii-casemap" and "i;octet" collations for text matching in reports. Servers MUST advertise supported collations via the CALDAV:supported-collation-set property, and clients MUST only use advertised collations.

Calendar collections MUST only contain calendar object resources and non-calendar collections as top-level resources. Nesting of calendar collections within other calendar collections at any depth is not allowed.

Calendar object resources contained in calendar collections MUST NOT contain more than one type of calendar component (e.g., VEVENT, VTODO), with the exception of VTIMEZONE components, which MUST be specified for each unique TZID parameter value.

Calendar object resources MUST NOT specify the iCalendar METHOD property.

New calendar object resources MUST be created with a PUT request targeted at an unmapped URI. Clients SHOULD use the HTTP "If-None-Match: *" request header on the PUT request when creating a new non-collection resource to avoid overwriting an existing resource.

http

Servers MUST expand recurring components to determine whether any recurrence instances overlap a specified time range when time range filtering is used in reports.

The DAV:getetag property MUST be defined and set to a strong entity tag on all calendar object resources. A response to a GET on a calendar object resource MUST contain an ETag response header field.

http

The UID property value of calendar components in a calendar object resource MUST be unique in the scope of the calendar collection. Components with the same UID MUST be contained in the same calendar object resource.

When a method precondition or postcondition is not satisfied, the response status MUST be 403 (Forbidden) or 409 (Conflict), and the appropriate XML element MUST be returned as the child of a top-level DAV:error element in the response body.

http

XML elements defined by individual implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav" namespace; they should use a namespace they control. Processing of XML by CalDAV clients and servers MUST follow the rules in RFC 2518 Section 14.

The CALDAV:calendar-home-set property on a principal resource identifies the URL of WebDAV collections containing calendar collections owned by that principal. This property SHOULD be defined on a principal resource.

The CALDAV:calendar-multiget REPORT retrieves specific calendar object resources by URL, returning their WebDAV properties and calendar data. It allows bulk retrieval without requiring a search filter.

http

The CALDAV:calendar-query REPORT searches for calendar object resources matching a specified filter and returns WebDAV properties and/or calendar data. Support is REQUIRED on all calendar collections and calendar object resources.

http

The CALDAV:calendar-timezone property on a calendar collection specifies the time zone the server uses to resolve floating date and date-with-local-time values to UTC for REPORT processing and free-busy computation. It SHOULD be defined on all calendar collections.

The CALDAV:free-busy-query REPORT returns VFREEBUSY iCalendar data for a given time range. Access is controlled by the CALDAV:read-free-busy privilege, allowing free-busy exposure without revealing event details.

http, privacy

The CALDAV:read-free-busy privilege controls which resources are examined during a free-busy-query REPORT. It MUST be aggregated in the DAV:read privilege, and servers MUST allow it to be granted independently of DAV:read.

security, privacy

The CALDAV:supported-calendar-component-set property, if present, restricts the calendar component types allowed in a collection. It MUST be protected; clients may initialize it via MKCALENDAR but cannot modify it via PROPPATCH.

The MKCALENDAR method creates a new calendar collection resource. Support is RECOMMENDED but not REQUIRED because some servers support only one calendar per user. If a MKCALENDAR request fails, the server state preceding the request MUST be restored.

http

This document registers the XML namespace "urn:ietf:params:xml:ns:caldav" for use by all XML elements defined in this specification, its revisions, and related CalDAV specifications.

registry

CalDAV inherits all security considerations from WebDAV and requires TLS (RFC 2818) for transport. Access control is enforced via WebDAV ACL (RFC 3744); the CALDAV:read-free-busy privilege allows limited free-busy disclosure without exposing full event details, supporting a privacy-preserving sharing model.

security, privacy

The CALDAV:calendar-data XML element carries iCalendar data in REPORT responses and requests. In requests it specifies which components and properties to return; it supports CALDAV:expand (expand recurrences), CALDAV:limit-recurrence-set, and CALDAV:limit-freebusy-set child elements.

The CALDAV:filter XML element contains a CALDAV:comp-filter hierarchy used in calendar-query REPORTs. It supports CALDAV:prop-filter and CALDAV:param-filter children, as well as CALDAV:time-range and CALDAV:text-match for matching criteria.

The CALDAV:mkcalendar XML element wraps a DAV:set instruction as the request body for MKCALENDAR; the response body, if present, MUST be a CALDAV:mkcalendar-response element. The response MUST include a Cache-Control:no-cache header.

http