2.1.4 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97


Robert Moskowitz <rgm3@chrysler.com>
Anik Ganguly <anik@ontime.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Applications Area Advisor:

Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Mailing Lists:

General Discussion:ietf-calendar@imc.org
To Subscribe: ietf-calendar-request@imc.org
In Body: [SUBSCRIBE/UNSUBSCRIBE in Message body]
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 event-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 Interoperability Specification (CSIS) * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's Specification * Versus 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 first Internet-Draft of Calendar Interoperability Protocol.



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

Jun 97


Submit revised Internet-Draft of Calendar Interoperability Protocol.

Jun 97


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

Aug 97


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

Apr 98


Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard.


No Request For Comments

Current Meeting Report

Minutes of the Calendaring and Scheduling (CalSch) WG

I. Agenda Review

Anik called the meeting to order. To begin, he referred to the agenda he had published to the mailing list. Because of the anticipated discussion for iCalendar, iTIP and Model and the desire to reach closure for these documents, he acceded to requests to delete iRIP and CAP requirements from today's agenda.

It was noted that a draft for iRIP is available in internet-drafts. Based on WG discussion on the mailing list prior to the meeting, Anik believes that iCalendar, iTIP and the Model will be ready after today's meeting for submission to the IESG to move them to PROPOSED status (FYI status for the Model). Of course, if problems are discovered, then they must be fixed first. The balance of the meeting will be devoted to reviews of iCalendar, iMIP and the Model in that order.

II. iCalendar Review

Derik Stenerson and Frank Dawson explained that they wished to list the issues known to need resolution and attempt to close them, then seek other issues from floor.

III. Time Zone Syntax

Derik began with the time zone syntax. He recently published a set of changes for iCalendar time zone syntax that incorporates suggestion made on the mailing list. Harald accepted the changes.

However, Keith Moore was more circumspect. Keith's initial concern was there are not enough examples that show the use of time zones in events. He asserted that no successful protocol would omit explicit references to time zones. As the discussion developed, it became clear that the time zone reference must be in terms of a label whose value is resolved each time the event is presented.

This is necessary because events are scheduled in terms of the current time, irrespective of clock shifts that may occur between the scheduling of an event and the arrival of the time for the event. This implies that changes throughout the document are still required. Without those changes or their equivalent, the IESG will certainly not allow iCalendar to go forward.

As a further example of this problem, Keith described a recurring meeting scheduled at 11am US Eastern Time each Tuesday. In terms of UTC, during EST this is UTC-0500, but during EDT, this is equivalent to UTC-0400. However, from the perspective of the attendees, the meeting is *always* at 11am ET, although the offset from UTC is different at different times of the year. If the meeting time is resolved to an absolute UTC at the time the meeting is scheduled, then the meeting time shifts when the clock shifts. This behavior is unacceptable.

Allowing a label in the time zone introduces more changes than simply allowing a label in time zone syntax. A set of labels and their interpretation must be specified. So that new labels may be registered or old one meaning modified, responsibility for maintenance of the list must be passed to IANA.

This discussion had grown quite animated. So that other topics for iCalendar could be discussed, Anik summarized this debate, and asked the WG to move on to the next item. He summarized the debate, as follows:

1. Event start and end times may be in different time zones.

2. A time zone must be expressed in terms of a time zone label.

3. There must be an accepted set of time zone labels.

4. No set of accepted labels currently exist.

5. An authoritative source for label semantics must be created (perhaps as a function of IANA).

IV. Recurrence Grammar

Recurrence rule grammar is complex. Is it possible to define a minimal set of rules that provide enough functionality? iTIP response codes could be used to negotiate what recurrence rules are interpretable. A meta-property could be used to identify what set is supported. But iTIP doesn't have real-time negotiation, so peers will likely assume the minimum implementation to avoid having messages rejected.

V. iCalendar Summary

The discussion of time zone and recurrence rules exhausted the time available to discuss iCalendar. Before moving on to iTIP, Anik asked the editors to supply a list of outstanding issues to be included in the minutes. Current outstanding issues are:


Doc Sections



Time specification is not adequate



Keith Moore

Must allow "late binding" to time zone info.

iCAL 4.4.6


Recurrence grammar should have minimum required set

iCAL 4.10.9


Dan Hickman

Ordering of evaluation of Byxxx components inconsistent with example



Dan Hickman

Eliminate "SOURCE" Use "Content-Location" instead

iCAL 4.5.4


Alex Hopmann

Does the URL attribute duplicate the MHTML Content-Location Header?

iCAL x.x.x


Alex Hopmann

Related-To make it a URL



Alex Hopmann

Should we support Basic or Extended or Both ISO 8601



Alex Hopmann

Can the owner also make changes?



Yvonne Tso

Owner needs to be defined or removed

iCAL 3


H. Alvestrand

Can Date/time DUE be same as DTSTART

iCAL 4.6.9


Yvonne Tso

VI. iTIP Issues

Steve Mansour and Frank Dawson began by listing all of the unresolved iTIP issues, and then began working through the list.

This seemed unresolved in mailing list discussion. However during the meeting, it was agreed that adding some examples will be sufficient.

Echoing the iCalendar discussion, the difficulty defining the set was noted. iTIP has defined error responses for inability to interpret recurrence rules. What to do about the minimum recurrence rule set remained unresolved.

Alex Hopmann has written a program to analyze the iTIP grammar. While he believes it is correct, as far as it goes, there were some rules he was unable to code in his analyzer. This led to a discussion of whether the specification was sufficiently complete, even if the grammar could not be parsed by machine. The discussion concluded that human readability was more crucial than insuring a mechanical parse.

The WG felt the ownership concept lacks clarity, specifically how it differs from the organizer. Nevertheless, it was felt to be an important concept. Currently iTIP has no mechanics to express changing the owner of a component. It was specifically omitted because of fears that the channel could be compromised. But it was noted that if the owner changes, this must be advertised to those CUs who have the component on their calendar. Because organizers do exist, some suggested unifying owner and organizer into a single role. Several in the WG felt this was a bad choice. Expressing ownership changes remained unresolved.

iTIP has no provision for multiple organizers, however, this is allowed in the model. Currently the single organizer in iTIP can be an individual, group or an unknown CU. There was a request on the list to eliminate the group. However, those at the meeting disagreed. Multiple organizers are still unresolved.

The iTIP authors would like clarification on how this should work in the model. The model author agreed to address this.


The iMIP authors bravely made this the first item on their agenda. They repeated the requirements as they saw them:

1. all conforming implementations MUST provide the ability to sign components

2. all conforming implementations MUST provide the ability to authenticate

3. all conforming implementations SHOULD encrypt and decrypt

iMIP messages could be constructed as multipart/mixed messages with each part containing a single component. The could be composed as a single text/calendar with multiple components. Expected behavior is that text/calendar parameters will identify the component type contained in the part. The first alternative is the one the authors prefer. The WG concurred.

MIME semantics only specifies whether object is in-line or to be stored as external file. Other interpretations should not be allowed or inferred.

VIII. Model

Two issues were identified for the Model, resolving the concept of delegation, and removing ambiguity about Calendar Service.

As noted above, the author has agreed to identify the kinds of delegation possible in Calendaring and Scheduling and incorporate them into the model.

The model combines a calendar store and component transfer agent into a single concept called Calendar Service. This creates ambiguities for when the functions of the Calendar Service are required. The author will divide Calendar Service into two separate concepts to remove the ambiguity.

Because of the extensive discussion, and the readily apparent need to resolve the problems discussed, we made no effort to assess consensus that any documents were ready for submittal to the IESG. We were out of time at that point, so the meeting was quickly adjourned.


None Received

Attendees List

Roster not received

Previous PageNext Page