Current Meeting Report
Jabber Logs

2.1.1 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 01/21/2002

Bob Mahoney <>
Pat Egen <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Patrik Faltstrom <>
Mailing Lists:
General Discussion:
To Subscribe:
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:
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
  • - draft-ietf-calsch-cap-08.txt
  • - draft-ietf-calsch-many-xcal-02.txt
  • Request For Comments:
    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

    Current Meeting Report

    Calendar & Scheduling Working Group minutes, Wed Nov 20
    reported by Larry Greenfield <>
    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
     Pekka Pessi, iTIP SIP binding "iSIP"
    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 
    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 
     meeting adjourns


    iSIP: iTIP over SIP and Using iCalendar with SIP