2.1.1 Calendaring and Scheduling (calsch)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99


Robert Moskowitz <rgm@icsa.net>
Pat Egen <pregen@egenconsulting.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:ietf-calendar@imc.org
To Subscribe: ietf-calendar-request@imc.org
In Body: [SUBSCRIBE/UNSUBSCRIBE in Message body]
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 event-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:



Submit core object specification as Internet-Draft.



Submit first Internet-Draft of Calendar Interoperability Protocol.



Submit second draft of core object specification as Internet-Draft.

Jun 97


Submit revised Internet-Draft of Calendar Interoperability Protocol.

Jun 97


Submit core object specification to IESG for consideration as a Proposed Standard.

Aug 97


Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft.

Apr 98


Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard.


Request For Comments:







Internet Calendaring and Scheduling Core Object Specification (iCalendar)



iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries



iCalendar Message-based Interoperability Protocol (iMIP)

Current Meeting Report

45th IETF Meeting, Oslo, NORWAY
Chair: Pat Egen (pregen@egenconsulting.com)
Minutes taken by Richard Shusterman and Frank Dawson


- SKI Project Presentation
- Locating Document Status
- iCalendar DTD Work
- Interoperoperability Experiences
- CAP Draft Submission (note - did not reach Announce list)

Monday, July 12, 1999 Spektrum I

SKI Project Presentation

Greg FitzPatrick presented the SKI project. It began as a cultural calendar of events. A "Tom Sawyer" calendar for "musical events" where folks can register events on the calendar. They found it was difficult to put the SKI calendar into practice, e.g., it was too hard to allow anyone to put events on a calendar. Now they are evangelizing the use of the calendar through various Swedish ministries, e.g., sports, tourism, culture, education, handicap. Their intent is to allow public events/resources to be published, centralized in one location.

They tried to tag using the Dublin core but switched to using the iCalendar XML DTD. They already presented SKI draft 7.0 to the list. Now at SKI draft 8.4 (http://www.skical.org), which will be presented to the list for discussion.

SKI has it's own XML DTD for representing iCalendar objects and element types. SKI makes use of a pre-RDF format to authenticate and validate and for naming translations types and types of events, i.e., the iCalendar CATEGORIES properties. They needed new properties for "opening times", e.g., when the venue for the event opens/closes, "scheduling times", e.g., when the scheduled event may happen, authortive list of holidays, and also other properties.

Nick Shelness asked why iCalendar was not sufficient? He suggested that the "opening times" could be handled as a state of the event, rather than as an entirely different property of the event. For example, take the STATUS property and add new enumeration values. He suggested that the SKI initiative describe the problems in terms of what can't be represented using iCalendar, RFC 2445. He also asked if SKI was really about putting properties on objects, i.e. resources?

Greg said some of the problems solved by SKI are that events can be tentative but the times are confirmed or that events can be confirmed but the times are tentative.

Frank Dawson made the comment that the working group already decided that their current charter would not address resource scheduling in it's current charter of work.

Pat Egen made the comment that she asked Greg to present SKI here because there had been no responses from the list. Greg said he would repost the latest SKI draft to the list for discussion. He also said SKI was working with the WAP Forum to progress the SKI calendar concepts as a thin wireless application. He also stated that a lot of practical experience can be gained because this work can be applied to real events/resources, i.e., from the Swedish government.

Locating Document Status

Frank Dawson got with our AD, Patrik Faltstrom, to clarify the status of this document, which had passed last call back in March. Patrik said the IANA had concerns with this draft so it was not brought up to other directors until these concerns were addressed by a revised draft. Now that the recently posted draft reflects responses to these concerns, Patrik will check with the IANA to verify that these changes satisfy them. If they do, he will submit it to the IESG for review and a decision.

iCalendar DTD Work

Frank Dawson first stated that this is not work chartered by the WG and that a revised draft has been posted. There has been discussion on the list.

John Stracke described his issues with the current document. These include that the document doesn't allow extensibility beyond that defined by the base iCalendar standard. He proposed holding off this work until we have this extensibility. He also has a problem with having to send email with a MIME multipart/alternative containing both "text/calendar" and the XML representation.

Doug Royer and Frank (two of the editors) responded that the goal of the document was to provide an alternative XML represetative of the standard format defined by RFC 2445, not to create another standard iCalendar format and to assure the the XML representation of an iCalendar object can be transferred into/out of the standard representation.

They also stated that the area directors had given them guidelines that there must be only one definition, one standard. The AD's also wanted to make sure that anything done in one format can be represented in another format without loss of information and with full interoperability.

Lisa Lippert made the comment that this DTD cannot be extended but RFC 2445 can be extended. Frank and Doug disagreed. They said that the issue is that if an implementor wants to insert a "foo" name space into the iCalendar name space, call it a different document type. But if you want the iCalendar document type, you must follow iCalendar conventions.

John made the comment that this DTD is isomorphic to iCalendar. If you comply with this DTD, there is no reason to use it. Doug answered with what if you only have a XML parser? If a multipart alternative is sent with both formats, the receiver can parse whichever format it supports. Nick Shelness agreed with Doug.

Lisa asked who here had XML experience in using this DTD. Very few people did. Nick stated that we still need vendor to vendor interoperability experience with RFC 2445. The only advantage of this DTD is to publish calendar information with other data. Is this only a display format? Frank answered no, this is how it's modeled, not presentation.

Lots of discussion on how useful was an XML representation? One comment was that the XML representation is important because of the strong industry focus for "anything XML". Management may decide that they want to use the XML representation for the iCalendar object.

Keith Moore pointed out that having two versions representing a single iCalendar object might be a maintenance problem for the editors. It will be very hard to keep each document in sync. The AD have mandated that the XML representation can only specify what is specified in the standard representation, so the editors will have to keep the XML representation specification updated, as the iCalendar document evolves. He was not certain if the technical merits of doing the XML representation was worth the issues of adding yet another representation for iCalendar. If there won't be 90% penetration, no interoperability, why was this needed? Is XML a better way to extend? Not clear.

Nick stated that one advantage is that if we have a DTD, this might help interoperability. We are no worse off? Keith said this DTD was worth doing if the XML representation can be convertable to/from the standard representation without knowledge of the data model and with no loss of information. If yes, then maybe worth doing. Anything that interprets this DTD will still need calendar knowledge. Frank said these were goals of the XML representation.

Doug asked what if for display only? Keith said still need it.

Lisa offered that the XML DTD could point the way for a "version 2" representation of iCalendar. Keith, Nick, and Doug all responded we should not create another calendar standard. Lisa further commented that small devices only want to parse one format.

Keith suggested that XML can also be used (and advocated by some) as a way to introduce incompatability to open formats/protocols. The XML representation is also useful because it encourages the use of a single data model for calendaring and scheduling information. Nick pointed out that the XML definition is useful for use with a XSL engine for formatting of calendaring and scheduling information on website.

Greg FitzPatrick asked won't we need this for RDF? Frank responded that they were appoached by the RDF folks and decided that XML was more important.

Frank asked for clarification that informational, experimental was the way to proceed? Keith answered that he is not the AD but his personal opinion was he did not see any reason not to do this as an informational, experimental RFC. Maybe a future WG will decide on a different direction.

Lisa asked why inline DTD? Frank responded to maintain interoperability.

Interoperability Experiences

Frank Dawson asked who was ready to do interoperability using simple events, requests, replies, and counters. Only three vendors were willing to commit to participating in a "CalConnect" like activity. These included Lotus, Netscape/AOL and Sun.

Keith Moore asked how many implementations? About 6 responses. Someone made the comment that there were a larger numbers of folks who had products with just iCalendar import/export support or iCalendar/iTIP/iMIP support. However, the larger number of vendors did not feel it was necessary to participate in a more formal interoperability event.

Doug Royer commented that we could do this interoperabilty over email.

Keith, Patrik Faltstrom, and Bob Moskowitz stated that it was easier to test and perfect interoperability if all the participants were in the same room. This can also be done inexpensitively. However, a formal interoperability event is not required in order to collect information for an interoperability report.

Pat Egen asked that those vendors interested in a formal interoperability event should work with Paul Hoffman/IMC, the chair and other interested parties to attempt (yet another time) to put together such a program.

CAP Draft Submission

Pat Egen said the draft can be found at: http://www.imc.org/ietf-calendar/temp-draft-ietf-calsch-cap-00.txt or www.egenconsulting.com/cap.txt)

Pat said we couldn't really talk much about this draft since we missed the deadline for submission. Patrick said talk about it as much as possible.

Pat stated that she would like to see more real application examples on the list from end users. Nick Shelness responded that why isn't getting any CUA to talk to any CS real :)

Alex Taler and Steve Mansour then gave a presentation on the CAP work, specifically updates to the CAP specification since the last IETF meeting in Minneapolis (IETF-44):

1. Separated transport commands from application commands.
2. Single command to perform calendaring and scheduling operations.
3. Added "scheduling" queue (concept) to calendar model.
4. Application commands broken into 2 categories:
- Calendaring (direct book)
- Scheduling
5. Detailed Search Schema (has been defined).


Calendaring command set includes: CREATE, DELETE, GENERATEID, MODIFY, MOVE, READ methods.


CAP calendaring and scheduling operations or commands are issued against one or more targets (i.e., calendar stores or calendars).

The scheduling messages (e.g., REQUEST, REPLY, etc. iTIP methods) are queued (e.g., in a VSCHEDULE component, if you will) and require a CUA to dequeue and process. Scheduling methods were introduced as a requirement to CAP because we wanted to allow iMIP or iRIP to be used by a CAP calendar server. This greatly simplifies the relationship between the CAP direct book, calendaring commands and the scheduling (iTIP) commands.

Frank added that the advantage to an iMIP implementation to using the CAP scheduling commands is that it allows you to use the same CAP connection being used to write on your own calendar to send commands (e.g., REPLIES) to others on another calendar store/service.

Nick asked if this scheduling queue was independent of CAP? Frank responded no but it's easier to reply and set access rights. Steve and Alex also added that this scheduling concept ties into iTIP.

Nick asked why would I use CAP vs iMIP? Steve answered that it depends on the target. If CAP address, use CAP. If iMIP address, use iMIP.

Steve also asked for feedback from the list, especially on the search schema.

Paul Hill then gave a summary of the security discussions since the last IETF meeting:

What is a Calendar User: An entity (often biological) that uses a calendaring system.

How are they identified: By their User Principal Name (UPN, e.g., "user@example.com"). Also, will support anonymous identification.

How are they authenticated: AUTHENTICATE and IDENTIFY command. Authentication is really done through SASL authentication operation.

What are their access rights: Determined by what calendar they are accessing and VCARs associated with that calendar. Each VCAR will UPN values for their GRANT and DENY properties. The UPN is suggested to put in the "Subject-Alt-Name" field in the X.509 certificate. Granted that this is not optimal, but better than some other choices.

Alex added that we have a requirement that authenticated CAP calendar users might want to change their identify to another individual's credentials. CAP has the IDENTITY command to reset the CAP session's authentication to another person. However, this is not appropriate for "designate" usage or for members of a group to assert rights of a group. However it was appropriate for a server to authenticate as itself to another calendar store and then to assume the identity of a calendar user (proxy) that it wants to issue commands for. Also appropriate for sysop operations where it needs to clean up the calendar store/others

Frank stated that Tuesday's session would be used to go thru an example session.

Tuesday, July 13, 1999
Room 301

Examples presented by Steve Mansour and Alex Taler, directly from the CAP draft.

1. Login Using Kerberos v4
c: <connect to cal.example.com on part ...>
s: 2.0
s: .
s: AmFYig==
c: BAcaQU5....
s: or//EoAADZI=
c: DIAF5A4ga_oOIALuBkAAmw==
s: 2.0
s: IDENTITY=bill@example.com
s: MINDATE=19700101T000000Z
# who knows this date?
s: MAXDATE=20370201T000000Z
s: .

Steve noted that capabilities were no longer a separate command/response but returned after CONNECT, AUTHENTICATE, and IDENTIFY.

John Stracke asked if CS implementors cannot return capabilities after CONNECT and AUTHENTICATE? Alex answered to prevent man in the middle attacks.

John then asked why return capabilities after IDENTIFY? Alex answered because they can be different after AUTHENTICATE.

Frank Dawson asked why application capabilities, like MINDATE and MAXDATE, are returned by a transport commands? Alex answered that these capabilities should be moved but not sure where?

2. Read From a Single Calendar
c: Content-Type:text/calendar;method=read;component=VEVENT
c: VERSION:2.1
c: CMDID:xyz12345
c: TARGET:cap://cal.example.com/opaqueid99
c: AND DTSTART <= 19990715T080000Z);
c: .

Steve noted that there is now a single transport command SENDDATA with mime encoded data that contains a CMDID at the application level.

Someone noted that each property in the SELECT statement needed a VEVENT prefix to distinquish VEVENT properties from VALARM properties. Steve made the changes in the example.

Lisa Lippert asked where was VSCHEDULE, i.e., do we need a query to list all tables? Lisa suggested that you should be able to list the table definitions that the calendar store supports. Steve answered that this still needed to be worked out.

Someone asked if they would need to fully implement SQL, including joins? Steve answered no, the use of SQL syntax in CAP is to leverage the familiarity of SQL syntax among implementors and that CAP would not require a full SQL implementation.

Someone made the comment that SQL syntax used in this way was confusing. Others disagreed. Steve stated that the SQL syntax is well understood by programmers and that the CAP data model maps nicely into SQL. Another suggestion was made that the grammar should either be just like SQL or grossly different so as not to lend any ambiguity or confusion to the interpretation of the grammar.

# this response code means that the transport succeeded # in delivering the data.
s: 2.0
s: Content-Type:text/calendar;method=response;
s: optinfo=version:2.1
s: Content-Transfer-Encoding:7bit
s: VERSION:2.1
s: TARGET:cap://cal.example.com/opaqueid99
s: CMDID:xyz12345
# we have not yet discussed response-status
s: DTSTART:19990714T200000Z
s: DTEND:19990714T210000Z
s: UID:004488929922
s: SUMMARY:blah, blah
s: UID:00348480980388889889443
s: SUMMARY:meeting
s: DTEND:19990714T233000Z
s: DSTART:19990714T223000Z
s: .

Steve noted there is a new VERSION value (2.1) and a new method RESPONSE and corresponding RESPONSE-STATUS. Also, that TARGET and CMDID are returned.

Keith Moore wanted to understand how query would work on events with timezones. Will a CUA have to convert timezones or is this done by a CS? It was generally agreed that the CUA should do this conversion however a CS would still have to interpret recurrence rules correctly to satisfy queries and this would require timezone conversion. Interpretation of timezone appears to be addressed in the CUA by this version of the draft. If this isn't the optimal approach, then we need to change this in the spec.

Someone asked if text after response codes were optional or required. What did the list decide? It was agreed that the draft's examples should include text after response codes to make the examples more readable.

Someone noted that there is a bug in RFC 2445 ABNF. The text and intent of the spec was that properties in a component are unordered, but the ABNF prescribes an order. The ABNF needs to be fixed. John agreed to post this on the list.

Steve than presented an example that reads from multiple calendars. He noted that 2 targets are identified, one relative and another fully qualified. Responses are multipart/mixed, with each target identified.

Frank commented that this seems to have some performance and scalability issues. Why not return the values when you get them and allow the CS to send back partial results. There was considerable discussion on this point.

What about delayed responses? How to prevent mixing application responses from transport responses, e.g., there might be a single application request that results in multiple transport responses, and how to match them?

Why not return "not done" response code? The channel would still be blocked since there is no way to match requests to responses unless they occur right after each other. Nick and Alex pointed out that the server can send partial results and block the channel until such time it gets all the results sent back to the CUA. In any case, a synchronous REQUEST/RESPONSE form appears to be the best way to go with this.

It was agreed that more discussion on the list was required to resolve these issues.

Steve than presented an example that addressed bounded latency.

John had a concern about rollback when a CS confronts the bounded latency problem. If the CS was sending out an iMIP message as a part of the operation there is no effective way to retrieve or abort it. Frank pointed out that we could address this issue of rolling back an iMIP portion of the operation by specifying in the draft that any such iTIP portions of the operation must not be sent until all other portions of the operation complete successfully. General acceptance of this solution.

Doug Royer asked if an ABORT can be issued at any time (i.e., an asynchronous ABORT). The answer was NO. Can only issue the ABORT when the current operation finishes.

John Stracke indicated that he had some issues with the CAP registration process. He will take the action item to conduct a formal review.

Bob Weiler suggested that there should be examples with hierarchy that uses PARENT and CHILD properties.

Hallvard Furuseth suggested that there should be examples that show, for example, searches where the use of only the property name would be ambiguous (e.g., VEVENT.DTSTART, VTODO.DTSTART or even VEVENT.ALARM).

Repectfully submitted by Frank Dawson/Lotus, Richard Shusterman/Netscape and Pat Egen/Patricia Egen Consulting


None received.