2.1.2 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-21

Bob Mahoney <bobmah@mit.edu>
Pat Egen <pregen@egenconsulting.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.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:
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-10.txt
  • - draft-ietf-calsch-many-xcal-02.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

    Calendar & Scheduling Working Group minutes, Mar 19
    The minutes were taken by Larry Greenfield 
    <leg+@andrew.cmu.edu> - (thanks Larry for volunteering).
    Pat Egan is chairing.
    Slide -  Chair, introduction & agenda bashing
    . Pekka from Nokia asks about iSIP and whether it will become a  working 
    group item.
    General thoughts are that it could become one after a charter revision but 
    only after CAP is done. Nothing to interfere with CAP.
    iSIP is iTIP transported via SIP.
    Slide - Chair, Interop testing.
    There's been a successful virtual interop that will help when we attempt to 
    move iCalendar to draft. There's a hope to do a face-to-face interop 
    sometime around June/July. It would be wonderful if there were 
    proto-CAP implementations then.
    CAP discussion: Chair & Doug Royer
    . BEEP profile
    Discussion whether there should be one iCalendar object per BEEP blob or 
    more than one. Consensus that since BEEP allows intra-channel 
    pipelining one iCalendar object per BEEP blob is fine.
    There might be an issue with multiple targets in a single iCalendar 
    object; list will discuss.
    . Response codes
    No discussion on response code changes.
    . Stored queries
    Should we allow stored VQUERY objects? If there are predefined queries than a 
    lightweight client could do less work.
    Larry Greenfield thinks that stored VQUERY objects without 
    standardized pre-defined queries could cause interoperability 
    problems. Room consensus that stored VQUERYs should be moved out of the 
    draft and reintroduced as an extension.
    . Grammar and typos
    No discussion on changes except that better English is gooder.
    Lively debate on a hypothetical charset property. Martin Duerst is 
    interested in this and possible solutions and hopefully a solution will be 
    presented on the list.
    . Resolved Issues
    GET-CAPABILITY will be required.
    . Removing LATENCY from some commands
    Chris Newman suggests removing latency entirely. 4 people in the room 
    don't see any need; consensus in the room is to make it an extension.
    . Removing CS
    CS "calendar store" acronym is confusing in the draft. The editors will try 
    to clarify.
    . Other stuff
    xCAL (XML version of iCalendar data) is very hot. People are very 
    interested in it, and the WG might take it on or provide review after CAP is 
    There's an effort to create an RDF schema.
    Chris Newman is unhappy with the IDENTIFY command because switching 
    authenticated identities can be hard in some environment. Others don't 
    think it is so hard, but no one in the room are impassioned about 
    keeping it, so it might just become an extension.
    The issue of closing the Working Group was discussed with the Area 
    Director.  If we are going to be submitting a new iCalendar draft with 
    changes found during interop testing, that will happen within the next 6 
    months.  Rather than restart the WG, it may be better to stay up until that 
    is complete.  Pat will submit a new charter update.
    Respectfully submitted by Pat Egen
    SLIDE TEXT - following is text of slide presented during meeting.  Notes 
    above reflect discussion during showing of slides.
    --    Agenda Bashing
    --    Interop testing status
    --    CAP
    Interop Testing
    --    Currently working on next Virtual Interop
    --    Need to do a face-to-face interop around July timeframe
    Beep Profile
    --    Should each begin and end vCalendar be in one Beep Blob?
    --    In other words, should it be one BEEP blob of reply or multiple BEEP 
    blobs of reply.
    --    The application should be able to reconstruct multiple BEEP blobs 
    into the original.
    --    It is probably best to lean towards multiple BEEP blobs simply so 
    that small memory devices do not have to handle large BEEP blobs all at 
    --    What does everyone think of this idea? We feel we need a BEEP 
    expert to help us make a determination.  We can compile and we can use it -- 
    but what is a BEEP Profile?
    Request-Status codes
    --    We are finishing the REQUEST-STATUS codes
    --    Everyone agrees on text -- we just need to change numbering
    Stored Queries
    --    vQuery
    --    Some people feel that a stored vQuery is harder to store than a 
    stored VCAR, VEVENT, VTODO
    --    It may be easier than it appears
    --    just store it as a blob and send it to the query engine that will 
    have to be able to process that blob if sent from a CUA anyway.
    --    If you do not want to save a VQUERY then say NO when the CUA 
    --    For example, if an implementation does not support VJOURNAL, you say NO 
    when a CUA attempts to use vJournal.
    --    We still are not sure if this feature is really required? 
    Grammar and typo's
    --    We are continuing to fix any typos found by readers of the draft
    --    There are quite a few comments regarding double negatives in the 
    wording that make the draft confusing
    --    If anyone sees instances of this, please post the item, with 
    suggested changes to the text, to the list
    --    There has been a lively debate on CHARSET
    --    The question on the list is CHARSET is not specified in 2445 inside 
    the object and this "breaks" transporting the objects outside of MIME
    --    This is really an issue about transporting iCalendar objects 
    without MIME headers
    --    We have a possible solution, based on discussions here this week
    --    Look to the list for suggestions and solutions
    Resolved Issues (maybe)
    --    GET-CAPABILITY required
    --    Based on the list consensus -- Resolution: it is mandatory.
    --    Ordering of commands
    --    Based on list consensus -- Resolution: they can come back in any 
    --    During hallway BOF's this week, we heard about lessons learned from 
             -- implementers discovered it is better that the commands come 
    back in the same order
    --    Therefore, we may need to review this decision
    Removing LATENCY
    from some commands
    --    LATENCY is already optional and the GET-CAPABILIITY command CAN be 
    sent after IDENTIFY, so it may need LATENCY
    --    As that point has not been refuted, we suspect that that the 
    consensus is to not change that feature
    --    Is this a correct assumption on our part? 
    Removing CS
    --    There are thoughts to removing CS when it could mean 'any 
    endpoint' to a future draft
    --    Several places we say CS when it also applies to CUA, for example 
    --    In some cases we say "CUA or CS" when we mean either end of the 
    connection, whatever that might be
    --    The comments have settled down so we suspect that the consensus is to 
    make it generic (remove 'CS' in those instances).
    CAP -- in Summary
    --    For the most part the last few months have been about bugs and not 
    feature changes.
    --    A last call has been "suggested to the list"
    --    Another final Last Call will go out after this meeting
    --    There will be a 2 week deadline on that last call
    Identify Command
    --    Should it be an extension and removed from draft?
    --    Use SASL authentication?
    --    Should it be optional?


    None received.