Open Calendar Sharing and Scheduling with Caldav

Home , CalDAV, Calendar (Windows), ICalendar

Editor: Jim Whitehead, [email protected]

Open Calendar Sharing Track Standards and Scheduling with CalDAV

Building on a decade of work on calendar standards, the CalDAV protocol promises to unlock the potential of widespread calendar interoperability. It permits calendar sharing over the Web and reduces the coordination cost of scheduling meetings across and within organizational boundaries.The protocol extends the Web Distributed Authoring and Versioning (WebDAV) protocol — itself, a simple extension of HTTP — to provide services for calendar maintenance, queries, event scheduling, and security.

onsider for a moment the effort it nology can see dramatic benefits as Lisa Dusseault takes to schedule a meeting that meeting-coordination time drops from Open Source Cincludes people from multiple orga- tens to single-digit minutes — as long as Applications Foundation nizations. Currently, doing so involves everybody uses client software that sup- phone calls and multiple rounds of ports the chosen enterprise application. Jim Whitehead email, usually coordinated by one per- Unfortunately, these applications work University of California, Santa Cruz son, to build consensus for a time that only within existing organizations. Con- works for most people; the coordinator sider what happens when Jim, who works must also delicately handle cases in outside the organization, wants to sched- which the chosen time excludes one or ule a meeting with Larry and his cowork- more participants. ers, who are inside. Because he doesn’t For meetings in which everyone comes have an account on the internal calendar from the same organization, participants system, Jim must send an email to Larry, can solve scheduling issues largely via who then takes on the coordination task calendar sharing and scheduling software. to find meeting slots that work for his To schedule a meeting with Oracle Calen- coworkers. Larry must then negotiate dar or Microsoft Exchange/Outlook, for with Jim for a time slot that works for example, you log in to a calendar server members of Jim’s organization. Even if and then issue search requests for avail- Larry and Jim both had access to calen- able times among a group of meeting par- dar systems for their respective organiza- ticipants. Once the application ﬁnds a free tions, the process would remain tedious time slot, it sends a meeting request and and prone to coordination breakdowns. then handles acceptance or rejection To efﬁciently schedule meetings, users replies. Organizations that adopt this tech- need an interoperability protocol that lets

a diverse range of calendar clients and servers operations via email, has seen some success, communicate over the Internet. With such a pro- including several vendor implementations and tocol, we could use existing tools to schedule some cross-vendor interoperability. However, iMIP cross-organization meetings as efficiently as with- isn’t commonly used today by typical calendaring in-organization meetings. This protocol would also or email applications. make it easier to support calendar access and CAP provides services that calendar applica- scheduling functionality on a broad range of tions can use to access calendar items from remote devices by providing an open, consistent, stan- servers, search for open time periods in another dardized way to retrieve calendar data. person’s calendar (known as free/busy queries), and schedule meetings. (See www.calsch.org/ History of ietf/drafts.html for a complete list of CalSch’s doc- Calendar Interoperability uments, drafts, and issues.) In versions 00 through Protocol developers have long recognized the need 05 of CAP (released between August 1999 and for a calendar access and scheduling protocol. A July 2001), CalSch developed an entirely new pro- July 1996 press release from Netscape Communi- tocol that was distinct from all existing applica- cations heralded the formation of a working group tion-layer protocols, although it borrowed some- dedicated to developing standards for calendaring what from the Post-Office Protocol (POP) for its and scheduling on the Internet.1 That group became interaction style. In versions 06 through 11 the IETF’s Calendaring and Scheduling (CalSch) (November 2001 through July 2003), the working working group, which operated from October 1996 group used the Blocks Extensible Exchange Pro- through September 2004. CalSch initially divided tocol (BEEP) for its marshalling syntax and mes- its work into three main lines of development: saging behavior.5 CalSch made no further progress on CAP, and the IETF closed the working group in • a data model and textual representation for cal- September 2004. After four years of development, endar events (which generated the iCalendar CAP was dead. specification), As CAP development was slowly progressing, • the transport of calendar information via several implementers were routing around the email and LDAP (which resulted in the working group to release functional Internet cal- iCalendar Message-Based Interoperability Pro- endars. In 2002, Apple Computer released its iCal tocol [iMIP]), and personal calendar application, which supports • a general-purpose specification for calendar Internet-based calendar sharing. With iCal, a user access and scheduling (which became the Cal- can publish a calendar to a server running Web endar Access Protocol [CAP]). Distributed Authoring and Versioning (WebDAV),6 from which anyone else can view and download A key problem in developing interoperable calen- events. Although Apple designed the application dar applications is determining a standard way to to integrate with its WebDAV-based .Mac service, represent calendar items, including those that iCal works with any WebDAV server. A few open- repeat over time (a meeting held every Monday at source clients adopted iCal-over-WebDAV as the 11 a.m., for instance). CalSch built on earlier work de facto first open calendaring standard. by the Versit consortium, which developed an ini- In WebDAV,6 Apple made an interesting choice. tial calendaring and scheduling specification called The protocol extends HTTP to include overwrite vCalendar (www.imc.org/pdi/). After two years of prevention (locking), namespace operations (list refining that work, CalSch produced RFC 2445,2 collection, move, copy, create collection), and which is now in widespread use. The iCalendar metadata (properties). Combined with HTTP’s capa- data format it defines shares vCalendar’s non-XML bilities for reading, writing, and deleting Web format for representing attribute-value pairs. resources, WebDAV provides all the features nec- CalSch also developed the iCalendar Transport- essary for remote publishing and sharing of calen- Independent Interoperability Protocol (iTIP) for dars. Given that Apple was already using WebDAV calendar retrieval and scheduling operations.3 This for access to its .Mac Internet disk service, it was document described conceptually how to perform able to piggyback calendar sharing on top of the calendar-related operations, but it didn’t provide existing WebDAV server infrastructure — a far a concrete, on-the-wire protocol. The iMIP speci- more attractive option than implementing and fication,4 which describes how to perform iTIP fielding server infrastructure for a new protocol

82 MARCH • APRIL 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING CalDAV

such as CAP. Apple showed, in a very public way, that calendars could be treated like any other Web Daughter Father resource accessible via HTTP. Although Apple’s iCal provides useful capabil- Mother ities for individuals to publish and share their calendars, it does have drawbacks for corporate use. It CalDAV CalDAV CalDAV isn’t easy to search for free/busy times across a large set of people or to find other people’s calen- Family calendar dars. Due to synchronization issues, iCal also March makes it very tricky to have someone else manage your calendar for you. These problems largely stem CalDAV server from protocol-level shortcomings. Although native (at ISP) WebDAV easily supports individual publishing and sharing, it doesn’t provide any support for calendar locating, searching, or workflow scheduling. Figure 1. Collaborative editing scenario with a shared calendar. This Yet, Apple’s success with iCal-over-WebDAV raised family uses a shared calendar maintained on a CalDAV server run the question of whether specialized calendar sup- by their ISP. The father uses a laptop computer at work and home port could be added to WebDAV, rather than to update the calendar; the mother uses a PDA with wireless access. requiring a new protocol like CAP. Ideally, we Their daughter keeps in synch with the rest of the family by viewing would like a calendar access protocol to support and updating the calendar from her cell phone. standard within-organization meeting scheduling, as well as collaborative calendar sharing such as a family might use (Figure 1). Additionally, we want to make it much easier to schedule a meeting Open Source University of California, between participants from multiple organizations Applications Foundation Santa Cruz (Figure 2). Supporting these scenarios is the moti- iMIP vation for the Calendaring and Scheduling Exten- sions to WebDAV (CalDAV) protocol.7 Lisa Jim CalDAV in a Nutshell CalDAV The base CalDAV protocol provides three main CalDAV CalDAV features: CalDAV • Calendar maintenance. Users can create multi- Lisa's calendar Jim's calendar ple personal calendars (one each for work, con- March March OSAF UCSC ference time slots, home, and so on) via a new CalDAV server CalDAV server mkcalendar method. • Calendar queries. People can search other people’s calendars for free/busy times, or they can discover who is participating in a given meeting. Calendar applications can use queries to Figure 2. Scheduling across an organizational boundary. Lisa and Jim discover when to-do list items are due, and a work for two separate organizations and need to schedule a flexible new report type supports a wide meeting. Using her CalDAV calendar client, Lisa first searches their range of calendar queries. calendars for free/busy times on the day she’d like to meet. She then • Calendar security. Users can control how sends a meeting invitation, which appears in Jim’s event inbox. Jim much of their calendars are visible to others, accepts the meeting and updates the calendars to show this. and who has permission to change them, by using CalDAV extensions to the WebDAV access control protocol. will let people using calendar applications make and reply to meeting invitations with a new Using the same framework, a separate draft will schedule method along with inbox and outbox build on the core CalDAV specification to provide collections, and invitation fanout (replication) optional scheduling workflow functionality. This rules. Meeting participants can be from a single

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2005 83 Standards Track

>> Request << requests. Calendar applications can also delete and write them as whole resources by using delete and GET /bernard/calendar/inbox/mtg456.ics HTTP/1.1 put. Although this is more a description than a def- Host: cal.example.com inition, it’s useful to help decide what to represent as resources in a given application. What size object >> Response << should have its own address? What size resource is most useful to download or upload? What size HTTP/1.1 200 OK resource is most useful to create or destroy? Date: Thu, 02 Sep 2004 17:05:23 GMT Within the iCalendar data format used by Cal- Content-Type: text/calendar DAV, a calendar is composed of events, each repre- Content-Length: xxxx senting some activity a person or group will attend — meetings, appointments, performances, trips, or BEGIN:VCALENDAR essentially anything with a start and end time. VERSION:2.0 In CalDAV, every event is represented as a PRODID:-//Example Corp.//CalDAV Server//EN resource, and resource contents are represented on BEGIN:VEVENT the wire in the iCalendar text format.2 Given that DTSTAMP:20040901T200200Z user operations often involve single calendar DTSTART:20040902T130000Z events, being able to provide a URL as an address DTEND:20040902T140000Z for each event and to create, delete, or overwrite SUMMARY:CalDAV draft review them is very convenient. UID:[email protected] It might also be useful to have URLs and oper- ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE= ations for an event’s individual properties (such INDIVIDUAL;CN=Lisa as its location, or start and end times), but that Dusseault:http://cal.example.com/lisa/inbox/ level of granularity is not required for reasonable performance. Although some use cases involve ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ- changing only an event’s location, it’s possible to PARTICIPANT;CUTYPE=INDIVIDUAL; do so within reasonable transmission and pro- CN=Bernard cessing times by rewriting the whole event. There Desruisseaux:http://cal.example.com/bernard/inbox/ aren’t strong use cases for creating a resource that represents an event location without an event that ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ- has that location. The working group made a sim- PARTICIPANT;CUTYPE=INDIVIDUAL; ilar choice with the iCalendar standard in defin- CN=Cyrus Daboo:http://cal.example.com/cyrus/inbox/ ing event properties (except for timezone) only END:VEVENT within the context of an actual event. To keep END:VCALENDAR things simple, CalDAV doesn’t define URLs for event properties. Figure 3. Using HTTP get for a calendar event. The request shows Given that CalDAV represents calendar events an HTTP get submitted to a CalDAV server to retrieve a calendar as HTTP resources, the protocol must decide event. The response shows an iCalendar event in the HTTP response which body and MIME type to assign these body with a MIME type of text/calendar. The meeting is titled, resources; this choice determines what the result “CalDAV draft review,” has three participants, and occurs on 2 of a get looks like. The working group opted to September 2004, from 13:00 to 14:00 hours. use the iCalendar standard to represent all event data within the HTTP resource’s body. This makes use of existing work on the iCalendar standard, organization or span many. A person sends a software libraries that implement iCalendar, and meeting invitation by instructing the calendar iCalendar interoperability experience. In fact, application to invoke schedule to place the meet- Web servers can already store files with the MIME ing in their outbox, thereby causing invitations to type “text/calendar,” and it’s not unusual for be placed in other attendee inboxes. existing Web browsers to dispatch downloaded iCalendar files to calendar applications to handle Modeling Calendaring appropriately. Figure 3 shows an HTTP get Objects as HTTP Resources request for an iCalendar-formatted event stored HTTP resources have URLs and respond to get on a CalDAV server.

84 MARCH • APRIL 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING CalDAV

Recurring Events CalDAV server collects them into calendars that A calendar repository needs a clear model of how roughly represent the time commitments for a to deal with recurring events. Imagine the confu- given person, object, or place. Sometimes it’s useful sion if one client represented recurrences as a to see a single event, but other times we need the property but another client couldn’t understand contents of a whole calendar or some time-slice the syntax and saw only one instance of the event. thereof. For reasonable synchronization, it also The situation gets even more complex when we helps to see which events have been added or start modifying recurrences. The specification thus removed since the last calendar synchronization. needs to be clear on whether a client can modify In these use cases, CalDAV uses the WebDAV an existing resource or must create a new one to collection resource to model calendars. A WebDAV create a new instance of a recurring event. collection provides a way to list its resources in a The choice of iCalendar provides guidance here clear, flexible, and machine-parsable (XML) way. because it almost always represents a recurring And because we’ve already defined events as event as a single component with a set of recur- resources, WebDAV operations work on events and rence dates or patterns. Following this pattern calendars in a straightforward way: allows CalDAV to represent even infinitely recurring events in a noninfinite space — a definite plus • To list all events in a calendar, use propfind on for synchronizing an entire calendar. the calendar URL. • To list all the calendars in a certain area of a Using HTTP Features on Calendars repository, use propfind on the appropriate URL. With iCalendar events mapped to resources, we • To copy an event to another calendar or cre- can use base HTTP to quickly solve an important ate a duplicate event within one calendar day, set of use cases for CalDAV: use copy. • To rename an event or move it to another cal- • To download an event, a calendar application endar, use move. uses get and interprets the body of the • To lock an event or to lock an entire calendar response as an iCalendar file. while making changes, use lock/unlock. • To create a new event, the application uses put • To synchronize a calendar that has been down- (and an unmapped URL) and sends an iCalen- loaded before, use propfind and ask for the dar file in the request body. getetag WebDAV property, which provides the • To overwrite an existing event or to change its HTTP ETag value and shows new resources and location, time, or attendees, the calendar appli- changed and unchanged ETags, and omits cation sends a put request to an existing event deleted resources. URL with the new values for the event in the iCalendar-formatted request body. WebDAV also defines the mkcol method, which • To delete an existing event, the application uses creates collections of resources, but CalDAV uses a delete on the event URL. different method because a calendar is a bit more • To check whether an event has changed since than an ordinary collection, and the CalDAV client last downloaded, the application uses the must signal that intention to the server. HTTP ETag. New CalDAV Mechanisms Although HTTP supports many useful calendar The native capabilities of HTTP and WebDAV sup- operations on its own, it has its limits. HTTP has port many useful calendar-retrieval and update no capability for listing all of a person’s calendar scenarios. However, it is necessary to extend Web- events or preventing collaborators from overwrit- DAV’s core capabilities to provide rich support for ing a shared calendar. The WebDAV protocol does calendar queries for free/busy times, creating col- support these functions; hence, CalDAV builds on lections of events, and supporting meeting invita- both HTTP and WebDAV. tion workflows.

Using WebDAV Features on Calendars Querying Calendars The functionality WebDAV provides on top of HTTP The major use case that the HTTP and WebDAV is also important to CalDAV. Events aren’t com- methods we’ve described so far can’t handle is the pletely unassociated with each other; instead, a ability to search a calendar. A generic search

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2005 85 Standards Track

mechanism that names properties and property mkcalendar request to the server, which creates a values might seem attractive, but it doesn’t work calendar (if it can) in a user’s calendar storage well when dealing with time ranges and recur- space on a CalDAV-compliant server. The server rences, which are necessary complications of the automatically assigns the correct resourcetype event model defined in iCalendar. Alternatively, it value, which enables other clients to detect that the is possible to download a copy of someone else’s new resource is a calendar that contains events. calendar and then perform free/busy queries over this local data. Calendars typically have many Scheduling Meetings entries, and the time required to download a local with Base CalDAV and iMIP copy is far greater than asking a server to perform Scheduling meetings is already possible with the the equivalent free/busy query. CalDAV features we’ve discussed (all of which are When scheduling a meeting, the most common described in the core CalDAV specification). A use case is to request all events in a given time client can use a report to view another user’s range. To schedule a meeting with a busy cowork- free/busy time, and then use the iMIP standard to er, for example, you might want to see her sched- send an invitation over email. CalDAV increases ule for the next week, including all recurring the likelihood that the meeting invitation will meetings and any multiday meeting that overlaps avoid time conflicts. with the next week. This isn’t a complicated Although this approach works for many request, given a syntax that’s tailored to time- applications, however, it’s not sufficient for range objects. enterprise-level calendaring and scheduling. In CalDAV solves this by borrowing the report existing systems (using proprietary protocols), syntax defined in RFC 37448 and defining a the server generally does more to help schedule calendar-specific time-range report.9 This report — in part, to improve the user experience, but provides a way to compile information in a single also to help address email’s shortcomings as an request and response that would be prohibitively application transport. expensive to collect using only get and propfind These shortcomings arise from the history and requests. At the same time, this report solves the practice of handling email and spam. Mail can be problem already noted of expanding recurring delivered through several mail-transfer agents events and identifying which events occur in a (MTAs) before arriving at one or more mail user given time range. If the client asks for all events agents (MUAs), as the IETF calls mail-reading with start times after 8 a.m. this morning and end applications. This architecture works great for times before midnight tonight, for example, it email, but it was never designed to deal with could miss recurrences. With a report, on the things like iCalendar invitations. Some of the prob- other hand, the server can perform the necessary lems it presents include: time and recurrence calculations and provide the exact set of events that should show up in a given • How does calendaring software know which time period. MUA will receive invitations? • How do MUAs know which application to send Identifying and Creating Calendars invitations to? The need to be able to identify calendars follows • Some email software bypasses these last two from the need to support special reports on them. issues with an integrated calendar module, but To treat a collection as a calendar, the client has to what if users want to manage their calendars both know that it is a calendar and support the cal- with a different application? endaring functionality. The mechanism that Web- • What does the MUA on a PDA or cell phone DAV defines for this purpose is the resourcetype do with an invitation if no calendar software property, and CalDAV defines a new value for it: is available? CALDAV:calendar. • What do MUAs do with invitations that appear The need for a special mechanism to create cal- in inboxes? endars then follows from the need to identify • How do multiple MUAs — each of which will them. To ask servers to create calendars, clients discover a given invitation in the user’s email need a method that indicates what kind of resource inbox — know which MUA should deal with the to create and what functionality to provide on it. invitation and whether it can be deleted? In CalDAV, the client simply sends a • What do MUAs do with invitations that have

86 MARCH • APRIL 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING CalDAV

Learning More about Calendaring

nformation about Internet calendaring Message-Based Interoperability Pro- page about CalDAV efforts (www. Iand scheduling is tricky to find because tocol (iMIP), and Calendar Access calconnect.org/tc-caldav.html). it is spread across multiple unconnected Protocol (CAP) specifications. It also • Lisa Dusseault’s book, WebDAV: Next- Web sites.Unfortunately, no books cover maintains a rich list of pointers to Generation Collaborative Web Authoring the iCalendar standards, but the following calendaring products, articles, and (Prentice-Hall, 2004), provides a list highlights some of the best sources of open-source projects. detailed description of the WebDAV, information about iCalendar,CalDAV,and • The Internet Society’s Internet Report Access Control, and DeltaV protocols. WebDAV. site houses the most recent CalDAV • Julian Reschke’s Greenbytes WebDAV specification, along with its revision page (www.greenbytes.de/tech/webdav/) • The CalDAV Resources site has links history (http://ietfreport.isoc.org/idref/ tracks ongoing activity in the WebDAV to the CalDAV mailing list, protocol draft-dusseault-caldav/). protocol space including the CalDAV drafts, and recent CalDAV news (http:// • The Open Source Applications Foun- speciﬁcation. ietf.webdav.org/caldav/). dation maintains the CalDAV mailing • Finally, last issue’s Standards track • The IETF’s Calendaring and Scheduling list, which is open to all (http:// article, “WebDAV: Versatile Col- working group (www.calsch.org) main- lists.osafoundation.org/mailman/listinfo/ laboration Multiprotocol” (IEEE In- tains a list of calendaring RFCs and ietf-caldav). ternet Computing, Jan./Feb. 2005, pp. revision histories for the iCalendar, • The Calendaring and Scheduling 66–74), provides an overview of iCalendar Transport-Independent Inter- Consortium’s CalDAV Technical recent activity in the IETF WebDAV operability Protocol (iTIP), iCalendar Committee maintains a limited Web working group.

already been moved to another folder, possibly CalDAV server’s assistance. This work is still in by categorization rules or by another MUA? greater flux than the base specification, partly because the challenges are a little more difficult. Recent antispam measures have made meeting With WebDAV, clients access stored resources, scheduling using iMIP even more difficult. MTAs rather than receive them from servers. It assumes often alter or block messages with unrecognized that resources are somewhat stable, so the model attachments, and MUAs could mark calendar invi- doesn’t fit as well for applications in which mes- tations as spam. sages are generally in transit. Thus, it’s tempting Finally, to make scheduling workflows more to treat scheduling as a simple repository-access effective, existing enterprise calendaring systems problem: to schedule with Jim, Lisa should create include mechanisms for receiving and recognizing an event in his calendar, and vice versa. invitations before they’re even delivered to the cal- The straightforward repository-access approach endar application. While on vacation, users often doesn’t suit the way users handle events. Rather leave their computers off, so they aren’t checking than letting everyone who is allowed to invite for, accepting, or publishing invitations on the her to meetings simply put them on her schedule server. In the meantime, coworkers might want to — implying confirmed attendance — Lisa wants schedule meetings for as soon as vacationers to treat each new scheduling item as a request to return. When a calendar server can receive and be reviewed. handle invitations on a user’s behalf, it can tenta- The authors of CalDAV’s scheduling support are tively place such invitations on the user’s pub- currently looking at scheduling inbox collections lished calendar. Although the meetings aren’t yet to solve that problem. Jim could put a request in accepted, coworkers can see which blocks of time Lisa’s scheduling inbox, where it would be consid- might already be filled, so they can try to find ered tentative until she moved it to the main cal- unrequested times for other meetings. endar. This approach seems to work better with common scheduling workflows, but it still leaves Scheduling using CalDAV Directly many unresolved details. For example: Given the advantages of scheduling via a calendar server rather than email, the CalDAV specification • If Jim can place events in Lisa’s scheduling authors already have a separate draft in progress inbox, does that mean he can change events in to define how to solve scheduling use cases with a that collection, including the one he created?

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2005 87 Standards Track

• When Lisa accepts a request, does the client put it Currently, the Calendaring and Scheduling on the calendar, or does the server handle that? Consortium (www.calconnect.org) is contributing • Is there more than one scheduling inbox if Lisa to the requirements for CalDAV and supporting has more than one calendar? interoperability testing events. Although it isn’t a • What happens to a meeting request after Lisa standards organization, CalConnect is working to accepts it? improve the interoperability of calendaring and • Can a user review the request history for a scheduling applications as well as public aware- meeting, including updates as well as the orig- ness of standards in this area. inal request? Isamet (client), Oracle (server), Mozilla (open- • Can a user review the history of outgoing source client), and Slide (open-source server) requests, including acceptances and requests have already begun developing CalDAV imple- that counter a suggested meeting time with mentations. The first interoperability test event an alternate? took place in January 2005, and demonstrated CalDAV interoperability among two servers and The CalDAV draft authors and CalDAV mailing list three clients. participants are currently discussing how to resolve these issues. ork continues on refining the CalDAV specifi- CalDAV Status Wcation according to implementation experi- After consuming significant committee time in ence, and those involved expect to make the first debates over requirements, scope, and basic model deployment of CalDAV capabilities available to assumptions, previous attempts at standardizing a users within the coming year. Once CalDAV protocol for calendar access proved inconclusive. demonstrates a track record of interoperability and Part of the difficulty is that many different mod- the base of users working with CalDAV-aware els exist and work well for the applications that clients and servers increases, we expect other cal- use them. Although it’s possible in many software endar client applications and servers to adopt it — areas to define a single standard that encompass- especially given that CalDAV is the only viable es most of the features in existing nonstandard calendaring access protocol. applications, this hasn’t proven feasible for calen- CalDAV will help millions of users schedule daring applications. Instead of a committee meetings within and across organizations using approach, the dedicated work of a few like-minded their PCs, personal information managers, and cell individuals thus seems likely to make more phones. It will remove much of the accidental progress at this point. complexity of gathering people together for a Because CalDAV is an individual submission to common purpose, freeing us for more creative and the IETF, the current work on it is in the hands of productive work. Moreover, because open stan- the draft authors: dards beget open-source implementations, CalDAV promises to bring advanced calendar scheduling • Cyrus Daboo, chief technology officer of Isamet capabilities to families, small nonprofits, schools, (www.isamet.com), and many others for whom current calendar tech- • Bernard Desruisseaux, who works on the Oracle nology is too complex and expensive. Calendar server (www.oracle.com/collabsuite/), and References • Lisa Dusseault, of the Open Source Application 1. “More than 20 Companies Join Netscape to Help Define Foundation (www.osafoundation.org). Open Standard for Internet Calendaring and Scheduling,” press release, Netscape Communications, 24 July 1996; To streamline the standardization process, they http://wp.netscape.com/newsref/pr/newsrelease194.html. plan to develop CalDAV quickly in a small but 2. F. Dawson and D. Stenerson, Internet Calendaring and open group. They welcome input, either in person Scheduling Core Object Specification (iCalendar), RFC 2445, or through the open mailing list at http://lists. Nov. 1998; www.ietf.org/rfc/rfc2445.txt. osafoundation.org/mailman/listinfo/ietf-caldav. 3. S. Silverberg et al., iCalendar Transport-Independent Inter- Once they have a stable proposal with interopera- operability Protocol (iTIP) — Scheduling Events, Busy Time, ble implementations, the authors plan to introduce To-Dos, and Journal Entries, RFC 2446, Nov. 1998; www. CalDAV fully into the IETF standardization process. ietf.org/rfc/rfc2446.txt.

88 MARCH • APRIL 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING CalDAV

4. F. Dawson, S. Mansour, and S. Silverberg, iCalendar Mes- is responsible for email, calendaring, and general sharing sage-Based Interoperability Protocol (iMIP), RFC 2447, Nov. protocols for Chandler, a personal information manager. 1998; www.ietf.org/rfc/rfc2447.txt. Dusseault is currently cochair of the IETF WebDAV working 5. M. Rose, The Blocks Extensible Exchange Protocol Core, group as well as the iMap Extensions WG, and she partic- RFC 3080, Mar. 2001; www.ietf.org/rfc/rfc3080.txt. ipates regularly in other IETF work particularly relating to 6. Y. Goland et al., HTTP Extensions for Distributed Authoring HTTP and Instant Messaging (XMPP). She has a BS in sys- — WebDAV, RFC 2518, Feb. 1999; www.ietf.org/rfc/ tems design engineering from the University of Waterloo. rfc2518.txt. Contact her at [email protected]. 7. C. Daboo, B. Desruisseaux, and L. Dusseault, “Calendaring and Scheduling Extensions to WebDAV (CalDAV),” IETF Jim Whitehead is an assistant professor in the Department of Internet draft, Feb. 2005; work in progress. Computer Science at the University of California, Santa 8. G. Clemm et al., Web Distributed Authoring and Version- Cruz. He founded the IETF WebDAV WG and served as its ing (WebDAV) Access Control Protocol, RFC 3744, May chair from its inception in March 1997 through March 2004; www.ietf.org/rfc/rfc3744.txt. 2004. His research interests include collaborative author- 9. G. Clemm et al., Versioning Extensions to WebDAV, RFC ing, software conﬁguration management, software evolu- 3253, Mar. 2002; www.ietf.org/rfc/rfc3253.txt. tion, and Web engineering. Whitehead received a PhD in information and computer science from the University of Lisa Dusseault is a development manager and standards archi- California, Irvine. He is a member of the ACM, Usenix, and tect at the Open Source Application Foundation, where she the IEEE. Contact him at [email protected].

PURPOSE The IEEE Computer Society is the EXECUTIVE COMMITTEE world’s largest association of computing profes- President: sionals, and is the leading provider of technical GERALD L. ENGEL* information in the field. Computer Science & Engineering MEMBERSHIP Members receive the month- Univ. of Connecticut, Stamford ly magazine Computer, discounts, and opportu- 1 University Place nities to serve (all activities are led by volunteer Stamford, CT 06901-2315 members). Membership is open to all IEEE Phone: +1 203 251 8431 members, affiliate society members, and others Fax: +1 203 251 8592 interested in the computer field. [email protected] President-Elect: DEBORAH M. COOPER* COMPUTER SOCIETY WEB SITE Past President: CARL K. CHANG* The IEEE Computer Society’s Web site, at VP, Educational Activities: MURALI VARANASI† www.computer.org, offers information and COMPUTER SOCIETY OFFICES VP, Electronic Products and Services: samples from the society’s publications and con- JAMES W. MOORE (2ND VP)* ferences, as well as a broad range of information Headquarters Office VP, Conferences and Tutorials: about technical committees, standards, student 1730 Massachusetts Ave. NW YERVANT ZORIAN† activities, and more. Washington, DC 20036-1992 VP, Chapters Activities: BOARD OF GOVERNORS Phone: +1 202 371 0101 CHRISTINA M. SCHOBER* VP, Publications: MICHAEL R.WILLIAMS (1ST VP)* Term Expiring 2005: Oscar N. Garcia, Fax: +1 202 728 9614 Mark A. Grant, Michel Israel, Rohit Kapur, VP, Standards Activities: SUSAN K. (KATHY) LAND* Stephen B. Seidman, Kathleen M. Swigger, Makoto E-mail: [email protected] VP, Technical Activities: STEPHANIE M. WHITE† Takizawa Secretary: STEPHEN B. SEIDMAN* Term Expiring 2006: Mark Christensen, Publications Office Treasurer: RANGACHAR KASTURI† Alan Clements, Annie Combelles, Ann Q. Gates, 10662 Los Vaqueros Cir., PO Box 3014 2004–2005 IEEE Division V Director: GENE F.HOFFNAGLE† James D. Isaak, Susan A. Mengel, Bill N. Schilit Los Alamitos, CA 90720-1314 Term Expiring 2007: Jean M. Bacon, George V. 2005–2006 IEEE Division VIII Director: Phone:+1 714 821 8380 STEPHEN L. DIAMOND† Cybenko, Richard A. Kemmerer, Susan K. (Kathy) E-mail: [email protected] Land, Itaru Mimura, Brian M. O’Connell, Christina 2005 IEEE Division V Director-Elect: Membership and Publication Orders: M. Schober OSCAR N. GARCIA* Next Board Meeting: 11 Mar. 2005, Portland, OR Phone: +1 800 272 6657 Computer Editor in Chief: DORIS L. CARVER† Fax: +1 714 821 4641 Executive Director: DAVID W. HENNAGE† IEEE OFFICERS E-mail: [email protected] * voting member of the Board of Governors President: W. CLEON ANDERSON † nonvoting member of the Board of Governors President-Elect: MICHAEL R. LIGHTNER Asia/Pacific Office Past President: ARTHUR W. WINSTON EXECUTIVE STAFF Executive Director: TBD Watanabe Building Executive Director: DAVID W. HENNAGE Secretary: MOHAMED EL-HAWARY 1-4-2 Minami-Aoyama,Minato-ku Assoc. Executive Director: ANNE MARIE KELLY Treasurer: JOSEPH V. LILLIE Tokyo107-0062, Japan Publisher: ANGELA BURGESS VP, Educational Activities: MOSHE KAM Phone: +81 3 3408 3118 Assistant Publisher: DICK PRICE VP, Pub. Services & Products: LEAH H. JAMIESON Fax: +81 3 3408 3553 Director, Administration: VIOLET S. DOAN VP, Regional Activities: MARC T. APTER E-mail: [email protected] Director, Information Technology & Services: VP, Standards Association: JAMES T. CARLO ROBERT CARE VP, Technical Activities: RALPH W. WYNDRUM JR. Director, Business & Product Development: IEEE Division V Director: GENE F.HOFFNAGLE PETER TURNER IEEE Division VIII Director: STEPHEN L. DIAMOND President, IEEE-USA: GERARD A. ALPHONSE

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2005 89