Last Modifield: 01/21/2002
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 second draft of core object specification as Internet-Draft.|
|Done||Submit first Internet-Draft of Calendar Interoperability Protocol.|
|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|
|RFC2446||PS||iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries|
|RFC2445||PS||Internet Calendaring and Scheduling Core Object Specification (iCalendar)|
|RFC2447||PS||iCalendar Message-based Interoperability Protocol (iMIP)|
|RFC2739||PS||Calendar attributes for vCard and LDAP|
|RFC3283||I||Guide to Internet Calendaring|
Calendar & Scheduling Working Group minutes, Wed Nov 20 reported by Larry Greenfield <firstname.lastname@example.org> Bob Mahoney is chairing. Chair, introduction & agenda bashing Chair, status of drafts CAP is very long lived and still changing. More eyeballs are needed and encouraged! xCal has been in and out of the working group. We didn't want to get distracted from our major goal (CAP) but maybe it's possible for us to do work on xCal without getting too distracted. Chair, interop results Novell intended to hold a physical interop, but not enough participants would have been able to come. Instead a virtual interop was held with IBM/Lotus, Oracle/Steltor, Novell, and KOrganizer participating: exchanging calendar objects and participating in conference calls. We need a better feature matrix if we want to move iCal to draft; anyone interested in doing so should volunteer. Drop a note to the chairs if you would like info on how to help. Chair, point of information There's a Java iCal parser at http://www.sourceforge.net/project/jical/. Pekka Pessi, iTIP SIP binding "iSIP" draft-pessi-calsch-isip-00.txt iSIP currently uses xCal ("it seemed like a good idea at the time") but the iCal format might actually be more extendable and more suited for our purposes. iSIP doesn't conflict with the current calsch work. Should it be part of calsch? What interesting applications are enabled by iSIP? The chair pointed out that the WG is already way overdue on some milestones so it might not be that wise to take more stuff on. Paul Hill asked why this wasn't being done in SIPPING; Pekka replied that SIPPING is very crowded and has many requirements and the calendar expertise is here. Aki Niemi thought that SIPPING had shown some interest. Chris Newman pointed out that there needs to be applicability of when to use iSIP instead of or in addition to iMIP and iRIP. Chair, mailing list The mailing list can seem unfriendly or imposing but don't let us old bitter people scare you. Please participate! Chris Newman, some issues with CAP Issue #1: How are calendars named and how do clients discover calendars available. Clients need to be able to find out what calendars it can access: private, shared, and public calendars. Larry Greenfield and Paul Hill discussed that this was brought up some time ago, and Paul talked about how the various subscription models of the calendars can be fairly confusing. Disagreements about what the namespace is makes coming to consensus hard. Chris pointed out that the mailbox namespace is one of the worst parts of IMAP interoperability, and committed himself to drawing an analogy between IMAP and CAP namespace on the mailing list. Issue #2: What should the mandatory to implement security be? Chris recommends requiring implementations support TLS with the SASL mechanism PLAIN, since it deploys much better than DIGEST-MD5. Kurt Zeilenga agrees. Issue #3: Multiple connections versus BEEP channels. The current draft doesn't discuss whether servers have to process channels in parallel or if processing on one channel can block the other channels. If clients only make a single TCP connection, rate limiting and other accounting is much easier---but if clients have to open multiple connections to keep long running operations from blocking, they will. Larry Greenfield said that requiring parallel processing of channels is a barrier to implementation and it isn't clear how to write an on-the-wire specification requiring it. Some discussion on Jabber with Marshall Rose and Larry Greenfield. Patrick Falstrom said that understanding congestion control/resource allocation on the application layer is a general concern for the IETF but no one has any good ideas. Issue #4: Round trips are very expensive; pipelining should be mandatory. meeting adjourns