technical caldav

In the second article of this series, I've written about how you can start using and deploying the WebDAV (and CalDAV/CardDAV) on your own systems, whether at the OS level, or at the CMS level (which Joomla! and Drupal, for instance, are capable of). In this post, let’s take a look at the technical aspects of the various extensions to HTTP; what their pros and cons are, and how you can use them at their best.

The first thing to understand is that from a technical perspective, WebDAV and all its derivative protocols are not APIs. That is to say, they do not specify how the protocols are implemented at the application level; merely how messages sent across the ‘wire’ (the Internet, in this case) are defined. The task of implementing a protocol, therefore, is comparatively simple, and it implies that any WebDAV client should be able to inter operate with any WebDAV server, regardless of platform (so a Joomla WebDAV client can exchange messages with a Microsoft IIS WebDAV server).

Unlike its own extensions CalDAV and CardDAV, WebDAV does not specify any specific format for the content that is transmitted across using the protocol. For CardDAV, the calendaring and scheduling information is required to be in the iCalendar format, while for CardDAV, contact details are required to be in the vCard format. This greatly simplifies the task of interpreting the information being received over the two protocols.

Like most other Internet application protocols (and their ‘parent’ protocol HTTP), WebDAV, CalDAV and CardDAV are all text-based. What this means is that all the commands and server responses are specified using text, rather than binary code. This is very much in line with the UNIX philosophy of keeping things text-based as much as possible (not surprising, seeing that the Internet uses the UNIX networking protocols TCP/IP), and means that most text-based tools can be used to work with WebDAV and its extensions, and any session logs would be human-readable.

This does not, however, mean that (like email) binary data has to be encoded in a text format. Because HTTP, the parent protocol, supports the direct transfer of binary data from server to client, WebDAV, CalDAV and CardDAV also supports the same – although in the case of CardDAV, since the underlying vCard format only supports binary data in the form of Base64-encoded text, it’s not very relevant. Similarly with CalDAV, where the iCalendar format also only supports the same thing. However, since WebDAV is often used as a network file system (what would today be called cloud storage), it fully uses HTTP’s ability to send and receive binary data.

We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.