2.1.2 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Bob Mahoney <bobmah@mit.edu>
Pat Egen <pregen@egenconsulting.com>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

General Discussion:ietf-calendar@imc.org
To Subscribe: ietf-calendar-request@imc.org
Archive: http://www.imc.org/ietf-calendar/mail-archive/

Description of Working Group:
Calendaring and group scheduling products are well established for organizational use, but they usually are limited to exchange of information among users of the same system, usually within the boundaries of a single organization. This working group will pursue development of standards to enable different products to interoperate and to work across organizational boundaries. This work will include the development of MIME content types to represent common objects needed for calendaring and group scheduling transactions and access protocols between systems and between clients and servers. The working group will also consider and recommend solutions to the security issues concerning the exchange of calendar information between network entities.

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.

Goals and Milestones:



Submit core object specification as Internet-Draft.



Submit second draft of core object specification as Internet-Draft.



Submit first Internet-Draft of Calendar Interoperability Protocol.



Submit revised Internet-Draft of Calendar Interoperability Protocol.



Submit core object specification to IESG for consideration as a Proposed Standard.



Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft.



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

Request For Comments:






Internet Calendaring and Scheduling Core Object Specification (iCalendar)



iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries



iCalendar Message-based Interoperability Protocol (iMIP)



Calendar attributes for vCard and LDAP

Current Meeting Report

Calendaring and Scheduling Working Group (WG) (calsch)

WEDNESDAY, March 21 at 1530-1730

CHAIRS: Pat Egen <pregen@egenconsulting.com>, Bob Mahoney <bobmah@MIT.EDU>
REPORTER: Walter Houser <houser.walt@forum.va.gov>

1. Agenda Tweaks - Bob Mahoney

2. IPTEL/CALSCH issues - John Stracke


The IPTEL Working Group wants to use iCAL recurrence rules (RRULES) in their Call Processing Language (CPL). CPL has to run in a telephony switch where CPU and memory are expensive. So IPTEL needs to pick and choose which rules apply, and has tried to severely limit the functionality owing to the limited flexibility and capacity of telephony hardware. CPL defines a subset of the iCAL recurrence rules.

The IPTEL document is currently blocked, due to questions about compatibility with iCalendar. Consequently, we need to harmonize iCAL and CPL. The hope is to define a common subset. Unfortunately, for IPTEL, iCAL rules are capable of extremely complex expression. Vendors could develop User interfaces (UI) that implement disjoint subsets which would not interoperate. John has written a draft subset of RFC 2445 which he will submit after this meeting.

Jonathan Lenox (Columbia Univ) from the IPTEL WG, noted that there is no obvious way to determine what iCAL RRULE functionality is reasonable and what is not. For example, IPTEL needs to have the duration less than the minimum unit. But there is no barrier to absurdity. Bob said we would take this issue to the list.

3. CAP status - Steve Mansour/George Babics

The latest draft cleans up and fixes a number of issues. However, there are no fundamental changes made to CAP. Remaining issues:

- CAP may be too complex to readily implement. (Steve addressed this point in detail later in the meeting)
- Restriction tables are tricky and detailed; they require careful review.
- There are a number of unresolved issues in these tables.
- These tables need to be consistent with iTIPS tables.
- How do VCARs apply to a calendar hierarchy? - How should we handle decreed VCARs?
- We need to list and submit IANA entries. - We need to verify current examples and add more examples.
- We need to review the CAP requirements draft to ensure each is being addressed or explained away.
- We need to verify security and whether VCARs are sufficient.
- Add new properties to the restriction tables.

We need people to verify the features in the iCAL and CAP documents.

4. CALSCH.ORG web site -Bob Mahoney

The CALSCH.ORG site is up, and being sponsored at MIT. It has current and expired WG documents, as well as a list of vendors implementing calsch protocols. However, there are a number of features we could add; suggestions are welcome. (see www.webdav.org as an example of what is intended)

5. Have we bit off more than we can chew? -Steve Mansour

Are the sheer size of the documents and scope of effort impeding adoption of these standards? Recent edits to the CAP draft cut the size down from 150 to 116 pages. (This was largely through the removal of the SCHEMA section to the next rev of iCalendar) Nevertheless, Steve recalled Tony Small (Microsoft) who was ruthless in fighting additional features he felt were "too complex". And now Steve is concerned that Tony may have been right, and that over complexity is hindering adoption. We need high adoption and interoperability between vendors in order to succeed. The implementation of interoperable standards will grow the market for the calendaring products.

How are things going? Four vendors showed at the first Calconnect. We saw limited METHOD support, yet we added a lot of stuff to iTIP that has not been implemented such as RRULES and MIME wrappers. Are any vendors implementing VJOURNALS?

Why so little progress? Calendaring and scheduling is just inherently complicated. In contrast, mail is a static document, saved in publicly writable inboxes. CAP is even more complex than iTIP, and there is concern that many vendors are holding back, and waiting for the market to develop.

What do we do? If no one implements the RFC, it's worthless. Ine suggestion to reduce complexity is to remove as many of the SHOULDS as possible, focusing on features that will maximize implementations. Another possibility is to eliminate fanout in CAP. Currently, it is in CAP as a definition, with the implication that it be implemented, but not fully specified. But if we push for implementation of fanout, we will have a lot of work to do with respect to access control, which will add greatly to the size and complexity of the document.

Dave Crocker commented that fighting complexity is the right thing to do. He felt the WG must get rid of as many SHOULDs as possible. One of the keystones of a successful IETF WG is to take the intersection of the suggested features, not the union of the requirements. If the feature is mandatory for most, then yes, put it in the RFC. If it is mandatory only for some, then no, leave it out. Furthermore, write a small set of scenarios to illustrate how the RFC will make life easier.

Bob noted that many of the SHOULDs were the result controversy between those who argued that it was a MUST versus those who said NEVER, so with review, it's possible that some SHOULDs would remain or change to MUSTs.

Steve observed that the authors have begun to review the SHOULDs. We pushed the schema out of CAP into iCAL. We wrote a pseudo-SQL description for the calendar store for the CAP. It is out of CAP and will be put into another document.

Dave asked about shifting to XML encoding. The XML tools are finally coming out enough to make this real possibility.

Paul Hill replied that there was a binding draft between iCAL and XML. Although he is leery of going to extended namespaces and queries, he would like some to pick this work up. (This expired document will be moved to the calsch.org site)

Dave: The WG should show how the standard does valuable functions, like the ability to "beam" virtual business cards or add them to signature files. The IMPP presence protocol needs iCAL and VCARD and is developing this in XML. There is a lot of energy in IMPP that CALSCH could tap.

Steve said he would post specific proposals to the list.

6. "Guide to Internet Calendaring" Last Call -Bob/George

This is in WG last call and there was some feedback. The title is changed to "Guide to Internet Calendaring" and will be made an Informational RFC.

7. RFC updates and status

RFC 2446 and 2447 have been updated and were discussed at 49th IETF in San Diego. We are waiting for the results of Calconnect II before submitting these changes. We want to deal with any holes from the interoperability testing before resubmitting these RFCs.

8. Plans for further informal meetings during the week.

Those WG attendees remain after the meeting are encouraged to get together and continue discussing the issues raised.

CALCONNECT II April 12-13 at Stanford has five vendors plus a number of open source submitters. The chairs will be making efforts to encourage vendors who have dropped out of the CALSCH effort to return, as well as relate that we may have a new appreciation for their objections in the past.

9. Adjourn.


What Remains?
Guide To Internet Calendaring
Too Much?