NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.
Robert Moskowitz <firstname.lastname@example.org>
Anik Ganguly <email@example.com>
Applications Area Director(s):
Keith Moore <firstname.lastname@example.org>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
General Discussion: email@example.com
To Subscribe: firstname.lastname@example.org
In Body: [SUBSCRIBE/UNSUBSCRIBE in Message body]
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 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:
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.
Submit revised Internet-Draft of Calendar Interoperability Protocol.
Submit core object specification to IESG for consideration as a Proposed Standard.
Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft.
Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard.
· Internet Calendaring and Scheduling Core Object Specification (iCalendar)
· Core Object Specification - Issues Document
· Calendaring Interoperability over HTTP (CIH)
· Real-time Protocol Requirements
· iCalendar Message-based Interoperability Protocol (iMIP)
· Internet Calendar Model Specification
· iCalendar Transport-Independent Interoperability Protocol (iTIP) Part One: Scheduling Events and BusyTime
· iCalendar Transport-Independent Interoperability Protocol (iTIP) Part Two: Scheduling To-Dos
· iCalendar Transport-Independent Interoperability Protocol (iTIP) Part Three - Scheduling Journal Entries
No Request For Comments
Minutes of the Calendaring and Scheduling Working Group
Reported by: Alex Hopmann
Anik Ganguly, WG Co-chair, called the meeting to order at 7:30 pm and reviewed the following agenda.
1930 - 2200 (7:30 - 10:00 pm)
19:30 Agenda Review
19:35 Discuss Model Document
Title: Internet Calendar Model Specification
Author(s): J. Noerenberg
Author(s): J. Noerenberg
20:20 Discuss iTIP Part 1
Title: iCalendar Transport-Independent=Interoperability
Protocol (iTIP) Part One: Scheduling Events and BusyTime
Author(s): S. Silverberg, S. Mansour, F. Dawson, R. Hopson
Author(s): S. Silverberg, S. Mansour, F. Dawson, R. Hopson
21:05 Discuss iCalendar
Title: Internet Calendaring and Scheduling Core Object
Author(s): F. Dawson, D. Stenerson
Author(s): F. Dawson, D. Stenerson
21:50 Review Next Steps
Setup Agenda for Tuesday meeting
22:00 Collect WG Roster, Adjourn
10:15 - 11:15 am
10:15 Discuss iTIP part
11:15 Collect WG Roster, Adjourn
II. Model Document
The first item of business was discussion of the Model Document. A number of editorial changes were identified and accepted for the next revision. There was some discussion of the use of the term, "minimal requirements" in the model document and it was agreed that the term, "minimal" would be removed.
The model document made reference to the exchange of calendar properties using iTIP. Since iTIP does not really allow property exchange, the model document will remove this statement.
There was a suggestion to describe how to-dos can roll over from day to day. This was rejected because the model document should be as general as possible with respect to the objects that can be exchanged between protocol elements and since we did not envision adding to the model document whenever a new object was added.
There was a discussion of the role of the owner and organizer, and it was decided that the model document would describe these and in particular the policy regarding ownership of entries in a calendar. There was a great deal of discussion on the notion of an authoritative store. The issues underlying this discussion are: the existence of multiple copies of a user's calendar, the access to them, and the resolution of differences among them.
Since the model document has two distinct purposes, it was suggested that the document be separated into two. One would be the abstract model itself and would say as little as absolutely necessary in an effort to be descriptive but not overly constraining. The second would describe by way of numerous examples and scenarios how the calendar specification might be applied. This would be an aid to implementers who had not participated in the creation of the specifications. This suggestion was rejected in favor of keeping both sections in one document, with appropriate guidance to readers. The model document would eventually become an Informational RFC.
With that, the discussion of the model document was closed, and the iTIP editors were invited to discuss their document.
III. ITIP (Part 1)
The editors listed the recently resolved issues from the ongoing discussion on the mailing list and identified a collection of typographical and grammatical errors that would be addressed in the next draft. The issue of delegation was discussed, and in particular, questions were raised about multiple people delegating the same meeting to the same person, and about the method to avoid looping. It was resolved that multiple delegations will be accepted.
The iTIP editors restated the long-standing criticism about the structure and semantics of the profile property and offered a solution. The solution is to separate the information contained in the profile into two attributes. The name of the component/object would be specified implicitly by the iCalendar object and a new property would specify the method/verb (e.g., request, cancel etc.). The MIME headers specified in iMIP would specify both the component and the method explicitly as parameters on the Content-type header. This proposal was accepted.
On the subject of return codes, it was stated that experience has taught that 3-digit return codes are problematic because of the finite nature of the space they could represent. The solution of dot-separated, hierarchical return codes was offered and accepted.
There was discussion about generation of UIDs, and Pete Resnick suggested that the DRUMS WG had come up with a good solution and that we should use the same solution. He took the assignment to get the solution from DRUMS to the editors of iTIP. Members of the audience noted that if the solution was structured as local-part@hostname, the local-part better not have meaning. They also noted that it was essential to specify a maximum length for the UID.
The iTIP editors noted that they were still working on and open to discussion on when to increment the sequence number for an event and suggested that the issue be discussed on the mailing list.
Finally, the iTIP editors discussed the plan for completing the document. They wanted to finish the next revision of the document in 6 weeks. A question was raised about the relationship between the model document and the iTIP document. The chair noted that, contrary to the charter, it made sense to submit the two documents (and indeed iCalendar also) at the same time to make sure that there were no inconsistencies between the documents. The iTIP editors noted that if both drafts were revised in the next several weeks, the WG members at large could help ensure that they were consistent. A question was raised about the need to submit one or more bindings for iTIP with the submission of iTIP to the IESG. A mail binding is in the works and a second binding, to a real-time transport, would demonstrate the transport independence of the iTIP specification. This led to an inconclusive discussion of the merits of HTTP as a real-time protocol for calendar interoperability as time ran out.
Next, the editors of the iCalendar specification discussed the few open issues with that specification.
The issue of version and profile-version was discussed and it was decided that Alex would submit to the mailing list a proposal for a mechanism that would flag individual properties with the Fail parameter if a receiver that does not comprehend the property encounters it. The default behavior of the receiver would be to simply ignore the property. This was accepted as a reasonable solution to the problem.
The time-zone syntax was criticized as too wordy. It was decided that a concrete alternative should be proposed on the list by Harald Alvestrand as soon as possible and no later than four weeks so this issue gets resolved.
There was an issue with multiple layers of encoding in the specification and Chris Newman took an assignment to specify the solution to this problem.
There was discussion again about the package of specifications that should be submitted together and someone raised the issue of the calendar access protocol. It was decided that the model document would make a reference to the access protocol and explain the distinction between the interoperability and access protocols but that, as agreed before and documented in the charter, the work on the access protocol would continue after the submission of the interoperability protocol. Further, if the model document needed revision to support the access protocol, a new RFC would be published to obsolete the original.
V. iTIP (Parts 2 and 3)
There was significant disagreement, even among the iTIP editors, about the need to support to-dos and journal entries at the same time as events. Some felt that the specification would be incomplete without them and others felt that the specification of to-dos and journals did not have sufficient depth and the quality of that part of the specification was suffering as a result. Also, the volume of the specification was daunting.
After significant debate that appeared not be converging, the chair suggested that the WG has accepted a time of about six weeks for revisions of the iTIP documents. That time should be allowed to enable anyone to surface substantive issues that would prevent the editors from coming to closure on to-dos and journals. And if none arose, those components would remain in the specification.
The meeting adjourned for the night at 10:05pm and was scheduled to continue at 10:15am the following morning.
The meeting reconvened on12-Aug-1997, 10:15am.
There was some discussion to confirm the conclusions of the previous night regarding iTIP. First, to-dos and journals would be presented alongside events and the iTIP specification would no longer have three distinct parts. A unified presentation of the objects and the methods that apply to them is the goal.
The chair made introductory remarks on the importance of properly addressing security in the specifications that the WG submitted to the IESG. The ADs underscored this point but pointed out that there were no easy answers. At the chair's request, the AD for Security, Jeff Schiller, had asked Paul Hill and Bob Mahoney to work with the CalSch WG to make sure that the protocols adequately addressed security. Bob and Paul led the discussion and identified the areas of concern as authentication, encryption and authorization. The current iTIP does not address the authorization issue and the feeling was that it should because it is a transport-independent issue.
The issue about the availability of an S/MIME specification as a mechanism that the calendar protocol could refer to was raised. It was stated that the only available, referenceable mechanism is PGP/MIME.
A suggestion was made that the security model be described in the model document and this was accepted by the editor of the model document who invited contributions.
Bob and Paul accepted the assignment of posting a threat model to the mailing list so that it could be discussed and incorporated into the model document. Additionally, the protocols themselves would specify the mechanisms they use to mitigate the various threats. The editors of iTIP and iMIP agreed to address security in their next revisions.
The Internet Draft that is supposed to provide protocol writers guidance on writing the security considerations section is available as draft-iab-secwks-sec-guidelines-00.txt.
VII. LDAP Schema
Alec Dun led a discussion of a proposal he had made for using LDAP to locate a user's calendar and to store free-busy information in the directory. He described the proposal briefly, the associated draft is draft-dun-calsch-schema-00.txt. He also noted that he was proposing that the vCard schema be extended to include the calendar related attributes.
Several issues were raised about the proposal, including:
1) How to associate multiple calendars with a user
2) The impact of putting free-busy time data inside a directory
3) The calendar URL as specified in the proposal is very mail centric and may not be appropriate for some systems
4) Security implications of the existence of this data in the directory
5) Effect of LDAP caching on the calendar applications
6) The dependence of the implementations of the CalSch protocols on LDAP
7) Lack of clarity on whether this is a mandatory or optional mechanism
Based on these objections, and a general sentiment that we need a simple, non-LDAP dependent, solution to locate a user's calendar server, Alec took the assignment of specifying the problem that the proposal attempted to solve and get consensus on the list before we continue the discussion of the details of the solution.
The chair noted that the following work items were committed at this meeting:
1) Model document 3rd revision with the results of the discussions at this meeting
2) iCalendar document 4th revision with the results of the discussions at this meeting and anything needed to support iTIP
3) iTIP document 2nd revision with the 3 parts merged, new format for presentation, security considerations and the other results of the discussions at this meeting.
4) iMIP/iRIP binding documents first drafts.
Roster Not Received