NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99
Chair(s):
Robert Moskowitz <rgm@icsa.net>
Pat Egen <pregen@egenconsulting.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
General Discussion:ietf-calendar@imc.org
To Subscribe: ietf-calendar-request@imc.org
In Body: SUBSCRIBE/UNSUBSCRIBE
Archive: http://www.imc.org/ietf-calendar/mail-archive/
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 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.
Goals and Milestones:
Done |
|
Submit core object specification as Internet-Draft. |
Done |
|
Submit second draft of core object specification as Internet-Draft. |
Done |
|
Submit first Internet-Draft of Calendar Interoperability Protocol. |
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. |
Nov 99 |
|
Submit Internet-Draft (informational) on Guide to Implementors using Calendaring Protocols |
Feb 00 |
|
Submit Internet-Draft on Calendar Access Protocol to IESG for consideration as a Proposed Standard. |
Feb 00 |
|
Submit proposed changes to all drafts affected by Calendar Access Protocol submission |
Internet-Drafts:
· Calendar attributes for vCard and LDAP
· ICalendar Real-time Interoperability Protocol (IRIP)
· iCalendar v2.0 Formal Public Identifier
· Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Request For Comments:
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) |
CAP Meeting Minutes, reported by Pat Egen.
WE announced that an upcoming interop test was in the works. It was noted that it will be scheduled for sometime in February (before the March meeting).
The chair introduced Bob Mahoney from MIT as the new Co-Chair.
There was next a discussion on the Guide to Implementors.
Bob asked if anyone read the doc and a few people noted they had done so. He went over the purpose of the document and asked for more feedback, especially from developers. What is missing. This document is in the early versions. Do we need to make a case for the Shoulds. He stated the next steps are to add more feedback. A suggestion was that we really talk about "shoulds".
Next we did a CAP draft update.
The draft has grammatical errors that we will fix in 3 weeks. There was a discussion about substantial updates.
The State diagram has been updated. Added were two commands. Another major addition was SLP - service level protocol. It's not done but major progress has been made. Capability has gone back to the way it was in the original draft. It's a separate command. The copy and paste is incorrect. Other minor changes were made.
Schedulable hours may be an issue we need to drop out. Text needs to be worked out.
Examples are inconsistent - we need to clean them up and make them consistent and we need better details.
What's left.
Some schema work needs to be completed and we need to nail vcommand and vcar. We got several comments on calendar wrappers. Someone (?) will send big example to the list.
The query subset needs more work. It's modeled after SQL. Queries are non-trivial so we chose sql-like, rather than force implementors to force SQL implementation. We came up with a subset. Need to guarantee that queries look a certain way. Need to put together a small set of queries.
It was suggested that if someone has an SQL engine could they use it. Syntax is ical - structure is SQL. There was a broad discussion about putting SQL in place.
There still needs to be more work on the definition of Users - there are some definitions that need to be changed/added. Add some examples and have done by 3 weeks.
Issues found (Chris Newman):
Idle timeout in protocol. Need to add no-op command. Forcing connection to remain open. If you are running under tls connection may be expensive.
Authenticate command - need to be able to return data when you have success. Digest command. Need to put it in.
DES Level 7.1.3 security. Are we requiring. Need to look at this item. Either have no security or require Triple DES.
Error codes from Authenticate that may be useful - he will provide them (he = ??)
Error text should be on all the examples - use short numonic. Text will be optional.. As long as it is UTF8, it will be the local of the server. May need to state what the default language is on the server. Command = sys text (make it logout or similar to other protocols).
Some commands have a terminating "." - need to find something that the parser to handle it. We were always going to terminate everything with a dot. An acceptable thing would be you have a terminating DOT. CRLF..
The create method may have a layoring violation. You use senddata to do a create. Multiple respond codes for different errors. This is a layoring violation. Have something on the senddata state how many of error responses.
Other issues:
Pipelineing - we started out tagging commands and then we talked about pipe-lining commands. It may be going away. Command ID is a remmnant of this. Do we still need this or is everyone happy with no pipeline. The IMAP has pipeline from the beginning. All the servers will run multiple scans simultaneously. So Chris says that is not useful. The ability for the server to return data unrelated to the command in process is helpful. It's not like "unsolicited". We deferred notification. IMAP is not notification - it's polling. Look at IMPP issues to see what not to do.
Unbounded recurrent sets - what should the options be for returning recurrent sets. What should be returned? One case - a server will expand to a bounded set and if you ask for vevent it is to get back every instance. Another one would be to get back the original using rrule and leave it up to the client. Or use the specific recurrence id. Any thoughts? A general discussion about recurrence. One way is give me the rule and the other is give me the instances. Smaller clients is an example of not needing the rules.
A comment from the audience says it must be possible for the client to get it both ways. Microsoft's implementation experience is to do the expansion by default.
Lisa asked for any implementation experience with CAP. Doug says yes. Three separate implementations.
Bob talked about extensions - for example, SKI. It should be in a separate group as an extension iCalendar. Events are their focus. I will resend it to the list.
The meeting was adjorned.
After the meeting was over, I and one of the editors approached the AD to ask for permission to hold one more interim meeting to finalize the remaining items for the draft. Most of the work will be done prior to the meeting and we will use the meeting to complete the text and grammatical edits. Permission was granted and I will post this to the list and to the Announce list.
Minutes taken and submitted by Pat Egen.
None received.