Cosmo Scheduling Prototype

This prototype explores the architectural changes needed in Cosmo to support a basic scheduling scenario in the web UI and at the protocol layer.

Introducing scheduling has ramifications throughout the server architecture. A user needs a place to store incoming, not-yet-accepted meeting invitations. Core APIs must be introduced to perform per-user free-busy lookups (rather than the per-calendar lookups that Cosmo provides now). The feed and DAV services must provide operations that allow the web UI to perform scheduling functions like invite, accept, decline, counter, and update. The web UI must provide an interface for aggregating free-busy lookups for multiple users and for the scheduling functions listed above.

One assumption is that all of the attendees have accounts on the same Cosmo server instance. The prototype does not consider scheduling between users on separate instances of Cosmo or between users of Cosmo and other scheduling systems. This constraint allows the protocol services and core APIs to be implemented wholly in terms of core API method calls within a single JVM and ignores any communications with external processes.

Scenario

The prototype scenario is: The Cosmo development team collaboratively schedules a status meeting.

Specific use cases considered in the scenario are:

• Ted uses the web UI to find a time where every attendee is free, schedules a meeting for that time and sends invitations to every attendee
• Travis uses the web UI to accept the invitation and add the meeting to his calendar
• Brian uses Google Calendar to accept the invitation and add the meeting to his calendar
• Mikeal uses iCal 3 to accept the invitation and add the meeting to his calendar

Other interesting use cases include:

• Matthew uses the web UI to decline the invitation
• Bobby uses the web UI to decline the invitation but suggest a new time
• Ted uses the web UI to rescheduling the meeting and update the other attendees
• Matthew uses the web UI to accept the rescheduled meeting and add it to his calendar
• Travis and Bobby use the web UI to accept the update
• Brian uses Google Calendar to accept the update
• Mikeal uses iCal 3 to accept the update
• Ted uses the web UI to confirm the meeting
• Ted uses the web UI to cancel the meeting

These use cases together exercise the basic features of a collaborative scheduling system across multiple interoperable calendar applications.

Definitions

Attendee

A party who is invited to a meeting by an organizer

Inbox

A special calendar collection that is used to receive scheduling messages sent by organizers

Free-busy lookup

(in the context of scheduling) The process by which an organizer determines the availability of each attendee and chooses the most appropriate time for which each attendee is free

Outbox

A special calendar collection to which an organizer's client sends scheduling messages for distribution to attendees' inboxes and which maintains a history of these messages

Organizer

The party who who sets up a meeting with one or more attendees

Model

Core APIs

Feed Service

DAV Service

• calendar-schedule feature in DAV header of OPTIONS response
• Inbox and outbox resources obey iTIP restrictions for calendar objects, not caldav-access restrictions
• resource types:
  • CALDAV:schedule-inbox
  • CALDAV:schedule-outbox
• outbox semantics:
  • POST to outbox MAY save a resource with a copy of a scheduling message but MUST NOT save a copy of a free-busy message
  • MAY auto-delete outbox resources
• inbox properties:
  • CALDAV:calendar-free-busy-set inbox property - identifies all calendar collections that contribute to free-busy info; basically a negated aggregate version of cosmo:exclude-free-busy-rollup; setting this property should set the exclude property for all contained calendar collections
• scheduling resource properties:
  • CALDAV:originator - identifies the originator of the scheduling message
  • CALDAV:recipient - for an outbox resource, identifies the intended recipients of the scheduling message; for an inbox recipient, identifies the recipient for whom the message was delivered to the inbox
• sending scheduling messages:
  • POST to outbox including Originator and Recipient headers
• acting on scheduling messages:
  • inbox must be lockable and unlockable as per WebDAV class 2
• iCalendar property parameters:
  • RECEIVED-SEQUENCE
  • RECEIVED-DTSTAMP
• scheduling privileges:
  • CALDAV:schedule-request
  • CALDAV:schedule-reply
  • CALDAV:schedule-free-busy
  • CALDAV:schedule
• principal properties:
  • CALDAV:schedule-inbox-URL
  • CALDAV:schedule-outbox-URL
  • CALDAV:calendar-user-address-set

Web UI

Conclusions

References

• draft-desruisseaux-caldav-sched: CalDAV Scheduling
• RFC 2446: iTIP
• RFC 3744: WebDAV Access Control
• RFC 4791: CalDAV Access
• RFC 4918: WebDAV