NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98
Robert Moskowitz <firstname.lastname@example.org>
Anik Ganguly <email@example.com>
Applications Area Director(s):
Keith Moore <firstname.lastname@example.org>
R Gellens <Harald.Alvestrand@maxware.no>
Applications Area Advisor:
R Gellens <Harald.Alvestrand@maxware.no>
To Subscribe: email@example.com
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) Scheduling Events, BusyTime, To-dos and Journal Entries
· CAP Requirements
· iCalendar Real-time Interoperability Protocol (iRIP)
No Request For Comments
Minutes of the Calendaring and Scheduling (calsch) Working Group
Minutes by Keith Rhodes (mailto:firstname.lastname@example.org)
I. Agenda Review
The meeting called to order at 9:30AM PST by chairman Anik Ganguly.
There were two time slots reserved for CALSCH, a two-hour block on March 30, and a one hour block on March 31. During the March 30 meeting, final discussion on iCalendar, iMIP and iTIP would occur. After that, the CAP and iRIP protocols would be discussed.
The agenda was discussed and approved.
II. iCalendar, iMIP and iTIP Last Call
The last call for the iCalendar, iMIP and iTIP documents was issued this morning (March 30, 1998)
Any open issues in these documents are being addressed in one of three ways:
1. The issue will be examined and determined that it is a non-issue.
2. The issue will be examined and will require further clarification in the documents
3. The issue will be examined and will require a technical change. This type of change which will occur in future revisions of the specifications.
The consensus from the group was that the submission plan was acceptable and last call for the three documents was accepted.
III. General discussion, led by Bob Moskowitz
The area of Security is of concern. The Security group's RFC 1847 style security will be used for now. We will not wait for S/MIME or OpenPGP working groups to finish their work. When a security RFC standard is available, it will be looked at. By the time we go to draft standard, it is hoped that the security RFC's will be completed and the CALSCH standards will then reference the new security RFC's.
The Model document has fallen out of synchronization. We need to look at how to get the Model document up to date in the next few weeks. John N. has agreed that he will bring the Model document up to date. The Model document may end up being the blocking factor for the submission. John N. agreed to bring the Model document back into synchronization with the others.
IV. Calendar Access Protocol Requirements discussion
The goal for this discussion is to provide clarification and get agreement on the CAP requirements.
Opening statements by Andre:
Andre made the opening statements about the CAP protocol. He said, "ICAL is data, ITIP is interoperability, CAP defines Access methods to the Calendar store."
Why do CAP now? If we focus on the requirements now, we can move forward quickly. It would also shortcut any late submissions, which may be good, but are too late in the process.
The CAP requirements document is just the first crack at this process. It is the equivalent of IMAP4 for mail to allow communication between the User Agent and the Calendar Server.
The discussion then focused on the CAP requirements document, on a point by point basis. It was quickly determined that the organization of MUST and MAY requirements didn't make sense. It was thought the organization should be a ranked order of prioritized requirements.
The protocol will support two connection modes; Data stored only on the server; and Data stored on both the client and the server and synchronized between the client and server. We don't consider a situation where the implementation is client-only, because you don't need an access protocol to access local data. If a local access protocol is required, the client would provide the server-side protocol to access its data.
Some one offered that it was OK to put both the client and server protocols together, as long as we can't determine that any protocol violation has occurred from the outside, looking in.
Discussion then centered on the issue of having a multi-master implementation. There were conflicting opinions on both sides of the argument, so it was deferred to the mailing list.
Define a calendar address: Calendar stores must be uniquely identified. This may be the same as what exists in the iCalendar specification.
A New MUST requirement was added: Support ability to read, write, modify, and search for iCalendar components. Discussion started to make sure international searching was provided for. It was emphasized that searching the full UTF-8 range was necessary. The search discussion collapsed to a requirement of "MUST have the ability to search for any calendaring component"
It was proposed that we need to make add operations atomic and send back proper return codes if properties that should be added together did not complete successfully. Discussion continued to see if this should be a MUST or a MAY. It was deferred to the mailing list.
Hierarchical calendar stores: The top level store is a rollup of the calendars beneath it. This came from a similarity to IMAP 4.
Group names as shortcut: Question as to whether we allow granting of ACL's using Group names. This has not been decided. Question as to when the Group Name is expanded is too early in most products. New members to the group are typically not updated when the group has new members added to it. Discussion: Why isn't that a capability provided by LDAP?
Question: Have the client control the bounding of latency, instead of having two requirements of providing for interrupting a communication and a separate mechanism for having a bounded latency capability.
Question: Can you start a request in one session and cancel it in another session? Discussion terminated by saying that this is too specific of a discussion for a requirements specification. Harald then said that we don't even know how you will connect between the client and server, so how do you know if you will even have a session. The group should focus on what capabilities should be provided. Example: Do you allow many people to access a calendar store. Not the implementation specifics of whether you allow simultaneous access, which is implementation specific.
New requirement: provide simple command extensibility mechanism.
Calendaring was area where locale specific issues that would be different form one area to another and should be able to handle it. Example: Protocol should deal with time zones properly. Is it 10:00am specific to your current time zone or specific to PST. Summary: protocol should address the rich set of requirements for the variety of time zones which are used. Follow up: Protocol should be able to be agnostic about time zone information and communicate it in the same way as iCalendar does.
The discussion changed to discussing user directories and how CAP would need access to it.
Question: Why does the protocol need to know the location of each users calendar store? Shouldn't it be dynamic? The answer is we need to read/write/search for user attributes which are specific to calendaring.
A fundamental point of debate then began, centered around the question, "Should we provide minimal directory services in the protocol or should we use LDAP?" A variety of comments follows along these lines.
Everything in a calendar object seems fair game for the access protocol and vice versa. If you want inter-site calendaring, what is the expectation that people will allow unlimited access to their information, or will it be only provided via some other more secure mechanism.
It is not the purpose of the calendaring server to collect groups of users on a calendaring server. It is only used for administrative purposes, not to support user functions.
Directory style access is outside the CAP Protocol. It sounds that we need to provide for new objects added to the protocol, like groups of users. It does seem that we need a mechanism to store user specific calendaring properties. The user in this case is a named calendar, which may be identified with a specific user.
A group of users is an entity which will be defined outside the context of calendaring and throw it over the wall to the directory people if possible.
As long as a user is defined externally and uniquely, CAP should not place any additional restrictions.
The discussion ended without any definite conclusions.
A new discussion arose around the need to add administration to the CAP protocol. It was further discussed that a minimal protocol was need for user administration. There was also some talk of splitting administration into a companion draft.
The search requirement for free/busy time was thought to be too detailed. The requirement needs to be more general and not so product specific. It was also said the problem needed to be defined in the context of the internet. A lengthy discussion ensued about the problems of putting implementation details into a requirements specification and the difficulties in striking the proper balance. This issue was deferred to the mailing list.
CAP Discussion Conclusion
The authors indicated that the protocol has received NO comments on the mailing list and it needs more input.
Working Group Conclusion
The next steps for the working group:
1) Submit the three specifications to the Area Directors.
2) Set the agenda for the March 31 meeting
a) There will not be a continuation of the CAP discussion as the editors need think time.
b) The LDAP locate calendaring information draft at draft-dun-calsch-locate-02.txt
c) The iRIP draft discussion
d) Discuss interoperability
The 1st meeting was adjourned.
Minutes of the Calendaring and Scheduling (calsch) Working Group - Second Meeting of the WG
I. Agenda Review
The meeting called to order at 10:15AM PST by chairman, Anik Ganguly.
The agenda was discussed and approved.
10:15 iCalendar Real-time Interoperability Protocol (iRIP)
10:40 Calendar Attributes for vCard and LDAP - draft-dun-calsch-locate-02.txt
11:05 Discuss Interoperability Workshop
II. iRIP Discussion (by Andre and Steve)
What is iRIP? Real time binding for iTIP. It has commands for sending around iTIP messages in real-time. It will write messages to the calendar store, as needed. It is not intended to be a replacement for CAP.
Whereas iMIP will require user action to accept a message, iRIP will not require the user to get into the loop. Things can be queried for without user interaction, like a Free/Busy request.
You could receive a iMIP request and answer via iRIP. There are no concurrency problem. IRIP is just a faster way of delivering calendaring information. The basic sequencing protocol of iTIP will allow these systems to work together.
Question: Will this allow a remote user to change something in a user's calendar? NO, that is a CAP capability. Its like email is designed to get things into a publicly available in-box. IRIP is similar to that. There is authentication to challenge users.
Comparing iRIP to CAP:
· Much simpler than CAP
· Limit capabilities which are exposed on the network
· Practical alternative for making legacy systems interoperable
· Different purposes: iRIP: interoperability, CAP: full access and management of the calendar store.
III. IRIP State Diagram Discussion
First thing that is done is to authenticate itself, by saying who I am and here are my credentials. We intend to use SASL for authentication. Documents to understand SASL are included in the bibliography of the iRIP protocol specification.
Question: Is authentication optional? It is not optional, but SASL allows you to use anonymous as valid access mechanism. Plain text password is also provided by SASL. It allows you to use whatever level of authentication and security is desired and is outside the definition of iRIP.
AD input for SASL: It is a draft protocol. The mechanism that is on the standards track is <something> 5. If you want to use plain-text password, think really hard. If you choose SASL you are not locking in the implementation. Ads suggested that the editors talk to Chris Newman.
The iRIP protocol has bounded latency and the server will wake up after a timeout. The client can then choose to continue the request or cancel.
· Continue - used when bounded latency timeout has hit and the client tells the server to continue
· Recipient - who is designed to get this message. Not the list of attendees in the iCalendar object
· Switch - if you have connected to another irip server, to allow other server to send the local server information. This is useful when you have a firewall which prevents a connection.
In SASL you can only authenticate one-way, so the switch command may be a problem. Andre will check into this issue.
Question: What is the purpose of bounded latency? Original purpose: the critique of original spec had this as an criticism. This can obviously be done by the client by an abort command.
Question: Since this is real-time, what will happen when you have a broken connection before this response is received? This needs to be addressed in the spec.
IV. Calendar Attribute for vCARD and LDAP (by Alec Dunn)
The basic problem this draft tries to address is "Why does a User want to locate a calendar?"
a) to determine where to send an iCal request (iMIP or iRIP)
b) to directly access/manipulate a calendar
c) to look up published free/busy time without accessing the calendar directly
d) to look up published iCal objects, like a snapshot of a persons calendar
Solution: Define URLs to refer to:
a) the location of the calendar itself, which is a place holder for CAP
b) the location to which iCal requests should be sent
c) the location of published free/busy data
d) the location of published iCal data
How to communicate these URLs to others:
a) out-of-band (tell the person the URL)
b) vCard exchange mechanism
c) Directory lookup, using something like LDAP
Question: Did you consider URNs instead of URLs because they are persistent?
Answer: If we were to say these were URIs, that would be fine.
Defined in draft
a) New vCard properties
b) New LDAP auxiliary object + attributes for LDAP. Object extends person, meeting room, or any top level LDAP object.
c) Mechanism for finding a directory entry given an e-mail address.
d) Support for multiple calendars
If you have multiple calendars, there is a preference parameter to tell you which is the preferred calendar.
We parroted what was done on the LIPS working group for email. If you are doing LIPS-like email, this looks very similar.
CAPURL - A CAP URL pointing to the user's calendar. Format/value of URL TBD in CAP protocol.
CALADRURL - A URL pointing to the communication end-point to which iMIP/iRIP meeting requests should be sent. Example: mailto:email@example.com
FBURL - A URL pointing to a published snapshot of the user's free/busy time (an iCal object containing one or more vFreeBusy components). Example: ftp://host/user/fb.ifb
CALURL - A URL pointing to a published snapshot of the user's calendar (an iCal object containing one or more vEvents, vTodos, or vJournal components). Example: ftp://host/user/cal.ics
There was an objection to using one attribute for both iRIP and iMIP. The current proposal does not associate the protocol (iRIP or iMIP) to the URL. It was suggested by the authors that if you had both iMIP and iRIP, you would make one preferred and the PREF would tell you which one. Further, you don't want to have to change the schema each time there is a new binding of iTIP. The assumption would that the iRIP will have a similar mechanism to MAILTO, which is used for iMIP.
It was then asked, What needs to happen for this to be commercially accepted? This would be good to have this published as a informational RFC. We need an AD to be a sponsor and a working group to charter it, even for an informational RFC.
This is really using another working groups activities for the purposes of CALSCH. It is not in the purview of LDAPEXT or any other working group. It was then decided that this needs to be a submission of the CALSCH working group, not an individual submission.
V. Interoperability Workshop
Bob Moskowitz then led a discussion about Interoperability Workshops.
He has had real-world experience in doing the implementations of developing the first generation. Its better to do it during development in a workshop, than to do it during a public comparison and fail.
He was willing to help design the workshops. These are engineering workshops, not marketing. The results are not necessarily published, but are shared with the members.
Mail had successful interoperability tests. Events under the control of the IMC. A timeframe for the tests were discussed as being in the late third quarter or early fourth quarter of this year.
There are a few levels of what we might do.
a) busy time publication/access
b) iCalendar object publication, like the IETF meeting schedule.
c) iTIP scheduling, the meat of what we want to do
d) vCard/LDAP looking for calendar information
Interoperability test phases were then discussed as having three basic types.
b) Calendar Connect
c) EMA Pavillion
In the email arena, the first doesn't work. The third is a pain. The only one which has any value was the Calendar Connect tests.
With that, the Second meeting was concluded.
go to list