Calendar Federation and XMPP

Monday, July 13, 2009 by darco
Posted in , ,

Why can't sending an event invitation to someone be as easy as sending an email? Why can't I check a friend's availability if they aren't using the same calendar server? Why can't I share a calendar with my friends who don't have an account on my calendar server?

For some reason or another, the concept of Calendar Servers has captured my imagination over the past year or so. I believe this technology could change how people think of time management, but I think it needs three things before it can get to that point:

  1. Ability to invite someone to an event who is using a different calendar server.
  2. Ability to view availability of someone who is using a different calendar server. (And, as a corollary, the ability to control who can see your availability)
  3. Ability to share calendars and events with people who don't have an account on my calendar server.

The key to make all of this possible is something I call Automatic Federation.

UPDATE: After writing this post, individuals have brought to my attention RFC-2446, RFC-2447, and the iSCHEDULE Technical Committee. At first glance, it looks like this may make the stuff I was proposing here somewhat irrelevant, but some investigation is still warranted. I'm not yet sure how these specs prevent abusive things like spoofing and who is allowed to see free-busy information.

Federation of Calendar Servers

The easiest way to describe this is to start with invitations.

Conceptually, when you invite someone you need to send a notification to them that they are being invited. If they are using the same calendar service that you are using (like Google Calendar), then sending them an invitation is fairly easy. However, if you want to invite someone from a different domain (i.e.: a different calendar server) then a mechanism is needed to allow servers to communicate with each other. This concept is called federation.

The most famous (and infamous) automatically federated system in existence is undoubtedly SMTP-based email. The modern concept of email works as follows:

  • Clients send/receive messages to/from their server. (Client-to-Server, or C2S)
  • Servers relay foreign messages to other servers. (Server-to-Server, or S2S)

It is not very difficult to imagine how this same pattern could be applied to allow calendar server federation. The protocol for communicating between the client and the server has already been well defined—CalDAV. But what should we use to send the invitations between domains? The three most obvious options are SMTP, HTTP, and XMPP.

SMTP for Server to Server communications

One possible solution would be to use the same technology that has powered email for the past thirty years: SMTP. While this may seem like a reasonable solution, it ends up inheriting all of SMTP's problems—namely spoofing and its insidious relative: spam.

HTTP for Server to Server communications

Another possible solution would be to use some sort of custom protocol based on HTTP—because if we already need to run a web server for CalDAV, why not use it for server-to-server communications as well?

This is a more reasonable approach than the SMTP idea because it offers us the flexibility to engineer a solution to the spoofing problem. For example, instead of pushing invitations to their destination, we would push a notification of invitation and let them pull the actual invitation directly from us. (Thus, providing a flavor of mutual authentication without having to deal with certificates)

XMPP for Server to Server communications

XMPP is a protocol that was specifically designed for sending messages across domains. It implements mutual authentication, which means that spoofing messages is very difficult. It is also widely deployed. This is the federation protocol option that I personally lean toward.


When looked at only from the perspective of invitations it is not clear why XMPP would be better suited than custom HTTP-based solution. I believe that XMPP has additional added value in other areas which make it at least worthy of consideration. For example, XEP-0070: Verifying HTTP Requests via XMPP.

XMPP for Cross-Domain HTTP Authorization

The idea is that a particular calendar item would live on a server, and that whoever is given access to it can connect to that server (not theirs) and view the event information or change it. When you add someone to the ACL for a calendar event, you simply add their address (which, in most cases, would be a JID). Then when they connect to your server to view and/or edit the event they authenticate via XEP-0070, and if they are in the ACL then they can perform whatever operations the ACL describes. This is taking advantage of the fact that XMPP is effectively a globally-distributed and federated authentication system. Not many people realize that XMPP can be used in this way.

This mechanism could also be how someone would authenticate to their own calendar server. For an "XMPP Enabled" calendar server, the client calendar program could use XEP-0070 to authenticate all HTTP requests sent to the CalDAV server. This XMPP connection could either be created and used exclusively by the client program, or it could be a shared XMPP connection that already exists.

XMPP for Real-Time Calendar Updates

Authentication isn't the only thing that client-side XMPP connection could be used for. Having an XMPP connection in the calendar client gives the Calendar Server an easy way to push update notifications directly to the client. Receive invitations right as you are invited, and get up-to-the-second updates on invitee confirmations.

Since the calendar server already has an S2S component built into it, it can send calendar updates directly to the client1 without the use of a separate pub-sub server—because the calendar server would be the pub-sub server.


This is an idea that I've been sitting on for far too long, and I just wanted to share my thoughts on it and hopefully get a discussion started. CalDAV is a powerful technology, but without some sort of automatic federation I believe it's utility will be somewhat stunted. I happen to be very passionate about XMPP, so my perspective is admittedly somewhat biased toward it, but I'm not unwilling to consider alternatives. The ability for calendar servers to communicate with each other is quite compelling no matter which technology is used to make it happen.

Feedback and comments are welcome!

1: Technically, the calendar server wouldn't be sending the update *directly* to the client, it would be sending the update to the user's XMPP server and then that update would be forwarded to the client.