Last Modified: 2004-02-10
The group will exist to create standards that make calendaring and scheduling software significantly more useful and to enable a new class of solutions to be built that are only viable if open standards exist. The Calendaring and Scheduling Working Group is chartered to focus on Internet standards for three basic problems facing group scheduling and calendaring users today. These include the following:
1. A standard content type for capturing calendar event and to-do information. The content type should be suitable as a MIME message entity that can be transferred over MIME based email systems or HTTP World Wide Web. The basic objects along with their representation using MIME will be specified in the document entitled "Core Object Specification".
2. A standard peer-to-peer protocol for common calendaring and group scheduling transactions. For example, these may include exchanging over the Internet, event-requests, reply to vent-requests, cancellation notices for event-requests, requesting free/busy time and replying to free/busy time requests between different calendaring products. The working group will undertake this work in two phases, with the first phase focusing on meeting requests and the second phase on free-busy time. To the extent that the peer-to-peer protocol has requirements related to security, the working group will attempt to apply existing Internet standards for authentication, and to assure privacy and integrity of sensitive calendaring information. The protocol for the interoperable transactions will be specified in a document called "Calendar Interoperability Protocol" in the milestone list.
3. A standard access protocol to allow for the management of calendars, events and to-dos over the Internet. This protocol will be specified in the document called "Calendar Access Protocol" in the milestone list.
This working group effort should be developed and stabilized with a 6-9 months since there has been considerable prior work done in this area. This prior body of work includes:
* Distributed Scheduling Protocol (CHRONOS) IETF Working Group
* ISO/IEC SC18 Distributed Office Application for Calendaring, Scheduling and Appointments
* MHS Alliance Calendaring and Scheduling Interoperability Protocol (CSIP)
* X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) and Calendaring and Scheduling Interoperabilty Specification (CSIS)
* X/Open Consortium Calendaring and Scheduling (XCS) Implementor's Specification
* Versit vCalendar format
The working group will focus on harmonizing, evolving and developing protocols and algorithms based on this work. The process is subject to extension if many new features are added, or more revision is needed.
Done | Submit core object specification as Internet-Draft. | |
Done | Submit first Internet-Draft of Calendar Interoperability Protocol. | |
Done | Submit second draft of core object specification as Internet-Draft. | |
Done | Submit revised Internet-Draft of Calendar Interoperability Protocol. | |
Done | Submit core object specification to IESG for consideration as a Proposed Standard. | |
Done | Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft. | |
Done | Submit Internet-Draft (informational) on Guide to Implementors using Calendaring Protocols | |
Feb 01 | Hold second CalConnect Interoperability Testing on iCalendar, iMIP and iTIP | |
Mar 01 | Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard. | |
Jul 01 | Request last call on Guide to Internet Calendaring | |
Jul 01 | Submit Internet-Draft on Guide to Internet Calendaring for consideration as a Proposed Standard | |
Jul 01 | Submit revisions for Internet-Draft for iCalendar, iMIP and iTIP | |
Jul 01 | Submit revisions for Internet-Draft for Calendar Access Protocol | |
Jan 02 | Evaluate readiness for interoperability testing of Calendar Access Protocol |
RFC | Status | Title |
---|---|---|
RFC2445 | PS | Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
RFC2446 | PS | iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries |
RFC2447 | PS | iCalendar Message-based Interoperability Protocol (iMIP) |
RFC2739 | PS | Calendar attributes for vCard and LDAP |
RFC3283 | I | Guide to Internet Calendaring |
IETF calsch WG meeting IETF 59, Seoul, South Korea 2004-03-02 submitted by RL "Bob" Morgan also thanks to Lisa Dusseault for Jabber scribing The meeting was called to order at 1415 by co-chair RL "Bob" Morgan. The first agenda item was WG status. Bob noted that finishing CAP is the main thing, and that a proposed charter revision reflecting this, with some possible new work items, and new milestones, had been sent to the list. Ted Hardie, the WG's area director, said that accurate milestones would be good, but that it is important to have identified authors for all charter work items; it would also be good to know if people are actually implementing CAP. Doug Royer said (via Jabber) that he, Novell, and Oracle are implementing CAP. Cyrus Daboo (also via Jabber) commented that he is more interested in caldav first, then CAP later. Lisa Dusseault said that CAP is not well-suited to the product of her new employer, the Open Source Application Foundation, which prefers a smart client model. Bob said that the University of Washington is implementing a CAP server. Nathaniel Borenstein of IBM said that IBM is not implementing CAP, and that to his knowledge Microsoft is not either. Ted asked if these are all server implementations. Doug noted that his implementation will include clients. Bob said that a lack of CAP implementors might lead us to abandon taking CAP to standardization, but that doesn't seem to be the situation. Doug noted that some implementors will wait until CAP reaches RFC status. Bob also noted that there are some who say that CAP has major flaws or is unsuited for their use, but this is hard to express as an issue with the CAP document per se. What effect this type of comment might have on our WG direction isn't clear. Bob asked if there were further issues to raise regarding CAP at this time, deferring discussion of items already raised on the list or via bugzilla. Nathaniel expressed support for Lisa's comment about the CAP "smart server" model being the wrong one, and that a model where the calendar server is a store would be better. He also expressed concern with the iCal spec, that it suffers from ambiguity that makes interoperability difficult to achieve in any but the simplest of cases. Doug commented that iCal and CAP are large because support for real-time scheduling and coordination is complex. Bob said that proceeding to last call with CAP and handing some of these assessments to the IESG might be the best way to get resolution expeditiously. Ted said that while there is no requirement for there to be implementations for a doc to be a Proposed Standard, there is a requirement for serious review, preferably by implementors. So he urged the chairs to require some number of real reviews before progressing the doc. Doug said that since CAP is big, many people want to wait until the WG says it's ready. There being no more comments on this or other topics, the WG adjourned at 1436. |