Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to CalDAV.
Nothing was collected or created yet.
CalDAV
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (April 2014) |
| Communication protocol | |
| Purpose | Access remote scheduling information |
|---|---|
| Introduction | March 2007 |
| Based on | WebDAV |
| OSI layer | Application |
| Port(s) | Any |
| RFC(s) | 4791, 6638 |
Calendaring Extensions to WebDAV, or CalDAV, is an Internet standard allowing a client to access and manage calendar data along with the ability to schedule meetings with users on the same or on remote servers.[1][2] It lets multiple users in different locations share, search and synchronize calendar data.[3] It extends the WebDAV (HTTP-based protocol for data manipulation) specification and uses the iCalendar format for the calendar data.[2] The access protocol is defined by RFC 4791.[1] Extensions to CalDAV for scheduling are standardized as RFC 6638.[1] The protocol is used by many important open-source applications.[3]
History
[edit]The CalDAV specification was first published in 2003 as an Internet Draft submitted to the Internet Engineering Task Force (IETF) by Lisa Dusseault. In March 2007, the CalDAV specification was finished and published by the IETF as RFC 4791, authored by Cyrus Daboo (Apple), Bernard Desruissaux (Oracle), and Lisa Dusseault (CommerceNet). CalDAV is designed for implementation by any collaborative software, client or server, that needs to maintain, access or share collections of events. It is developed as an open standard to foster interoperability between software from different vendors.[clarification needed]
Specification
[edit]The architecture of CalDAV (partially inherited from the underlying specifications) organizes the data (events, tasks, free-busy info, notes) in directories (collections), where multiple items (resources) reside. The resources and collections can be accessed by one or more users, using standard HTTP and DAV semantics to detect conflicting changes, or to provide locking.
For access control the concept of ACLs are used, so each operation (view, edit, delete etc.) can be denied or granted per user. Therefore, the specification requires that CalDAV servers must support "WebDAV Access Control Protocol" (RFC 3744). The calendar resources must use iCalendar format, which allows the server to understand and process the data. Parsing the iCalendar items is necessary, because the server has to support a number of calendaring-specific operations such as doing free-busy time reports and expansion of recurring events. With this functionality, a user may synchronize their own calendar to a CalDAV server, and share it among multiple devices or with other users. The protocol also supports non-personal calendars, such as calendars for sites or organizations.
See also
[edit]- Exchange ActiveSync
- Calendar
- CardDAV
- iCalendar
- Scheduling OSID defines a software interface abstraction for calendaring protocols.
- SyncML
- vCalendar
- WebDAV
References
[edit]- ^ a b c "Introduction". Calconnect. Archived from the original on May 4, 2022.
- ^ a b "Glossary of Terms".
- ^ a b "Introduction to CalDAV". Linux.com. February 14, 2006.
External links
[edit]- CalDAV Resource Site
- CalConnect, The Calendaring and Scheduling Consortium
- WebDAV Resources
- Open Calendar Sharing and Scheduling with CalDAV L. Dusseault, J. Whitehead, IEEE Internet Computing 9(2)
- RFC 2616
- RFC 3744
- RFC 4791
- RFC 4918
- RFC 5545
- RFC 5546
CalDAV
View on Grokipediafrom Grokipedia
CalDAV, or Calendaring Extensions to WebDAV, is an Internet standard protocol that defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to enable clients to access, manage, and share calendaring and scheduling information on a server using the iCalendar data format.[1] It operates over HTTP, allowing for the creation, retrieval, modification, and deletion of calendar resources such as events, tasks, and free/busy information.[1] The protocol was standardized by the Internet Engineering Task Force (IETF) in RFC 4791, published in March 2007 as a Proposed Standard on the standards track.[1]
CalDAV builds directly on WebDAV (RFC 2518), incorporating its core methods like PUT, GET, COPY, MOVE, and DELETE, while adding calendar-specific elements such as the MKCALENDAR method for creating calendar collections and specialized REPORT methods for querying data.[1] Calendar data is modeled using iCalendar (RFC 2445, obsoleted by RFC 5545), with resources organized into calendar collections (containers for multiple calendar objects) and calendar object resources (individual iCalendar components like VEVENT or VTODO).[1] Key reports include the calendar-query REPORT for filtering events by time range, unique identifier (UID), or properties, and the calendar-multiget REPORT for efficient retrieval of multiple objects.[1] This design ensures interoperability between calendar clients and servers while maintaining compatibility with existing WebDAV infrastructure.[2]
The protocol's core specification in RFC 4791 focuses on calendar access and management, but it was later extended by RFC 6638 (published in 2012) to support scheduling features, such as the scheduling-outbox and scheduling-inbox collections for handling meeting invitations and responses across servers. Additional extensions appear in RFCs like 8607 (for attachments) and 7953 (for calendar availability reporting), enhancing functionality for enterprise and cross-server scenarios. CalDAV has been widely adopted in implementations by major providers, including Apple's Calendar app, Google's Workspace, and open-source servers like those from the Cyrus project, facilitating seamless calendar synchronization in diverse environments. [3]
Recurring events and tasks are handled within a single resource using
A successful response returns 201 Created status with an ETag header for concurrency control.[9]
Retrieving a calendar resource can be done via GET to fetch the full iCalendar object or PROPFIND to obtain specific properties. A GET request targets the resource's URI and returns the complete iCalendar content with an ETag. For instance, GET /home/lisa/calendars/events/event123.ics yields the VCALENDAR data. PROPFIND, applied to a resource or collection (with Depth: 1 for members), retrieves properties like DAV:displayname or CALDAV:calendar-data in a DAV:multistatus XML response, allowing efficient metadata access without full content.[40]
Modifying a calendar resource involves either updating properties with PROPPATCH or replacing the entire body with PUT. PROPPATCH targets the resource URI to set or remove WebDAV-defined or CalDAV-specific properties, such as CALDAV:calendar-description, using an XML body with set/remove instructions; it does not alter the iCalendar content. For content changes, like editing an event's SUMMARY, a PUT request overwrites the resource at its mapped URI, including an If-Match header with the current ETag to ensure safe updates. The response provides a new ETag upon success.[10]
Deletion of a calendar resource uses the DELETE method on the resource's URI, removing the iCalendar object from the collection. A successful operation returns 204 No Content. This can apply to individual events or, with appropriate collection handling, to entire sub-collections, though CalDAV emphasizes resource-level granularity.[18]
To query multiple calendar resources in a collection efficiently, clients use the CALDAV:calendar-multiget REPORT method. The request targets the collection URI with an XML body specifying the desired properties (e.g., DAV:getetag and CALDAV:calendar-data) and a list of DAV:href elements for the target resources. For example:
The server responds with 207 Multi-Status, including the requested iCalendar data and ETags for each href, optimizing bandwidth for bulk retrieval.[32]
Introduction
Definition and Purpose
CalDAV, or Calendaring Extensions to WebDAV, is an Internet standards track protocol that extends the Web Distributed Authoring and Versioning (WebDAV) protocol to enable standardized access, management, and sharing of calendaring and scheduling information over HTTP.[1] This extension builds upon WebDAV's capabilities for remote resource manipulation by incorporating specific mechanisms for handling calendar data in the iCalendar format.[1] Published in March 2007 as RFC 4791 by the Internet Engineering Task Force (IETF), CalDAV establishes a framework for interoperable calendar services without relying on vendor-specific implementations.[1] The primary purpose of CalDAV is to facilitate remote access to calendar resources, including events, tasks, and free/busy information, allowing synchronization across multiple devices and users in collaborative environments.[1] By providing a protocol for scheduling and sharing calendar data, it supports group calendaring scenarios, such as coordinating meetings, while promoting open standards to avoid proprietary lock-in.[1] This enables clients to perform operations like creating, updating, and querying calendar entries in a manner that ensures consistency and accessibility across diverse systems.[1] CalDAV operates at the application layer of the OSI model, leveraging HTTP for transport and utilizing XML for structuring requests and responses.[1] Calendar data itself is represented in the iCalendar format, which defines components such as VEVENT for events and VTODO for tasks.[1] This scope ensures that CalDAV integrates seamlessly with existing web infrastructure while focusing exclusively on calendaring extensions to WebDAV.[1]Key Features
CalDAV organizes calendars as WebDAV collections, where each calendar resource serves as a container for iCalendar objects such as VEVENT for events, VTODO for tasks, and VFREEBUSY for availability data.[4] This structure allows individual calendar items to be treated as addressable resources within the collection, enabling efficient manipulation through standard WebDAV operations like creation, retrieval, and deletion.[5] By limiting each object resource to a single component type—except for VTIMEZONE components, which can appear multiple times—CalDAV ensures a consistent and queryable data organization that supports interoperability across calendar clients.[5] A core capability of CalDAV is its support for synchronization, particularly through delta-sync mechanisms that transfer only changes rather than full datasets, thereby minimizing bandwidth usage.[6] This is achieved using reports like CALDAV:calendar-query and CALDAV:calendar-multiget, which allow clients to specify time ranges or filters to retrieve updated iCalendar objects, along with ETags for versioning to detect modifications efficiently.[7] Such features enable seamless syncing of calendars across devices without redundant data transmission, making it suitable for mobile and distributed environments.[8] CalDAV facilitates calendar sharing via access controls and HTTP methods, with core support for collaborative management extended by later specifications.[9] Servers can create shared calendars using the MKCALENDAR method, which establishes collections accessible to multiple users, while iCalendar objects can include ATTENDEE properties for indicating participants; full scheduling operations, such as sending invitations and processing responses across servers, are provided by the extensions in RFC 6638.[10] [11] This integration allows users to manage events or tasks with participant details through standard WebDAV interactions.[12] Access control in CalDAV is tightly integrated with the WebDAV Access Control Protocol (ACL) defined in RFC 3744, providing granular permission management for calendar resources.[13] Servers must support WebDAV ACLs to define privileges such as DAV:read for viewing events or CALDAV:read-free-busy for limited availability access, applied via access control entries (ACEs) to principals like users or groups.[14] [15] This model allows administrators to configure read, write, or scheduling permissions on collections and individual objects, ensuring secure sharing without exposing full calendar details.[16] Methods like the ACL PROPPATCH enable dynamic updates to these permissions.[17] The protocol's extensibility supports custom properties and additional features, such as managed attachments for iCalendar objects, as outlined in RFC 8607.[18] This allows non-standard iCalendar components or properties to be incorporated while maintaining compatibility, with attachments handled through HTTP POST operations using parameters like MANAGED-ID for identification and SIZE for octet limits.[19] Such provisions enable implementations to add specialized capabilities, like file uploads for event-related documents, without disrupting core functionality.[20]Historical Development
Origins and Standardization
CalDAV emerged in 2003 as an individual Internet Draft authored by Lisa Dusseault of Xythos Software, aimed at extending the WebDAV protocol to support calendar data access and synchronization in collaborative environments.[21] The draft, titled "Calendaring Extensions to WebDAV (CalDAV)," was motivated by the need to enable interoperable sharing of calendaring information across diverse systems, leveraging WebDAV's established framework for remote file management while addressing the limitations of prior proprietary or non-standard approaches to calendar synchronization.[21] This initiative built on earlier discussions within the IETF's CALSCH working group, where the concept of using HTTP and WebDAV for calendar access had been explored as far back as 1997 or 1998, though initial implementations by various companies suffered from interoperability issues.[1] The development of CalDAV progressed through collaborative refinement within the IETF community, with Dusseault joined by co-authors Cyrus Daboo of Apple and Bernard Desruisseaux of Oracle, reflecting input from industry stakeholders seeking standardized calendaring solutions.[1] The protocol's design focused on modeling calendar resources as WebDAV collections, incorporating iCalendar data formats to facilitate operations like querying, creating, and updating events, all while emphasizing scheduling semantics to support group coordination.[1] This evolution addressed key challenges in collaborative software, such as ensuring consistent data representation and access control across clients and servers. The standardization process culminated in RFC 4791, published in March 2007 as a Proposed Standard by the IETF, following multiple revisions of the initial draft from November 2003 onward.[1] These iterations, spanning over 15 versions by 2006, incorporated feedback from last calls, IESG evaluations, and contributions from experts in WebDAV and calendaring, refining features like report mechanisms and property handling to achieve broad applicability.[22] The final specification, authored by Daboo, Desruisseaux, and Dusseault (then affiliated with CommerceNet), established CalDAV as a foundational extension to WebDAV, enabling standardized calendar interoperability without relying on vendor-specific protocols.[1]Key Milestones and Updates
The core CalDAV protocol was formally established with the publication of RFC 4791 in March 2007, which defines extensions to WebDAV for accessing, managing, and sharing calendar data using the iCalendar format.[1] In June 2012, RFC 6638 introduced scheduling extensions to CalDAV, providing a standardized mechanism for handling calendar invitations, replies, and time zone processing to improve interoperability in group scheduling scenarios.[23] In March 2016, RFC 7809 updated CalDAV to support time zones by reference, enabling clients and servers to exchange iCalendar data using standardized time zone identifiers instead of embedding full time zone descriptions.[24] August 2016 saw the release of RFC 7953, which extended CalDAV to support calendar availability publication, allowing users to share free/busy information without revealing sensitive event details.[25] Further enhancements arrived in June 2019 with RFC 8607, enabling managed attachments for iCalendar objects in CalDAV, which facilitates the secure storage and retrieval of binary files associated with calendar events directly through the protocol.[26] No major revisions to the core CalDAV specification have occurred since 2019, though development has continued through targeted extensions addressing specific needs like availability and coordination. Ongoing efforts include the March 2025 draft for calendar subscription upgrades (draft-ietf-calext-subscription-upgrade), which proposes updates to RFC 5545 to better handle subscription mechanisms in CalDAV environments for improved client-server interactions.[27]Technical Overview
Core Protocol Components
CalDAV is built upon the Hypertext Transfer Protocol version 1.1 (HTTP/1.1), leveraging its standard methods such as GET for retrieving calendar object resources, PUT for creating or updating them, and DELETE for removal.[10] These methods enable basic resource management within calendar collections, where each calendar object is stored as an iCalendar resource.[28] The protocol extends the Web Distributed Authoring and Versioning (WebDAV) framework by incorporating its methods, including PROPFIND to query properties of calendar resources and collections, and PROPPATCH to set or modify those properties.[29] This inheritance allows CalDAV to utilize WebDAV's established mechanisms for property handling, such as live properties like getcontenttype and dead properties for custom metadata.[30] A key CalDAV-specific extension is the REPORT method, which facilitates advanced querying of calendar data beyond basic WebDAV capabilities.[31] For instance, the calendar-query REPORT enables clients to filter and retrieve calendar object resources based on criteria like time ranges or component types, using structured XML request bodies.[6] Other REPORT variants, such as calendar-multiget, support efficient retrieval of multiple specified objects.[32] CalDAV employs XML namespaces to organize its elements and properties distinctly. The DAV: namespace (urn:ietf:params:xml:ns:dav) is used for core WebDAV elements, while the CALDAV: namespace (urn:ietf:params:xml:ns:caldav) defines protocol-specific properties, such as calendar-home-set, which identifies the URL of a principal's calendar collections, and supported-calendar-component-set, which enumerates the iCalendar components (e.g., VEVENT, VTODO) supported by the collection.[33] These namespaces ensure unambiguous parsing of requests and responses, with all CalDAV elements prefixed accordingly in XML documents.[13] Principal resources in CalDAV represent users or entities involved in scheduling, serving as entry points for access control and address resolution.[34] A key property is calendar-home-set, linking to the principal's personal calendar collections.[35] Principals enable features like free-busy queries and support multi-user environments through WebDAV access control lists.[36] Error handling in CalDAV adheres to HTTP status codes, with WebDAV-specific extensions for precision. For example, the 507 Insufficient Storage status indicates quota exceedance during resource creation or updates, prompting clients to handle storage limitations gracefully.[37] Other common responses include 403 Forbidden for unsupported properties or access denials, and 424 Failed Dependency for partial failures in multi-resource operations, ensuring robust interoperability.[38]Data Model and iCalendar Integration
CalDAV employs a data model that organizes calendar information as a hierarchy of WebDAV collections and resources, where each calendar collection serves as a container for calendar object resources that encapsulate iCalendar data.[1] This structure ensures that calendaring data is managed in a manner consistent with WebDAV principles while leveraging the rich semantics of iCalendar for representing events, tasks, and availability.[1] Calendar collections are defined as WebDAV collections bearing theCALDAV:calendar resource type element, and they exclusively contain calendar object resources, prohibiting the inclusion of other resource types to maintain data integrity.[1]
The integration with iCalendar, specified in RFC 5545, maps calendaring concepts directly to CalDAV resources, with each calendar object resource storing an iCalendar object of media type text/calendar (version 2.0).[39] Core iCalendar components are represented as follows: VEVENT for events, including properties such as DTSTART for the start time and SUMMARY for a brief description; VTODO for tasks, utilizing properties like DUE for completion deadlines and SUMMARY for task titles; and VFREEBUSY for availability information, incorporating DTSTART and DTEND to delineate free or busy periods.[1] These components and their properties are embedded within the body of the iCalendar object resource, while certain metadata, such as the unique UID property, ensures resource identification across the collection.[1] For instance, a VEVENT resource might contain:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example//CalDAV Client//EN
BEGIN:VEVENT
UID:[email protected]
DTSTART:20231110T090000Z
SUMMARY:Team Meeting
DESCRIPTION:Discuss project updates
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example//CalDAV Client//EN
BEGIN:VEVENT
UID:[email protected]
DTSTART:20231110T090000Z
SUMMARY:Team Meeting
DESCRIPTION:Discuss project updates
END:VEVENT
END:VCALENDAR
RRULE for recurrence rules and override instances for exceptions, avoiding fragmentation.[1]
Servers advertise supported iCalendar components through the CALDAV:supported-calendar-component-set WebDAV property on calendar collections, which lists permissible component names (e.g., VEVENT, VTODO, VFREEBUSY) and whether they allow expansions for recurrence instances.[1] This property, which is protected and initialized by the client during collection creation via MKCALENDAR, enables clients to query and respect server capabilities before storing data.[1]
Time zone handling in CalDAV relies on the VTIMEZONE component from iCalendar to define time zone rules, including offsets and transitions between standard and daylight saving time.[39] The CALDAV:calendar-timezone property on calendar collections specifies a default VTIMEZONE for time-based queries and storage, with date-time values in components referencing time zones via the TZID property (e.g., TZID=America/New_York).[1] Clarifications in RFC 6638 ensure consistent application of these time zones during scheduling operations, preventing mismatches in multi-time-zone environments.[11]
For multi-user scheduling, CalDAV utilizes the ORGANIZER and ATTENDEE properties within VEVENT and VTODO components to facilitate invitations and participation management.[1] The ORGANIZER property identifies the event or task creator (e.g., ORGANIZER;CN=Cyrus Daboo:mailto:[email protected]), while ATTENDEE properties list participants with parameters like PARTSTAT (e.g., NEEDS-ACTION, ACCEPTED) to track responses.[39] These properties enable servers to process scheduling intents while maintaining the iCalendar format's interoperability for group calendaring.[1]
Protocol Operations
Basic Operations
CalDAV extends WebDAV to enable basic operations on calendar resources, which are individual iCalendar objects representing events, tasks, or journal entries stored as files with a .ics extension or similar. These operations use standard HTTP methods, ensuring atomic handling of single resources within a calendar collection. Calendar resources must conform to the iCalendar format (RFC 5545) for their content body.[1] To create a new calendar resource, a client issues a PUT request to an unmapped URI within the calendar collection, supplying the iCalendar data in the request body with Content-Type: text/calendar. The request includes an If-None-Match: * header to prevent overwriting existing resources. For example:PUT /home/lisa/calendars/events/event123.ics HTTP/1.1
Host: cal.example.com
Content-Type: text/[calendar](/page/Calendar)
If-None-Match: *
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp//CalDAV Server//EN
BEGIN:VEVENT
UID:[email protected]
DTSTAMP:20231110T000000Z
DTSTART:20231115T090000Z
DTEND:20231115T100000Z
SUMMARY:Team Meeting
END:VEVENT
END:VCALENDAR
PUT /home/lisa/calendars/events/event123.ics HTTP/1.1
Host: cal.example.com
Content-Type: text/[calendar](/page/Calendar)
If-None-Match: *
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp//CalDAV Server//EN
BEGIN:VEVENT
UID:[email protected]
DTSTAMP:20231110T000000Z
DTSTART:20231115T090000Z
DTEND:20231115T100000Z
SUMMARY:Team Meeting
END:VEVENT
END:VCALENDAR
REPORT /bernard/work/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: application/xml; charset=[utf-8](/page/UTF-8)
<?xml version="1.0" encoding="[utf-8](/page/UTF-8)" ?>
<C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getetag/>
<C:calendar-data/>
</D:prop>
<D:href>/bernard/work/event1.ics</D:href>
<D:href>/bernard/work/event2.ics</D:href>
</C:calendar-multiget>
REPORT /bernard/work/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: application/xml; charset=[utf-8](/page/UTF-8)
<?xml version="1.0" encoding="[utf-8](/page/UTF-8)" ?>
<C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getetag/>
<C:calendar-data/>
</D:prop>
<D:href>/bernard/work/event1.ics</D:href>
<D:href>/bernard/work/event2.ics</D:href>
</C:calendar-multiget>