The calDAV Standard - navigating the RFC jungle

Application interoperability is key to wide spread adoption. Luckily there are so many open standards that one can claim to be open without being interoperable. On a protocol level HTTP and SMTP were huge successes, as well as HTML/MIME for message content. Beyond that it gets murky. None of the big vendors (outside the OpenSource space) has adopted an open protocol for chat and presence.

For other standards, most notably Calendaring, support is murkey. On key contributor might be the RFC process that produces documents that are hard to follow and lack sample implementations. They are work outcomes of a committee after all. In this series of blog entries I will (try to) highlight the moving parts of a calendar server implementation. The non-moving parts here are the calendar clients to target: Apple calendar on iOS and macOS, Thurnderbird and a few others.

Involved standards

There is a series of RFC that cover calendar operation, with various degrees of relevance:

• RFC 4918: webDAV. Defines additional HTTP verbs and XML formats
• RFC 4791: calDAV. Defines again additional HTTP verbs
• RFC 5545: iCalendar. Calendar data as plain text, or XML or JSON
• RFC 7953: vAvailability. Free/Busy lookup specification
• RFC 7986: Extended properties for iCalendar
• RFC 6638: Scheduling extensions
• RFC 8607: Managed attachments in calendar entries
• RFC 8144: Use of Prefer Header field in webDAV
• RFC 5785: Definitions for the /.well-known/ URL

Technologies

Based on the RFC we can see what are the moving parts that constitute the calendar API:

• HTTP extensions: With the introduction of new HTTP keywords (e.g. REPORT or PRPOPFIND), the basic REST idea gets turned upside down by having verbs with specific meanings instead of the ususal CRUD logic. In a more contemporary approach the actual actions would be represented by the URL, but that would be too easy.
• iCalendar: a text based key/value format for calendar information, with little goodies like identifying multi-line entries just by some indentation
• XML: inherited from webDAV: angle bracked infested data structure that does not care about white space or indentation. This gets juicy when it contains an iCalendar as payload, that is very well sensitive to indents.

Vendor and consortium documentation

There are plenty of trees in the woods, so the task is scavenging, not planting. Besides the RFC, this is what I found:

• Google has a partial calDAV implementation. Their approach seem to be: only what's needed for a typical client
• Apple opensourced their Calendar Server including a Test Suite and a Docker Image (Blog post)
• The CalConnect consortium provides a nice Developer Guide, mostly focused on data formats and client implementations
• webDAV Community provides information around webDAV and its implementations
• Joomla's iCalendar.org provides a validator
• Most notably absent: Microsoft. They do support calDAV, but only if you are on the nice list (which is basically US based cloud vendors). There are solutions and AddOns. It seems that in the Microsoft world calendaring is best served with SOAP / EWS or the shiny new Microsoft Graph API

The tools

Gearing up to battle with an API mandates to be armed with the right toolset. This skilled craftsman suggests:

• Postman: We want to test different HTTP commands, Postman makes that easy
• CURL: Anything HTTP, from the command line, for professionals or CI/CD
• Charles Proxy: When testing endpoints used by actual client applications it allows you to see the traffic
• Docker: Running a few calendar servers to see how they "tick" in docker

This is just the beginning of a long trip, stay tuned!