One of the most mundane unfulfilled promises of the Internet is perhaps scheduling, through personal Calendars, ToDo lists and Journal entries; all these could in theory be distributed and shared, under proper access control, but none of this has been realised in practice.

The following examples show how the core definition can be useful.

The intention of ARPA2 is to bring these rudimentary principles to everyone's fingertips. Interestingly, data formats have been defined, but the current set of transport protocols is not really useful.

The problems that are currently being faced are:

  • The Email transport requires manual actions; or else spammers could take control over your schedule;
  • The CalDAV transport requires polling, thus leading to data charges or non-realtime performance.

The solution that we propose for this is to use AMQP; this incorporates a facility for sharing documents with a MIME-type, including iCalendar updates, to be sent between endpoints. The Reservoir incorporates these submissions and schedules them based on the MIME-type and their sender.

As an example application, your secretary could be granted direct access to your work calendar masked, but only during work hours and only when not overruled by your personal quality-time calendar.

As another example, you could grant access for one meeting and one only to a group of friends, and they may find an entry within your personal calendar, but only when not overlaid by your spouse's or your work calendar.

A dentist, a singing teacher and so on could do similar things; they might send an invitation that you can use to setup a meeting with them in the hours they allocated for you.

In all this, authentication is important to validate that data is only entered (and updated!) by the right party, and only them. This is one of the things where AMQP steps in.

If you care, you can read the original architecture document on this part of the Reservoir; it is a bit older, does not yet speak of the AMQP and ATOM/RSS transport options, but it gives an idea of the sort of structures we are aiming at: server2server submission of iCalendar files using a variety of transport options including automatic processing where possible, and client2server interaction for manual initiation and for making scheduling choices.