How do online calendars even work?

(Last updated: )

This is a pretty rough post of my (meager) understanding of how online calendars work. Details may not be complete or 100% correct, but I needed to record this somewhere anyway.

Online calendars are complicated beasts. It’s understandably that most folks outsource calendars and contacts (collectively referred to as “groupware” alongside email) to third parties such as Microsoft 365, Gmail, or Fastmail, or use self-hosted solutions such as NextCloud. But for those of us who want a lightweight calendaring solution, there aren’t a lot of straightforward implementations, and there’s precious little documentation of how everything fits together (unless you want to read a bunch of RFCs, which are likely to put you to sleep).

This post is my attempt to give an overview of each of the components of online calendaring and how they interoperate, to make this all a little less mysterious.

Calendar representation

In most implementations, calendars are represented via the iCalendar format, which usually has a .ics file extension.

An iCalendar file can contain a calendar of one or more events (among other non-event object types). A simple file could look like this (pulled from the above Wikipedia page; more details there):

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT
UID:uid1@example.com
DTSTAMP:19970714T170000Z
ORGANIZER;CN=John Doe:MAILTO:john.doe@example.com
DTSTART:19970714T170000Z
DTEND:19970715T040000Z
SUMMARY:Bastille Day Party
GEO:48.85299;2.36885
END:VEVENT
END:VCALENDAR

This file has only a single event “Bastille Day Party”, which is organised by “John Doe”. If this were loaded into a calendar client app, the app would check for an event with the same UID, and if it found one, would update that event in the calendar. If it didn’t find a matching event, it would offer to add this as a new event.

iCalendar files can include the fields ORGANIZER and ATTENDEE, where the former is the person organising an event, and the latter, which lists the people who are invited to attend.

Calendar synchronisation

Many calendaring implementations synchronise a user’s calendar with a server using CalDAV, which is a protocol built on top of WebDAV, which in turn is built on HTTP. CalDAV uses HTTP to send and receive iCalendar files between a calendar client and calendar server, updating a user’s calendar where appropriate. This means you can have your calendar on multiple devices (phone, tablet, desktop, and sometimes via a web interface), and have a synchronised view of events across them all.

Calendar invitations and RSVPs

This is where things get particularly tricky. In theory, I can craft an iCalendar file with a single event, myself specified as an ORGANIZER, and one other ATTENDEE, and give that file to the other attendee somehow (via email or otherwise), and then that person can import the iCalendar file to their own calendar, which would offer to update the event with their RSVP (e.g. with ACCEPTED, TENTATIVE, or DECLINED statuses). Then, if that person were to export that event to an iCalendar file and send it back to me, I could import that back into my calendar, which would then show whether the person was attending or not.

This is, of course, quite tedious; exporting and importing iCalendar files is not often made easy, and even if it were, doing so every time an event got updated would get old very quickly.

There are some protocols that can handle the communication of updated calendar events automatically. A couple of these are called iTIP, and iMIP.

iTIP (“iCalendar Transport-Independent Interoperability”) defines how software can communicate iCalendar files between event attendees and organisers, but leaves the actually communication platform undefined, instead only listing a set of methods to define what type of update is being communicated.

A companion to iTIP is iMIP (“iCalendar Message-based Interoperability Protocol”), which explicitly defines how to communicate iCalendar file updates over email. This protocol can be implemented by an email client (mail user agent, or MUA), or an email server (mail transport agent, or MTA). I don’t fully understand the nuances of this yet, but the broad overview is that when an email with an iCalendar file is received by an email client or server that knows how to access the calendar for that email user, the client/server is able to integrate the iCalendar update with the user’s calendar.

Some mail clients, such as Mozilla Thunderbird, support doing this, while others (such as Mail for Apple iOS), seem to rely on this being supported on the server-side. That is, the CalDAV server (or equivalent) that is hosting the user’s calendar tells the client that it supports iTIP, and when an updated event is sent from the calendar client to the calendar server, the calendar server then passes it on to the mail server, which sends the updated event to relevant attendees. In the case of a client-side implementation, such as Thunderbird, the client receives an iCalendar event in an email, automatically adds it to the relevant calendar, and when the event in the calendar is updated, Thunderbird sends an email to other attendees with the updated iCalendar file attached.

References