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 |
| RFC | Status | Title |
|---|---|---|
| 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 <leg+@andrew.cmu.edu>
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
|