Summary of the Calendaring Standards Landscape
Goals for OSAF
Things that will help Westwood development
- ratification of CAP - quickly (without sacrificing quality of the standard)
- encourage stability of evolving standards
- make sure CAP is Chandler-friendly (e.g. OSAF may need provide input to make sure that CAP is client application friendly)
- suggestions on how OSAF can facilitate goals above
- 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 during the last couple of weeks of Dec. 2003. 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...
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:
- The CalDAV approach may be a more "modern" solution and may (or may not) be technically superior and better suited to a smart client application like Chandler than CAP. The first draft was submitted to IETF in Nov. 2003.
- 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.
- What are the dynamics between supporting a "approved" standard and a better technical approach?
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)
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
- 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
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.
- 10 Dec 2003
Add subproject to compare CAP
Also, proceed to connect with CAL Connect - Calendar and Scheduling Consortium
to find out
- what they are doing
- what calendar clients they have, and
- understand if there is a working group for CAP to the ITEF. (calsch is the working group, we've been following the mailing list for several months -- KatieCappsParlante)
- note: Pieter sent Dave Thewlis, Director of CAL Connect an initial e-mail on 12/1/2003.
- following up with phone call to Dave and Pat Egen co-chair of the IETF CALSCH working group for week of 12/7 with Katie -- PieterHartsook
- OSAF joined CAL Connect consortium as a founding member in the fall of 2004
"OSAF is pleased to be able to support advances in calendaring
standards and interoperability by becoming a founding member of the
Calendaring and Scheduling Consortium and actively participating in
its efforts. The consortium, while not establishing standards itself,
has the laudable goal of encouraging dialog and interoperability
testing among partners who are not only actively engaged in standards
work, but who are also significant players in bringing solutions to
Development manager, standards architect -- Open Source Applications
Can you elaborate on why you are investigating CAP vs. Jungle.WebDAV? also, Sun seems to have a good CAP (& WCAP) implementation with their calendar server, perhaps someone there can help you with follow through. I have some CAP experience & would like to help if I can...
- 09 Dec 2003
Jake, it is our understanding that Jungle.WebDAV was mentioned as an alternative to CAP at the last calsch meeting. Different parties went off to finalize CAP and to propose a Jungle.WebDAV based calendaring approach. OSAF is currently agnostic about any CAP vs WebDav comparison. Like most folks, we want consensus around a set of calendaring standards, and we want to build Chandler to work well with those standards. Right now, we are focusing on other Chandler infrastructure and design issues, watching the activities of calsch and calconnect with interest, and just starting to engage with these groups more actively.
-- KatieCappsParlante - 10 Dec 2003