2.1.1 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

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
In Body: SUBSCRIBE/UNSUBSCRIBE
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 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

Internet-Drafts:
Request For Comments:

RFC

Status

Title

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

Current Meeting Report

CALSCH meeting minutes - London
Pat, co chair, went over the following agenda:

Agenda Bashing
- Guide to Internet Calendaring
- CalConnect Interoperability results - next plans
- iCalendar Updates
- Other drafts - SKICAL, CRISP
- IPCPL - iCalendar
- CAP draft
- Update charter

Bob Mahoney gave a brief update on the Guide to Internet Calendaring. We asked people to review the list so it could go to IETF last call.

George mentioned that the Guide is now available in HTML format, and it will soon be available on the calsch.org website.

At this point, we moved up the IPTEL discussion so that the rep from that group) could leave early. He asked the group to please help us make a decision on how this issue (particularly with their request for changes to BYSETPOS). Pat explained that we had spoken with the Area Director and he gave us some suggestions on what we could do. We will try once again to see if we can resolve this over the list. Otherwise, Bob and Pat will work with Jonathan Lennox to come up with a one page summary on the issue and give it to Patrik for next steps.

Pat next covered the interop testing held in Standford in the first half of the year. A final report will be on the list by the end of the month. We will hold the next interop in November at McGill University in Montreal. Pat asked for some more vendors to participate.

Pat went over the CRISP document and SKICAL at which point she turned over the meeting to Greg Fitzpatrick to talk about SKICAL.

Greg talked about a document that shows the SKICAL reference in HTML format. We are going to put it on calsch.org. He also talked about an effort going on at the W3C in relation to iCalendar and RDF. He said Libby Miller was the head of this effort and she will join us after the meeting so Greg can introduce her to the working group members.

Greg then went into discussion of where SKICAL is and how they have struggled with their effort in trying to define an Event type of draft. He talked about how they would like to see standardization on names such as what a vendor calls a meeting or event. He correlated this to having an XML namespace where things were defined. This may be hard to do as many vendors choose to call objects differently.

Greg pointed out that the ABNF and the examples are different when it comes to requiring a DTStart. He said for his effort, not requiring a Replace DTStart with DTSTART would help. We need to first fix the iCalendar spec and then determine which is correct for our draft - required or not required. Greg feels there are other issues or changes to iCalendar that need to be addressed. We aske him to put these on the list.

Greg talked about some work resurrecting the Chris Newman document on dates and times. He wanted to know why we don't follow the ISO 8601 standards and constructs. John Stracke addressed this briefly.

John said that we do follow a subset of ISO 8601.

There was a general discussion about working with the W3C and how this becomes difficult. There was a general discussion about the challenges of working with time. Greg said it would be helpful to have a language property (like lang) added to iCalendar. He said it could be called lang - John objected to this idea.

John objected because it was a French word. This was inconsistent with all the other names which are all in English.

Next George Babics did an update on CAP. He went through the slides (copies included with this draft). We announced we want to go to last call in December. We also asked for more participation on the list so we can make sure we have consensus. During the discussion about VCARs and their challenges, Ned Freed asked about how, in the document, do we explain how to determine the identity of a calendar. In other words, how do we define what that should look like. Our naming model may be too flexible. Paul Hill said he just came from a SASL discussion and he said they were having the same challenges. They are looking at application profiles that define these. Some do it in the DN for LDAP and some do it for Kerberos.

George stated that we need more participation and participants since CAP is big and complex. The more people looking at it, the better. George mentioned that an HTML version of the CAP document will also soon be available on the calsch.org website.

John Stracke said we need to do a better job of defining our CAP methods.

Ned then said he had just read the draft and had some comments. He wanted to know if we had looked at the BEEP RFC. We explained it was a timing issue. BEEP was not around when we started working on our draft. Ned suggested we move some of the overhead down into the "payload" portion and let something like BEEP manage the transport. Pat asked if this should be a part of iTIP?

General questions from the audience.

Have we looked at a calendar other than Gregorian. Answer is no for now. General discussion about this. Talked about time in general.

Nick Shelness said our group had done a good job defining time and the issues associated with this effort.

Pat talked about the fact she had contacted Olson regarding interfacing with the IETF to establish a common timezone table. Then, a member of the audience wondered if there needed to be some sort of Internet Time Space - this is beyond the scope of the IETF.

Someone wanted to know if we had looked into any of the presence documents. He said we may want to think about somehow incorporating this into the drafts to manage where a person is at any point.

Pat talked about charter updates and whether or not we needed to resubmit our requirements document. Ned suggested we look at the document and if there was nothing controversial, submit it as an information document. If we have veered too much from the original document, then leaving expired may be best.

Guide to Internet Calendaring

- In Working group last call
- Most recent comments
- Minor typos/grammer
- Designate

CalConnect II - Interop Testing

- Standford University
- Three Vendors
- Lotus, Steltor, iPlanet
- Significantly improved results
- Report on list by end of week 8/13
- Next Calconnect
- Montreal - McGill University
- November 2001

iCalendar, iTIP, iMIP

- Need to make changes found during interop testing
- Do we want to resubmit draft that shows XML extensions for iCalendar?
- Eric Busboom now main editor

Other Drafts

- SKICAL - last call
- Crisp - need to resubmit

CPL and iCalendar Issues

- RECUR
- BYSETPOS
- What do we do?

CAP
What Is New In Version 5?

- Use RFC 2629 (Writing I-Ds and RFCs using XML)
- Added some new examples
- Clarifications
- Fixed some errors

Our Plans (1)

- Resolve all open issues:
- We have started posting them to the list
- Finish all other outstanding tasks
- Goal: last call in December

Our Plans (2)

- Need more participation and participants!
- CAP is large and complex
- Many details

Open Issues: Fanout (1)

- Fanout: ability for a CUA to communicate to a single server to be able to perform scheduling operations with calendars on many CSs
- MUST be able to do it with iMIP

Open Issues: Fanout (2)

- Problems:
- Can we map all the CAP commands into iMIP methods?
- E.g. CREATE -> REQUEST
- Security: how can the remote server trust the server doing fanout?

Open Issues: Fanout (3)

- Problems without fanout:
- CUA has to manage scheduling using different types of addresses: CAP and email (iMIP)

Open Issues: Decreed VCARs

- The ability to have administrator controlled immutable VCARs that apply to all calendars on the server.
- E.g. disallow anyone from permitting anonymous users do gain access to their calendars
- Problem: there is no way to identify decreed VCARs
- Need new properties
- Do we need them?

Open Issues: Restriction Tables

- There are a number of issues with the Methods in the restriction tables
- Check the draft for these issues
- We should be addressing them soon

Open Issue: Delegation

- CAP does not easily allow delegation
- Some suggestions recently on how we can fix this

Outstanding Tasks

- Register port number (5229) with IANA
- Get new properties and components into iCalendar
- E.g. VQUERY, GRANT
- Add new examples, such as an entire "typical" session from start to finish
- Review security
- Review restriction tables

Charter Update

- Current Charter
- Note last call on CAP
- Move Guide up food chain
- Re-post requirements Doc?
- Re-post CRISP?

Slides

None received.