Summary of the Calendaring Standards Landscape

---

Goals for OSAF

Things that will help Westwood development

1. IETF ratification of CAP - quickly (without sacrificing quality of the standard) or adoption of an alternative standard
2. encourage stability of evolving standards
3. make sure CAP is Chandler-friendly (e.g. OSAF may need provide input to make sure that CAP is client application friendly)

---

Action Items

1. suggestions on how OSAF can facilitate goals above
2. any opportunity for CSG institutions or as a group to encourage the above goals

---

Current Calendaring Landscape (as we understand it)

To try an understand the status and progress of the various calendar standards, and in particular the status of CAP, we have talked to a number of the principle players and interested parties in the calendaring and scheduling standards community within the last couple of weeks. These include:

• Pat Egen, who along with Bob Morgan is co-chair of the IETF Calendaring and Scheduling (calsch) working group proposing the CAP standard
• Nathaniel Borenstein, the current acting editor of the CAP draft document and IBM employee
• David Thewlis, Director and co-founder with Pat Egen of the Calendar and Scheduling Consortium http://www.calconnect.org a newly formed non-profit that hopes to promote calendar and scheduling standards within the industry
• Marten den Haring, Oracle/Corp. Time - still on record as having Oracle Calendar evolving to CAP complience
• Lisa Dusseault, CalDAV proposal author, currently works for Xythos (Web File Server/Content Management vendor)

Standard ratification process and estimates of when CAP will be approved.

There seems to be a consensus that the CAP standard draft will be approved in either the March or June meeting this year (2004). Of course, once the draft is approved the resulting RFC needs to be ratified and by the time that occurs it may be time for revisions of all the iCalendar suite of standards. So even when CAP is established as a standard it would be expected to continue to evolve.

But wait!, There's something new from the calsch working group that's been proposed...

#CalDAV A new approach for calendar client/server interaction based on WebDAV has been proposed by Lisa Dusseault (CalDAV) see the introduction to the CalDAV draft published Nov. 1, 2003, and related links below

---

CalDAV (see the full draft of the proposal at: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-00.txt , and good summary document with bibliographies at: http://xml.coverpages.org/ni2003-12-31-a.html.)

Introduction from the CalDav draft

Advantages of WebDAV for Calendar Access

   WebDAV offers a number of advantages as a framework or basis for
   calendar access.  Most of these advantages boil down to a significant
   reduction in design costs, implementation costs, interoperability
   test costs, deployment costs, and the costs of mistakes.  Every new
   standard author or implementor finds certain small errors and the
   IETF spends considerable time and effort remediating these.  Some of
   the advantages are contingent upon the way WebDAV is used, which is
   why this section exploring advantages is inseparable from the rest of
   this document for the moment.

   This draft was commissioned at the Fall 2003 Minneapolis working
   group meeting of the CalSched working group.  The concept of using
   HTTP/WebDAV as a basis for a calendaring server is by no means a new
   concept: it was discussed in the CalSched working group as early as
   1997 or 1998.  Several companies have implemented calendaring servers
   using HTTP PUT/GET to upload and download iCalendar events, and using
   WebDAV PROPFIND to get listings of resources.  However, those
   implementations do not interoperate because there are many small and
   big decisions to be made in how to model calendaring data as WebDAV
   resources and properties, as well as how to implement required
   features that aren't already part of WebDAV.  This draft is therefore
   intended as an exploration of the advantages of using WebDAV as well
   as a proposal for one way to model calendaring data, and some ideas
   for how to specify the features that go beyond WebDAV.

---

The issues to discuss regarding CalDAV are:

1. Even if CalDAV were to prove to be a better approach, it looks like no one is going to throw out the 10 years of effort on CAP and the CAP draft will be approved shortly.
2. While the CalDAV approach is a more "modern" solution and may (or may not) be technically superior and better suited to a smart client application like Chandler than CAP, it may take considerable time to have the draft extension to WebDAV approved.
3. It is not clear what the impact on architecture and development time for Westwood would be if we were to attempt to support both CAP and CalDAV. We will probably should support just a single standard.
4. What are the dynamics between supporting a "approved" standard and a better technical approach

---

Supporting Materials

---

The Calendar Access Protocol (CAP) is an Internet protocol described in http://ietfreport.isoc.org/ids-wg-calsch.html that permits a

• Calendar User (CU) to utilize a
• Calendar User Agent (CUA) to access an
• [iCAL] based Calendar Store (CS).

The CAP definition is based on requirements identified by the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) Working Group. More information about the IETF CALSCH Working Group activities can be found on the IMC web site at http://www.imc.org/ietf-calendar and at the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html

---

Guide to Internet Calendaring RFC 3283 see http://www.ietf.org/rfc/rfc3283.txt

is an excellent summary document explaining the relationship of the various IETF RFCs (though this version does not address the new CalDAV draft)

Abstract

   This document describes the various Internet calendaring and
   scheduling standards and works in progress, and the relationships
   between them.  Its intent is to provide a context for these
   documents, assist in their understanding, and potentially aid in the
   design of standards-based calendaring and scheduling systems.  The
   standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and
   RFC 2447 (iMIP).  The work in progress addressed is "Calendar Access
   Protocol" (CAP).  This document also describes issues and problems
   that are not solved by these protocols, and that could be targets for
   future work.

      - Data format: iCalendar [RFC-2445]

      iCalendar [RFC-2445] provides a data format for representing
      calendar information, to be used and exchanged by other protocols.
      iCalendar [RFC-2445] can also be used in other contexts, such as a
      drag-and-drop interface, or an export/import feature.  All the
      other calendaring protocols depend on iCalendar [RFC-2445], so all
      elements of a standards-based calendaring and scheduling systems
      will have to be able to interpret iCalendar [RFC-2445].

      - Scheduling protocol: iTIP [RFC-2446]

      iTIP [RFC-2446] describes the messages used to schedule calendar
      events.  Within iTIP messages, events are represented in iCalendar
      [RFC-2445] format, and have semantics that identify the message as
      being an invitation to a meeting, an acceptance of an invitation,
      or the assignment of a task.

      iTIP [RFC-2446] messages are used in the scheduling workflow,
      where users exchange messages in order to organize things such as
      events and to-dos.  CUAs generate and interpret iTIP [RFC-2446]
      messages at the direction of the calendar user.  With iTIP [RFC-
      2446] users can create, modify, delete, reply to, counter, and
      decline counters to the various iCalendar [RFC-2445] components.
      Furthermore, users can also request the free/busy time of other
      people.

      iTIP [RFC-2446] is transport-independent, and has one specified
      transport binding: iMIP [RFC-2447] binds iTIP to e-mail.  In
      addition [CAP] will provide a real-time binding of iTIP [RFC-
      2446], allowing CUAs to perform calendar management and scheduling
      over a single connection.

      - Calendar management protocol: [CAP]

      [CAP] describes the messages used to manage calendars on a
      calendar store.  These messages use iCalendar [RFC-2445] to
      describe various components such as events and to-dos.  These
      messages make it possible to perform iTIP [RFC-2446] operations,
      as well as other operations relating to a calendar store such as
      searching, creating calendars, specifying calendar properties, and
      specifying calendar access rights.

---

-- PieterHartsook - 10 Dec 2003