Last Modified: 2003-01-21
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 vent-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.
| Done | Submit core object specification as Internet-Draft. | |
| Done | Submit first Internet-Draft of Calendar Interoperability Protocol. | |
| Done | Submit second draft of core object specification as Internet-Draft. | |
| Done | Submit revised Internet-Draft of Calendar Interoperability Protocol. | |
| Done | Submit core object specification to IESG for consideration as a Proposed Standard. | |
| Done | Submit Calendar Interoperability Protocol to IESG for consideration as a Proposed Draft. | |
| Done | Submit Internet-Draft (informational) on Guide to Implementors using Calendaring Protocols | |
| FEB 01 | Hold second CalConnect Interoperability Testing on iCalendar, iMIP and iTIP | |
| MAR 01 | Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard. | |
| JUL 01 | Request last call on Guide to Internet Calendaring | |
| JUL 01 | Submit Internet-Draft on Guide to Internet Calendaring for consideration as a Proposed Standard | |
| JUL 01 | Submit revisions for Internet-Draft for iCalendar, iMIP and iTIP | |
| JUL 01 | Submit revisions for Internet-Draft for Calendar Access Protocol | |
| JAN 02 | Evaluate readiness for interoperability testing of Calendar Access Protocol |
| RFC | Status | Title |
|---|---|---|
| RFC2445 | PS | Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| RFC2446 | PS | iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries |
| RFC2447 | PS | iCalendar Message-based Interoperability Protocol (iMIP) |
| RFC2739 | PS | Calendar attributes for vCard and LDAP |
| RFC3283 | I | Guide to Internet Calendaring |
Calendar & Scheduling Working Group minutes, Mar 19 The minutes were taken by Larry Greenfield <leg+@andrew.cmu.edu> - (thanks Larry for volunteering). Pat Egan is chairing. Slide - Chair, introduction & agenda bashing . Pekka from Nokia asks about iSIP and whether it will become a working group item. General thoughts are that it could become one after a charter revision but only after CAP is done. Nothing to interfere with CAP. iSIP is iTIP transported via SIP. Slide - Chair, Interop testing. There's been a successful virtual interop that will help when we attempt to move iCalendar to draft. There's a hope to do a face-to-face interop sometime around June/July. It would be wonderful if there were proto-CAP implementations then. CAP discussion: Chair & Doug Royer . BEEP profile Discussion whether there should be one iCalendar object per BEEP blob or more than one. Consensus that since BEEP allows intra-channel pipelining one iCalendar object per BEEP blob is fine. There might be an issue with multiple targets in a single iCalendar object; list will discuss. . Response codes No discussion on response code changes. . Stored queries Should we allow stored VQUERY objects? If there are predefined queries than a lightweight client could do less work. Larry Greenfield thinks that stored VQUERY objects without standardized pre-defined queries could cause interoperability problems. Room consensus that stored VQUERYs should be moved out of the draft and reintroduced as an extension. . Grammar and typos No discussion on changes except that better English is gooder. . CHARSET Lively debate on a hypothetical charset property. Martin Duerst is interested in this and possible solutions and hopefully a solution will be presented on the list. . Resolved Issues GET-CAPABILITY will be required. . Removing LATENCY from some commands Chris Newman suggests removing latency entirely. 4 people in the room don't see any need; consensus in the room is to make it an extension. . Removing CS CS "calendar store" acronym is confusing in the draft. The editors will try to clarify. . Other stuff xCAL (XML version of iCalendar data) is very hot. People are very interested in it, and the WG might take it on or provide review after CAP is done. There's an effort to create an RDF schema. . IDENTIFY in CAP Chris Newman is unhappy with the IDENTIFY command because switching authenticated identities can be hard in some environment. Others don't think it is so hard, but no one in the room are impassioned about keeping it, so it might just become an extension. The issue of closing the Working Group was discussed with the Area Director. If we are going to be submitting a new iCalendar draft with changes found during interop testing, that will happen within the next 6 months. Rather than restart the WG, it may be better to stay up until that is complete. Pat will submit a new charter update. Respectfully submitted by Pat Egen SLIDE TEXT - following is text of slide presented during meeting. Notes above reflect discussion during showing of slides. Agenda -- Agenda Bashing -- Interop testing status -- CAP Interop Testing -- Currently working on next Virtual Interop -- Need to do a face-to-face interop around July timeframe Beep Profile -- Should each begin and end vCalendar be in one Beep Blob? -- In other words, should it be one BEEP blob of reply or multiple BEEP blobs of reply. -- The application should be able to reconstruct multiple BEEP blobs into the original. -- It is probably best to lean towards multiple BEEP blobs simply so that small memory devices do not have to handle large BEEP blobs all at once. -- What does everyone think of this idea? We feel we need a BEEP expert to help us make a determination. We can compile and we can use it -- but what is a BEEP Profile? Request-Status codes -- We are finishing the REQUEST-STATUS codes -- Everyone agrees on text -- we just need to change numbering Stored Queries -- vQuery -- Some people feel that a stored vQuery is harder to store than a stored VCAR, VEVENT, VTODO -- It may be easier than it appears -- just store it as a blob and send it to the query engine that will have to be able to process that blob if sent from a CUA anyway. -- If you do not want to save a VQUERY then say NO when the CUA attempts. -- For example, if an implementation does not support VJOURNAL, you say NO when a CUA attempts to use vJournal. -- We still are not sure if this feature is really required? Thoughts? Grammar and typo's -- We are continuing to fix any typos found by readers of the draft -- There are quite a few comments regarding double negatives in the wording that make the draft confusing -- If anyone sees instances of this, please post the item, with suggested changes to the text, to the list CHARSET -- There has been a lively debate on CHARSET -- The question on the list is CHARSET is not specified in 2445 inside the object and this "breaks" transporting the objects outside of MIME -- This is really an issue about transporting iCalendar objects without MIME headers -- We have a possible solution, based on discussions here this week -- Look to the list for suggestions and solutions Resolved Issues (maybe) -- GET-CAPABILITY required -- Based on the list consensus -- Resolution: it is mandatory. -- Ordering of commands -- Based on list consensus -- Resolution: they can come back in any order. -- During hallway BOF's this week, we heard about lessons learned from IMAP -- implementers discovered it is better that the commands come back in the same order -- Therefore, we may need to review this decision Removing LATENCY from some commands -- LATENCY is already optional and the GET-CAPABILIITY command CAN be sent after IDENTIFY, so it may need LATENCY -- As that point has not been refuted, we suspect that that the consensus is to not change that feature -- Is this a correct assumption on our part? Removing CS -- There are thoughts to removing CS when it could mean 'any endpoint' to a future draft -- Several places we say CS when it also applies to CUA, for example capability -- In some cases we say "CUA or CS" when we mean either end of the connection, whatever that might be -- The comments have settled down so we suspect that the consensus is to make it generic (remove 'CS' in those instances). CAP -- in Summary -- For the most part the last few months have been about bugs and not feature changes. -- A last call has been "suggested to the list" -- Another final Last Call will go out after this meeting -- There will be a 2 week deadline on that last call Identify Command -- Should it be an extension and removed from draft? -- Use SASL authentication? -- Should it be optional? |