2.1.2 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-10

Pat Egen <pregen@egenconsulting.com>
RL Bob Morgan <rlmorgan@washington.edu>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.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:
Done  Submit core object specification as Internet-Draft.
Done  Submit first Internet-Draft of Calendar Interoperability Protocol.
Done  Submit second draft of core object specification as Internet-Draft.
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-12.txt
  • Request For Comments:
    RFC2445 PS Internet Calendaring and Scheduling Core Object Specification (iCalendar)
    RFC2446 PS iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
    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

    IETF calsch WG meeting 
    IETF 59, Seoul, South Korea 2004-03-02 
    submitted by RL "Bob" Morgan also thanks to Lisa Dusseault for Jabber 
    The meeting was called to order at 1415 by co-chair RL "Bob" Morgan.
    The first agenda item was WG status. Bob noted that finishing CAP is the 
    main thing, and that a proposed charter revision reflecting this, with some 
    possible new work items, and new milestones, had been sent to the list. Ted 
    Hardie, the WG's area director, said that accurate milestones would be 
    good, but that it is important to have identified authors for all 
    charter work items; it would also be good to know if people are 
    actually implementing CAP.
    Doug Royer said (via Jabber) that he, Novell, and Oracle are 
    implementing CAP. Cyrus Daboo (also via Jabber) commented that he is more 
    interested in caldav first, then CAP later. Lisa Dusseault said that CAP is 
    not well-suited to the product of her new employer, the Open Source 
    Application Foundation, which prefers a smart client model. Bob said that 
    the University of Washington is implementing a CAP server. Nathaniel 
    Borenstein of IBM said that IBM is not implementing CAP, and that to his 
    knowledge Microsoft is not either. Ted asked if these are all server 
    implementations. Doug noted that his implementation will include 
    Bob said that a lack of CAP implementors might lead us to abandon taking CAP 
    to standardization, but that doesn't seem to be the situation. Doug noted 
    that some implementors will wait until CAP reaches RFC status.
    Bob also noted that there are some who say that CAP has major flaws or is 
    unsuited for their use, but this is hard to express as an issue with the CAP 
    document per se. What effect this type of comment might have on our WG 
    direction isn't clear.
    Bob asked if there were further issues to raise regarding CAP at this 
    time, deferring discussion of items already raised on the list or via 
    bugzilla. Nathaniel expressed support for Lisa's comment about the CAP 
    "smart server" model being the wrong one, and that a model where the 
    calendar server is a store would be better. He also expressed concern with 
    the iCal spec, that it suffers from ambiguity that makes 
    interoperability difficult to achieve in any but the simplest of cases. 
    Doug commented that iCal and CAP are large because support for 
    real-time scheduling and coordination is complex.
    Bob said that proceeding to last call with CAP and handing some of these 
    assessments to the IESG might be the best way to get resolution 
    expeditiously. Ted said that while there is no requirement for there to be 
    implementations for a doc to be a Proposed Standard, there is a 
    requirement for serious review, preferably by implementors. So he urged the 
    chairs to require some number of real reviews before progressing the doc. 
    Doug said that since CAP is big, many people want to wait until the WG says 
    it's ready.
    There being no more comments on this or other topics, the WG adjourned at 


    None received.