Calendaring Standards and Architectures

For as long as there have been properly defined standards for calendar data it has been possible to use traditional e-mail to share the details of events, and for each individual to look after their own calendar and to know when these events will occur. However, when only "pure" iCalendar information is being shared - in the form of events being attached or included in messages - all participation information needs to be exchanged informally.

simplenew eventeventsMail infrastructuresend eventinboxinboxevents"I will attend..."

iTIP

To structure the workflow of negotiating and registering attendance, the iCalendar standard was extended to incorporate well-defined ways of exchanging information about participation in events and other activities. Using iTIP, clients can exchange participation and availability data in a peer-to-peer fashion.

iTIPnew eventeventsMail infrastructurerequest attendanceinboxinboxeventsacceptance

Publishing Free/Busy Information

Although it is possible to unconditionally publish availability information, it might be desirable to be able to request such information as well but to do so without bothering individuals. In principle, e-mail programs could handle such requests without user intervention - the program would auto-respond to free/busy messages, perhaps based on some kind of policy - but other approaches have been pioneered where free/busy data is published on a server and retrieved by clients aware of its location. The earliest forms of this server-hosted approach probably employed plain HTTP PUT requests to a writable location and HTTP GET requests to obtain other people's free/busy data, but other protocols like IMAP can be used. More recent approaches have built upon HTTP and applied WebDAV-based technologies such as CalDAV. In practice, hybrid solutions involving a combination of these approaches are employed.

Discovering the location of published free/busy information for a given person is another challenge. Doing so can involve consulting the details of such contacts in LDAP or vCard form, with the latter being defined in calendar properties of vCard objects. Thus, provided that a person's contact details are accessible and incorporate a free/busy URL, it should be possible to immediately request free/busy information from a definitive source. (Interestingly, the FBURL definition does not mention mailto URLs, despite this already being standardised by iMIP.)

freebusynew eventeventsfree/busy for client #1publishnew eventfree/busy for client #2eventspublish

Resources, Scheduling and Agents

Apart from scheduling the attendance of individuals, there may also be other entities involved in a calendar event that also need to be scheduled or reserved. Such entities - commonly known as resources - may need to be managed in a structured way, but their interactions with people may not be overseen by an individual: it may be very desirable that such interactions be managed automatically - rooms might be booked by anyone with appropriate privileges - and thus there will not be someone with an e-mail client receiving, processing and responding to mails about booking rooms or otherwise managing access to resources. Instead, something (that once upon a time used to be popularly referred to as an agent) is given the task of handling such correspondence.

Some systems appear to implement this agent functionality when events are saved or updated by individuals within a common store of event information, rather than have a mail recipient receiving messages and acting upon them. SOGo, for example, appears to do this:

sogoinboxnew eventusing Porsche 911events #1save eventMail infrastructureResource:Porsche 911acceptance

Here, alongside the reservation of resources, event attendees are notified about invitations. One way of performing such notifications is through the use of iTIP requests (using e-mail and iMIP as supported by CalendarServer and SOGo) where invitations are initiated by the server and received by event attendees. Attendees will invariably save any event they accept, and thus the server may also opt to send an iTIP reply on behalf of an attendee. It is also conceivable that in such an architecture, the client software of attendees could send the appropriate iTIP replies (alongside saving the event in their own calendar).

sogoinboxnew eventevents #1save eventMail infrastructureinboxinvitationevents #2acceptancereceivedsave event

One server-managed mechanism for notifications is provided by the scheduling extensions to CalDAV which uses scheduling endpoints for the exchange of notifications, with users on the same server being able to collect invitations using CalDAV and to respond to them. Interoperability between different servers requires other mechanisms.

In Kolab, resources are managed by an agent handling framework called Wallace. Wallace presumably tracks the free/busy state of resources (in wallace.module_resources.read_resource_calendar), but this state does not appear to be published to the Web server. For normal users, free/busy information is periodically published to a directory which is then exported by a Web service. Resources are slightly differently handled, but in principle they could also be supported by the free/busy daemon and by other mechanisms.

resourcesinboxeventsnew eventMail infrastructurerequest reservationinbox for resourceevents for resourceacceptancefree/busy record

In principle, such agents could also act on behalf of real people provided that they have access to those people's calendar details. However, a quick search doesn't bring up much in the way of indication that clients actually support sending free/busy requests using iMIP (iTIP over e-mail).

Asynchronous and Synchronous Access to Free/Busy Data

Certainly, when attempting to schedule an event, instant access to free/busy information via a synchronous medium like HTTP is somewhat preferable to supporting a workflow where attendees are identified and then their free/busy details are requested via an asynchronous medium like e-mail, particularly if the attendees list is fluid and where people might be selected according to availability. Indeed, the supposed inadequacy of e-mail for the timely exchange of free/busy information is used as the motivation for some complicated standards proposals.

Then again, it is not inconceivable that in an environment where all events or meetings involve a well-defined set of people, instead of organisers or managers browsing around in the organisational hierarchy for people who might like an invitation, having asynchronous free/busy updates would be good enough for scheduling purposes: people would just keep themselves up-to-date with the availability of members of their team or project by occasionally sending out requests or encouraging their team members to keep publishing updates to their availability information.

Free/busy information could be exchanged by e-mail (as iMIP describes) but on an opportunistic basis in the form of additional attachments accompanying payloads conducting other business, such as those accepting, declining or countering invitations. Such information could then be held in a cache so that when an organiser wishes to consult availability information and get an immediate response - perhaps because they are viewing a dialogue showing availability and will not want to suspend that dialogue while e-mail messages are exchanged - the cached information will most likely already be available and also serve as a "best effort" overview even if it is not completely accurate.

Mail Agents and Calendar Server Agents

One advantage of using mail agents like Wallace to manage resources is that they behave just like other mail recipients and can in principle be used by individuals with only an e-mail program and the ability to send messages to e-mail addresses associated with resources. The disadvantage is a need for a mail transport agent that can be configured appropriately to support the workflow.

Perhaps the main advantage of calendar server agents is that their functionality - acting upon stored events - is a natural extension of the functionality of the calendar server itself, but for all the relevant functionality to be activated, users must be storing their events in a suitably enabled server that takes care of the details of scheduling. This makes it tempting to almost demand that all involved users make use of the same infrastructure (even though a federated approach would also be possible with iTIP mediating between different server systems).

Even where mail-based agents are preferred and employed, it can still be useful to provide calendar server support for direct interaction with the scheduling mechanisms. Consider a recipient of an invitation whose e-mail program does not support iTIP/iMIP interactions: messages could provide a hyperlink or reference to a server resource that allows acceptance or rejection of event invitations and the dispatch of a reply to the event organiser by e-mail. By opening the link in a Web browser, even users of basic e-mail software can be included in the invitation workflow.

Summary

So, the typical architecture for calendaring is as follows:

architectureMail infrastructureinbox #1inbox #2inbox for resourcefree/busy for client #1free/busy for client #2new eventfree/busy for resourceevents #1acceptanceacceptanceevents #2events for resource

In summary, what we have is the following:

References