2.1.1 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00


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

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

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 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 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.

Nov 99


Submit Internet-Draft (informational) on Guide to Implementors using Calendaring Protocols

Feb 00


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

Feb 00


Submit proposed changes to all drafts affected by Calendar Access Protocol submission


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

Minutes from 47th IETF meeting of the
Calendar and Scheduling Workgroup in
Adelaide, Australia
March 28, 2000

Bob Mahoney, CALSCH co-chair presiding (bobmah@mit.edu)
Reported by Richard Shusterman (rans@netscape.com)
Approximatly 25+ people in attendance

1. Guide to Implementors (5 minutes)

Discussion lead by Bob Mahoney (co-author)

Bob: This draft needs to be rev'd soon; it is about to expire. The authors will work on posting an updated draft in the near future. We need input from developers that are reading the calendar documents. Please send in your "war stories".

There were no comments or questions from the crowd.

2. CAP draft discussion (15 minutes)

Discussion lead by Bob Mahoney, with presentations by Paul Hill (co-author) and Steve Mansour (co-author), with help from Doug Royer (co-author)

Bob: The latest draft, draft-ietf-calsch-cap-02.txt, was posted on March 10, 2000. We are making good progress; there has been discussion on the mailing list that is reflected in this draft. There was one interim meeting scheduled this past January in Boston that was sparsely attended, probably due to the snow storm.

Bob: What is our timeframe? Soon.

Bob: What features are our priorities? There is no one feature that is prioritized above another feature. However, some features have had more discussion on the mailing list than other features. Recently there has been a lot of discussion in 2 areas, security and groups, which will now be presented by Paul and Steve.

2A. Security - presented by Paul Hill

Security Model

The requirements are very similar to the authentication and access control requirements of LDAP.

The current language is very closely aligned with the LDAP authentication draft.

User Principal Name (UPN)

An identifier that denotes a unique CU. A UPN is an RFC 822 compliant email address, with exceptions listed below, and in most cases it is deliverable to the CU. In some cases it is identical to the CU's well known email address. A CU's UPN MUST never be deliverable to a different person. It consists of a realm in the form of a valid, unique DNS domain name and a unique username.

UPN may be the authentication ID used by the authentication method.

UPN may also be the optional SASL authentication ID.

CAP IDENTIFY command may also be used to assert the UPN.

Question: Is a UPN independent of the authentication method?

Paul: Yes, it is the same ID regardless of the authentication method used by the CU. The same UPN is used by VCARs.

UPN and Certificates

When using X.509 certificates for purposes of CAP authentication, the UPN should appear in the certificate. Unfortunately there is no single correct guideline for which field should contain the UPN.

Since no single method of including the UPN in the certificate will work in all cases, CAP implementations MUST support the ability to configure what the mapping will be by the CS administrator.

Implementations MAY support multiple mapping definitions, for example, the UPN may be found in either the subject alternative name field, or the UPN may be embedded in the subject distinquished name as an EmailAddress attribute.

Question: Is there a preferred field?

Paul: Yes, a preferred field is specified in the draft.

TLS Ciphersuites

Section mentions which ciphersuites may be appropriate.

This is aligned with the LDAP access control draft.

2B. Groups - presented by Steve Mansour


To invite groups of individuals to an event/todo (CALIDEXPAND)


Why do groups need to be expanded?

An example diagram was presented, showing 2 CS,

- coach.com and publicIsp.com
- that are connected together using CAP. The CS coach.com has an embedded directory with group and calendar "baseball team", and current members bill, joe, and bob, each with their own calendar.
- The scenario is for the "coach" to setup a team calendar in coach.com with a VCAR definition that only allows the members of his team to access this calendar. Any changes to the membership of his team will automatically be enforced by this VCAR definition.
- If the "coach" would like to invite the calendars for each member of his team to a meeting, his CUA can use CALIDEXPAND to retrieve the list of CALIDs.
- "joe" would like to view the current members of his team. His CUA, connected to publicIsp.com, can attempt to use UPNEXPAND to retrieve the list of UPNs. Since the definition of his team is embedded in coach.com, this request will be fanned out to coach.com by publicIsp.com and if allowed, the list will be returned.
- "joe" would now like to invite his team to a meeting. His CUA, creates an event with his team as the only attendee. In order to track the responses of each member, publicIsp.com can use


to retrieve the list of CALIDs from coach.com before fanning this request out.

Paul: The current draft has a mistake showing CALIDs being returned by UPNEXPAND. This should be UPNs.

2C. iCalendar enhancements in CAP

Bob: Do these belong in CAP? Should iCalendar be revised or should these be treated as IANA extensions?

There were no comments or questions from the crowd.

Doug: There are also bugs in iCalendar that need to be fixed.

3. iMIP security (2 minutes)

Bob: RFC 1847 vs RFC 2633 (PGP vs S/MIME)

S/MIME is excluded because it doesn't support multipart/encrypted, thus not being RFC 1847-compliant. This was not the WG intent.

iCalendar was written before S/MIME RFC was ready.

This issue should be addressed in iCalendar.

Bob: Does anyone know if S/MIME will ever support multipart/encrypted?

There were no comments or questions from the crowd.

4. CalConnect (2 minutes)

April 11-12, Cambridge, MA (MIT)

Question: How many participants?

Bob: Potentially 4-5 vendors, and hopefully 1 open source. Cost is $1K and you can send 2 participants.

Other comments and questions from the crowd

Question: What's left to be done on the draft?

Steve: Examples that show multipart responses and groups. Also, restriction tables, i.e., what commands are allowed and where. This is very tedious work but it was found to be a key part of iTIP. These examples and tables should come out in the next few weeks and any input from the mailing list is welcome.

Doug: We need more examples.

Question: Have all the issues on searching, raised by Lisa Lippert, been addressed?

Paul: Since Lisa has not been participating lately on the mailing list, there has been no further discussion (or apparent interest) on these issues.

Question: What's the interest level in CAP?

Doug: So far, there have been 570 downloads of the CAP draft, many from the same individuals, which also reflects the multiple revisions of the draft since the ftp site was setup.

Bob: Editors are available for discussion after this meeting. We are all --working towards finishing up this work, which the AD's appreciate.

Meeting was adjourned