NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Anik Ganguly <anik@ontime.com>
R. Moskowitz <rgm3@chrysler.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
H. Alvestrand <Harald.T.Alvestrand@uninett.no>
General Discussion:ietf-calendar@imc.org
To Subscribe: ietf-calendar-request@imc.org
In Body: [SUBSCRIBE/UNSUBSCRIBE in Message body]
Archive:
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:
· 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". · 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. · 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 Interoperability 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:
· MIME Calendaring and Scheduling Content Type Profile
· MIME application/calendar Content Type
· Calendaring Interoperability Protocol
· Internet Calendaring and Scheduling Core Object Specification (iCalendar)
· Core Object Specification - Issues Document
· Calendaring Interoperability over HTTP (CIH)
· Real-time Protocol Requirements
Reported by: Ross Hopson (rhopson@on.com)
Anik Ganguly, co-chair, opened the meeting and began with a review of the agenda:
a1) Agenda Review a2) CalSch status report a3) Discussion of iCalendar Core Object Specification Draft <draft-ietf-calsch-ical-01.txt>, with the goal of issuing a last call after the next edit. A4) Discussion of protocol requirements <draft-ietf-calsch-rtreq-00.txt> and solution approaches using TCP versus HTTP versus SMXP, with the goal of selecting a transport and producing a draft.
The origin of the CalSch Working Group was reviewed. The Working Group began with a lunch meeting at the 36th IETF conference. The charter was approved on October 29, 1996, and the Working Group first met at the 37th IETF conference.
The CalSch status report began with a review of the original schedule. The Working Group is behind schedule for submitting iCalendar to the IESG, so a "straw man" revised CalSch schedule is proposed:
May 1997 - Submit the iCalendar Internet-Draft to IESG for consideration as a proposed standard. The Working Group accepted this. May 1997 - Agree on interoperability requirements. The Working Group accepted this.June 1997 - Submit Draft One for:
b1) Transport Independent Interoperability Protocol Internet-Draft b2) Real-time binding for Interoperability Protocol I-D b3) E-mail binding for Interoperability Protocol I-D
The Working Group accepted this. However, a question was raised concerning whether there might be too many CalSch drafts and whether some of them might be combined. It was agreed that a clarification of the drafts is needed.
July 1997 - Submit Draft Two for: b1), b2) and b3) above. The Working Group accepted this.
August 1997 - Submit to IESG for consideration as a proposed standard for: b1), b2), and b3) above. The Working Group accepted this. It was asked if it would be necessary to have a demonstration of interoperability before submitting the draft, and it was decided that this is not required.
December 1997 - Submit Draft One for: Access Protocol I-D. There was discussion and general agreement that work on the access protocol draft should wait until other drafts (such as iCalendar) have been completed, and that there is no need for further discussion of access protocol until there is more Working Group agreement on supporting issues. It was stated that an access protocol draft has been written, <draft-oleary-icap-01.txt>, but it was agreed that discussion of the draft should wait for acceptance of the iCalendar draft. It was asked whether there is a need for an access requirement document, and it was determined that this would be necessary.
Next the CalSch products (documents) were reviewed:
iCalendar - <draft-ietf-calsch-ical-01.txt>
This document defines the system model that is used to define the CalSch protocol suite. As such, it defines the abstract communicating entities, their roles and their potential communication capabilities (e.g., intermittently connected versus constantly connected). With the entities clearly named and defined, this model will go on to explain the intended application of each protocol that is defined by CalSch. Further, this document defines a framework for constructing objects that will be used in the CalSch protocol suite. It defines the object model, the object representation and encoding rules, the data types that are used in the objects, and it contains an exhaustive list of attributes. This document also defines the administrative procedure for creating conforming objects.
InteropProtocol - <draft-ietf-calsch-cip-00.txt>
This document defines the transport independent protocol that can be used by communicating entities to accomplish calendaring and scheduling tasks with another entity.
InteropProtocol Real-time Binding
This document defines how the InteropProtocol will work over a real-time connection.
InteropProtocol E-mail Binding
This document defines how the InteropProtocol will work over E-mail.
This document defines the protocol that can be used between a client with calendaring and group scheduling capabilities to talk to a server that offers those capabilities.
Discussion of the iCalendar draft began with the introduction of Derik Stenerson and Frank Dawson (co-authors of the draft). An overview of the current status of the draft was presented:
c1) The current draft is <draft-ietf-calsch-ical-01.txt>, and the goal is to submit the draft as a standards track in May 1997. c2) The following change requests were identified: add a system model description, add an object model description, corrections to BNF, editorial changes, and addition of clarification text. c3) The last call revised document to be ready by May, 1997 time frame.
Derik and Frank asked the Working Group for new issues concerning iCalendar, and made a list of these:
d1) The recurrence rule grammar should be changed back to the original format (type: grammar).
d2) Use of the property parameter should be minimized (type: grammar).
d3) Classify the properties into a core subset of properties and the more complete set (type: model/conformance).
d4) The use of the terms "Value Type" and "Type" as parameters of a property value are confusing; change the names of the property parameter (type: editorial).
d5) The registration process is complex; remove it and require any new profile to be defined as a standards track document (type: process).
d6) There is a need for a clear description of the model used by iCalendar (type: model). Resolution: The Working Group agreed that this will either be a separate document (general consensus) or added as an introduction to the iCalendar document.
d7) Change BNF to an acceptable form, such as a single specification, rather than the iterative form in the current document (type: grammar/editorial).
d8) Ensure conformance to MIME (type: process).
d9) Extensions are needed to handle resource-scheduling specifics (e.g., video-conferencing) (type: model).
d10) Local time usage needs to be clarified to avoid potential interoperability issues (type: editorial/model).
d11) Non-significant LWSP-Characters should be restricted everywhere (type: grammar).
d12) The need for PROFILE-VERSION is questioned (type: grammar).
d13) The DUE property value should be limited to DATE-TIME and not allow DURATION (type: grammar/model).
d14) UID uniqueness needs to be strengthened by providing hints (e.g., add "@domain").
Due to time constraints, it was suggested that the list be discussed in order of priority, and the two highest priority items were determined by the Working Group to be d6) and d3).
The issue of defining the calendaring model before discussion could continue about iCalendar was raised, and a sketch of the system model was requested, which was begun to be drawn on a slide. It was suggested that the model be developed after the meeting in a small group rather than on the overhead with 50 onlookers. The question was asked whether separate model documents would be required for calendar objects and their transmission. It was stated that there should be separate documents for the system and object models. The need for separate model documents was discussed. The need was defined by saying that there had not been enough interest in an architectural document when the Working Group was formed, so one was never written. It was suggested that, since the Working Group members are already together at the conference, they convene outside the Working Group meeting to draft a document by the end of the conference. The problems of producing such a draft were discussed. It was said that it would be very difficult to produce an architectural document due to the diversity of calendaring products currently available, and that there is no one "correct" way to do group scheduling. Asking for an abstract document (rather than an architectural document) that would describe one true set of "over-the-wire" descriptions or protocols in abstract form continued this thought. There was consensus among the Working Group for this action.
Time had expired for this part of the meeting, so a discussion of the other issues was left for email. Derik agreed to put together a new iCalendar issues list.
The meeting continued with the introduction of Steve Hanna, who began the discussion of real-time protocol requirements for interoperability <draft-ietf-calsch-rtreq-00.txt>. Each of the requirements (as defined in the rtreq draft) were described and displayed on a slide which showed the real-time requirements and the strengths and weaknesses of each protocol (HTTP <draft-ietf-calsch-cih-00.txt>, TCP <draft-ietf-calsch-cip-00.txt>, and SMXP) as they pertain to these requirements:
Real-time Requirement | CIH | CIP | SMXP
------------------------|-------|-------|-------
Bounded Latency | Fix | Fix | Fix
------------------------|-------|-------|-------
Simple | Weak | Strong| Strong
------------------------|-------|-------|-------
Existing Technology | Strong| OK | OK
------------------------|-------|-------|-------
Efficient | Weak | Strong| Fix
------------------------|-------|-------|-------
------------------------|-------|-------|-------
------------------------|-------|-------|-------
Address Resolution | OK | OK | Fix
------------------------|-------|-------|-------
Deploy and Administer | Weak | Weak | Weak
------------------------|-------|-------|-------
A discussion was held of what would be required to modify CIP and SMXP so that they would meet all the real-time requirements. It was agreed that SASL would fix the security problem. There was concern over deployment, as several attendees stated that firewalls might be a problem, explaining that it is often difficult to convince administrators to open firewalls for new applications. Concern was expressed over modifying SMXP to meet all the requirements. It was felt that this would remove one of SMXP's greatest assets, which is its simplicity.
Discussion was held concerning CIH and whether interoperability could be done using existing HTTP. While it was agreed that the infrastructure for HTTP already exists, there was a list of several questions for the Working Group:
· How would port numbers be handled? It was determined that it is fairly easy to get a port number assigned by the IANA. · How would URL's be resolved? It was explained that this could be done using LDAP or URN's (Universal Resource Names). · Would the HTTP POST command be sufficient? It was indicated that any server can handle POST commands. · Would caching and proxying pose problems? It was explained that with the HTTP v1.1 implementation, caching can be configured on a 'by request' basis. There was concern over whether this would work with v1.0 HTTP. · How would bounded latency be handled? It was determined that this problem was also covered by the v1.1 HTTP specification.
There was not a group consensus concerning which protocol would be best. Time was running out, so it was asked whether it was possible for the Working Group to agree on the real-time protocol requirements. It was also asked whether bounded latency would be a problem. There was consensus among the Working Group that bounded latency might not be necessary as it is not a requirement in any other protocol. There was consensus among the Working Group to accept the real-time requirements without bounded latency, and the discussion of and consensus over a single real-time protocol would be continued on the mailing list.
Anik adjourned the meeting at 3:05 pm.