Current Meeting Report
Slides


2.1.1 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 11-Oct-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:
RFCStatusTitle
RFC2445PSInternet Calendaring and Scheduling Core Object Specification (iCalendar)
RFC2446PSiCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
RFC2447PSiCalendar Message-based Interoperability Protocol (iMIP)
RFC2739PSCalendar attributes for vCard and LDAP

Current Meeting Report

Minutes for the CALSCH Applications Area working group meeting
December 2001 - Salt Lake City.

Agenda:
1. Agenda Bashing
2. Guide to Internet Calendaring – last call with ADs
3. Updates on other drafts (iCalendar, iMIP, iTIP)
4. CAP draft
5. Milestone review and Charter update

Pat Egen started the meeting with an overview of the agenda. Pat advised the group that the Guide to Internet Calendaring has been sent to the AD's for their review and IESG last call.

Pat then gave an update on iCalendar, iMIP and ITIP RFC work. Shannon Clark is now an editor of Icalendar, iMIP, and iTIP and is doing updates. He needs to submit changes to iCAL syntax and also needs to discuss on the list how to submit them. Several changes are a result of interop testing. Also, we are trying to decide what to do about items that are in CAP but that relate to iCalendar. Steve will discuss later in his portion of the meeting.

The next topic was Internationalization and how it related to the drafts just discussed and any new work or drafts. The group was asked to look over all our work by Area Directors. We believe our RFC's are OK. We believe there are possible issues with CAP. Pat has been assigned to validate the CALID and check if the URL (csid) are ok with respect to internationalization.

George Babics then discussed the draft that adds an XML interpretation of iCalendar. He commented that the draft has been submitted. This draft does not replace iCalendar - it sits on top of it. In other words, you need to ensure that the iCalendar rules are in place before you add any XML syntax.

Steve Mansour then took over to discus CAP. I've included the text from our slides in these minutes.

Slides 1 and 2: Changes in Draft Version 06
* Lots of small corrections
* Transport Protocol changed to BEEP - CAP is an Application Protocol
* Added VAGENDA
* - Replacement for overloaded VCALENDAR
* - Has properties (name, TZID, VCARs, etc)
* - Appears within the VCALENDAR wrappers in iCalendar
* Fanout was removed
* "move" command supports VAGENDAs and VEVENTs, VTODOs, VJOURNALs, and VCARs -
* Removed UPNexpand and CALID expand - these can be done with VQUERY

Notes on slides 1 and 2:
We Chose BEEP as the protocol to specify the transport layer (at the suggestion of Ned Freed). vAgenda is now the container for vToDos, vEvent, etc. We removed fanout from the draft because there were too many issues.

There is a prediction that early vendor implementations will have their own fanout routines. We can standardize it later.

Slide 3: Current issues/tasks
* Query is spread between Transport and Application protocol
* Review calid in light of recent I18N discussions
* Add the iCalendar extensions
* CAP or an Extensions
* Review VCARs, Queries
* Finalize return code table
* Finish all proposed corrections
* Scheduling restriction tables
* Obtaining the UPN after Authentication in BEEP
* Fanout discovery

Notes on Issues/tasks
Steve went over the topics shown on slide 3 above. He talked about the need to determine whether we add the iCalendar extensions in this draft, or create a separate document. We don't want to go back and update the existing iCalendar - there are people now running code using this protocol.

Other questions we have are how to handle listing presentation of return codes that are spread out over many docs?

We need to make sure that the restriction tables of iTIP are compatible with CAP.

Paul Hill from MIT will look at the issue of obtaining UPN after authentication in BEEP.

For fanout discovery the protocol needs to tell the client if it needs to do fanout or if the server will handle it.

Slide 4: Query Issue (this is an example of a query).

English query: Search relcal2 and relcal3 for booked events that overlap
8:00 Mar 10, 1999 to 19:00 Mar 10, 1999

Example: Draft 06
C: <search id="search01"/>
C: <select>
C: <source relcalid="relcal2"/>
C: <source relcalid="relcal3"/>
C: <data content="cid:query@c.ex.com"/>
C: </select>
C: </search>

C: BEGIN:VCALENDAR
C: BEGIN:VQUERY
C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
C: FROM VEVENT
C: WHERE DTEND >= '19990310T080000Z'
C: AND DTSTART <= '19990310T190000Z'
C: AND METHOD IS 'BOOKED'
C: END:VQUERY
C: END:VCALENDAR
- - - - -
Example: Proposal
C: <search id="search01"/>
C: <select>
C: <data content="cid:query@c.ex.com"/>
C: </select>
C: </search>

C: BEGIN:VCALENDAR
C: BEGIN:VQUERY
C: TARGET:relcal2
C: TARGET:relcal3
C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
C: FROM VEVENT
C: WHERE DTEND >= '19990310T080000Z'
C: AND DTSTART <= '19990310T190000Z'
C: AND METHOD IS 'BOOKED'
C: END:VQUERY
C: END:VCALENDAR

Notes on Query Issue:
The command is separated between the application and command part. There is a suggestion of having a "TARGET" or "SOURCE" property in the vQuery

Slide 5: Plan going forward:
* Bring CAP to last call before the March IETF
* Informational Examples RFC
* - Volunteers to help
* - Ideas for examples

We want to create an informational RFC that "houses" the CAP examples. This would make CAP smaller. We asked for volunteers to help move the examples to this draft. This draft would move along the same timeline as CAP.

George Babics then gave an example of CAP using BEEP. CAP is BEEP Example.
Here is the example syntax (slides 6-7-8):

C: MSG 1 8 . 3843 778
C: Content-Type: multipart/related; boundary="boundary-foo321";
C: start="1@cal.example.com";
C: type="application/beep+xml"
C:
C: --boundary-foo321
C: Content-Type: application/beep+xml
C: Content-ID: 1@cal.example.com
C:
C: <create id="creation01">
C: <target csid="cal.example.com"/>
C: <data content="cid:2@cal.example.com"/>
C: </create>
C: --boundary-foo321
C: Content-Type: text/calendar
C: Content-ID: 2@cal.example.com
C:
C: BEGIN:VCALENDAR
C: VERSION:2.1
C: BEGIN:VAGENDA
C: RELCALID:relcalz1
C: NAME;LANGUAGE=EN-us:Bill's Soccer Team
C: OWNER:bill
C: CALMASTER:mailto:bill@example.com
C: TZID:US_PST
C: END:VAGENDA
C: BEGIN:VAGENDA
C: RELCALID:relcalz2
C: NAME;LANGUAGE=EN-us:Mary's personal calendar
C: OWNER:mary
C: CALMASTER:mailto:mary@example.com
C: TZID:US_PST
C: END:VAGENDA
C: END:VCALENDAR
C: --boundary-foo321--
C: END
S: RPY 1 8 . 4621 647
S: Content-Type: multipart/related; boundary="boundary-bar321";
S: start="1@cal.example.com";
S: type="application/beep+xml"
S:
S: --boundary-bar321
S: Content-Type: application/beep+xml
S: Content-ID: 1@cal.example.com
S:
S: <result id="creation01">
S: <target csid="cal-example.com"/>
S: <request-status code="2.0"/>
S: <data content="cid:2@cal.example.com"/>
S: </result>
S: --boundary-bar321
S: Content-Type:text/calendar;
S: Content-ID: 2@cal.example.com
S:
S: BEGIN:VCALENDAR
S: VERSION:2.1
S: BEGIN:VAGENDA
S: RELCALID:relcalz1
S: REQUEST-STATUS:2.0
S: END:VAGENDA
S: BEGIN:VAGENDA
S: RELCALID:relcalz2
S: REQUEST-STATUS:2.0
S: END:VAGENDA
S: END:VCALENDAR
S: --boundary-bar321--
S: END

Pat Egen then gave an update on interop testing:

Slide 9: Interop Testing
* http://www.calsch.org has results from interop.
* Results from Calconnect2 will be posted end of this week
* CalConnect3 was scheduled for November but due to travel restrictions by most attendees, we had to cancel.
* Looking at March/April 2002 – location to be determined
* 6 vendors and one open source group are signed up to participate
* Need to resolve an issue with a vendor that states they support iCalendar, iMIP and iTIP but will not attend interops

Notes on interop. Novell has offered to host it in Provo Utah.

Slide 10: Charter & Milestones Update
* December 2001 was set for last call on CAP
* Date changed so that draft could be updated to take out transport and point people at BEEP
* Need to add item to resubmit iCalendar, iTIP and iMIP as drafts with changes found during interop testing

Thanks to George Babics and Bob Mahoney for helping take notes.

Minutes respectfully submitted by Pat Egen

Slides

None received.