Editor's Note: These minutes have not been edited. Minutes for the Calendaring and Scheduling (CalSch) Working Group 38th Internet Engineering Task Force Memphis, Tennessee April 8, 1997 1:00pm CDT Reported by: Ross Hopson (rhopson@on.com) Co-chair, Anik Ganguly 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 , with the goal of issuing a last call after the next edit. a4) Discussion of protocol requirements and solution approaches using TCP vs. HTTP vs. SMXP, with the goal of selecting a transport and producing a draft. The origin of the CalSch WG was reviewed: the WG began with a lunch meeting at the 36th IETF conference, the charter was approved on October 29, 1996, and the WG first met at the 37th IETF conference. The CalSch status report was begun by reviewing the original schedule. The WG was behind schedule for submitting iCalendar to the IESG, so a "straw man" revised CalSch schedule was proposed: May 1997 - Submit the iCalendar Internet-Draft to IESG for consideration as a proposed standard. The WG accepted this. May 1997 - Agree on interoperability requirements. The WG accepted this. June 1997 - Submit Draft 1 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 WG 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 was needed. July 1997 - Submit Draft 2 for: b1), b2) and b3) above. The WG accepted this. August 1997 - Submit to IESG for consideration as a proposed standard for: b1), b2) and b3) above. The WG accepted this. It was asked if it would be necessary to have a demonstration of interoperability before submitting the draft; it was decided that this was not required. December 1997 - Submit Draft 1 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 was no need for further discussion of access protocol until there was more WG 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 was a need for an access requirements document, and it was determined that this would be necessary. Next the CalSch products (documents) were reviewed: iCalendar - - 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 vs. 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 - - 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. AccessProtocol - 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 ; 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 WG 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 WG 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) Insure 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; the two highest priority items were determined by the WG to be d6) and d3). The issue of the need to define 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 WG was formed, so one was never written. It was suggested that, since the WG members were already together at the conference, they convene outside the WG 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. This thought was continued by 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. There was consensus among the WG for this action. Time had expired for this part of the meeting, so a discussion of the other issues were 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 . 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 , TCP , 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 ------------------------|-------|-------|------- Scaleable | OK | OK | Fix ------------------------|-------|-------|------- Secure | OK | Fix | 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 WG: 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 WG to agree on the real-time protocol requirements. It was also asked whether bounded latency would be a problem. There was consensus among the WG that bounded latency might not be necessary as it is not a requirement in any other protocol. There was consensus among the WG 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. Anik Ganguly OnTime Campbell Services Inc. http://www.ontime.com