NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 28-Nov-00
Chair(s):
Bob Mahoney <bobmah@mit.edu>
Pat Egen <pregen@egenconsulting.com>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
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:
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) |
RFC2739 |
PS |
Calendar attributes for vCard and LDAP |
Calendaring and Scheduling WG (calsch)
Wednesday, December 13 at 0900-1130
====================================
CHAIR:
Pat Egen <pregen@egenconsulting.com>
Bob Mahoney <bobmah@mit.edu>
Reported by: Walt Houser <houser.walt@forum.va.gov>
AGENDA:
Agenda bashing
1. Guide to Interoperability draft update
- inclusion of Timezone data
- most recent changes
- additional examples added
2. iCalendar updates (and iTIP,iRIP,iMIP if necessary)
- Eric Busboom added as an Editor
- Bruce Kahn added as Method Reviewer
- changes (typos fixed, adjustments, etc)
3. CAP update
- Command table work
- Timezone efforts
4. Plans for Winter CalConnect
__________________________________
1. Agenda bashing - We will add a discussion of the web site, and a talk by Greg FitzPatrick on SkiCal.
2. The name of the Implementor's Guide is being changed to "A Guide to Internet Calendaring", will be resubmitted with that change immediately, and is targeted toward WG last call in the near future.
Implementors' Guide to Internet Calendaring (36388 bytes)
http://ietf.org/internet-drafts/draft-ietf-calsch-imp-guide-02.txt
This version includes Timezone data for which registry has been submitted to IANA. Recent changes include more explanation of the contents of the other WG documents. Additional examples are needed.
3. iCalendar updates (and iTIP,iRIP,iMIP if necessary) Frank Dawson has moved to Nokia, but will continue with iCAL implementation for small devices. We have added Eric Busboom of Software Studios as an Editor and Bruce Kahn Iris/Lotus added as Method Reviewer. We made a number of changes, typos fixed, adjustments, etc.
3.1 Eric found a several recurrence rules issues in RFC 2445. The specification is possible implement but it is remarkably complex. First, there are conflicts between type of frequency and the BY rules. The text says it is not legal to have BYWEEKNO and BYMONTH. Implementors have typically tossed the rule. There is no status code for invalid BYXX. This should be added to the interoperability tests. One attendee suggested putting a table in the text showing the legal and illegal rules. John Stracke observed that it is hard to imagine how a user using a GUI could generate an illegal rule. But the group felt this needed addressing.
The BYSETPOS is potentially quite large number set. Outlook uses BYSETPOS to select the last Thursday of each month. But would interoperability require a large array? Internationalization is an issue that requires clarification. Do some countries use to other numbering schemes?
There was a request for examples of each of these issues.
3.2 Two open source implementations are progressing, and will participate in upcoming interoperability tests. We should start pooling our test data. We need twisted minds to come up with test cases. Eric has the RFC 2445 and 2446 examples available on line. Bob and Pat will make these available online.
3.3 John Stracke noted that the CAP server must advertise for Access Control and query, CRISP change to add capabilities = none. This issue was posted to the mail list.
3.4 Eric listed additional issues for CAP:
- Data integrity
- The trust model - Paul suggested that this be further discussed on the list. Some list participants had concerns that iCAL trusted all the data. Per Paul this is a basic assumption of SASL. There is no way to sign each event with a personal certificate.
- Signature and encryption
- Fanout - turning iTIP and CAP workflow - Define iTIP and CAP workflow
3.5 iTIP and iMIP updates
REQUEST is overloaded. Added to the text the proposal to use CONFIRM
1) reply to REFRESH and 2) changes in ATTENDEE and ORGANIZER. CONFIRM has itself become overload and we propose dropping.
Who sends a COUNTER proposal? When attendees are added or removed, do you send to affected attendees only, or all attendees. We decided to send just to affected attendees and not bump the sequence numbers.
RFC 2447 does not say which MIME encapsulations must be supported. We oppose to add the requirement that conforming iMIP implementations must be able to receive the described encapsulations, although the ability to generate these encapsulations is not required. Generate both a text version and iCALENDAR attachments. Implementations have to support multipart mixed MIME type. Patrik advised to check the MIME standard to be sure of the combination of acceptable.
Garbage in the examples ("Error! Bookmark not defined") have been fixed.
New problem: No way an attendee can say to remove me from the event.
Options:
- Comment to ask to be removed by the organizer. - Reply with ATTREMOVE
- Reply with a COUNTER proposal to delegate and remove oneself. This risks overloading COUNTER.
The document format is back in MS Word. Plan to convert to XML using RFC 2629 which includes the DTD for RFCs. The product "Email Effects" generates ASCII art, and was recommended for our use.
Restriction tables
Updated the examples to reflect
3.6 To do:
3.6.1 End-to-end review. John Stracke and another list member reviewed it but it is a hard read. More review needed.
3.6.2 Asynchronous error reporting. Background job to propagate iMIP. No way to handle error replies.
3.6.3 Review schema definition. Doug Royer did it in an SQL-like fashion, and it needs to be updated.
Many examples are needed. The current ones were done to flesh out the protocol and are not always reasonable. When an organizer creates an event it will appear in his calendar as created. The attendees are invited in a conceptual queue using the REQUEST method. Is this one or two CAP actions? What is the minimum event? What is returned when I ask for all properties of this minimal event? What if I have permission to write events but not permission to write particular properties? Backing out written events is hard across multiple stores. Is the command set enough to support synchronization? Who are synch vendors or experts that can review the commands? We plan to get this done by January 22. We will try to get it ready for the next IETF meeting.
3.7 CAP update is resubmitted as version 3. The WG charter was resubmitted.
CAP Requirements (53021 bytes)
http://ietf.org/internet-drafts/draft-ietf-calsch-capreq-04.txt
Calendar Access Protocol (CAP) (217860 bytes)
http://ietf.org/internet-drafts/draft-ietf-calsch-cap-03.txt
4. The Winter CalConnect is planned for the third week in Feb 2001 in San Jose area. Interoperability testing will address scheduling and mime multipart. We need to go through the examples and recurrence rules for testing. (Do we need external access to the Internet?) We are discussing details with a large university in the area.
5. A general website for calendaring issues to be created. Plan is for www.calsch.org to be active in about three weeks. MIT will provide a home for this.
6. Greg FitzPatrick spoke about SkiCal, an extension of iCal.
This effort adds properties extending rfc2445. Example:
Required: shoes.
RECOMMENDED: warm clothes
PROHIBITED: suits and ties
Recommended lists of terms to permit discovery and interoperability in language. A draft will appear after the IETF reopens the drafts queue. Note: There are a number of implementations currently using the existing draft.
7. General Discussion
7.1 XML interpretation of iCAP. Microsoft is doing iCAP in XML. SkiCal is doing an XML schema; and they found 63 syntax errors when validating the current schema. There is no nesting, so the mapping is one-to-one. Lisa Lippert has left Microsoft (where she was the champion of iCAL) Chairs will be speaking with Microsoft about a new contact. SkiCal will prepare DTD and compare the schemas.
7.2 Question: How should we handle iCAL events when the recipient server wants an XML version?
7.3 Bruce raised the issue that the delegation model does not specify the delegation and retraction of delegation. What happens to the status of the redelegation? Let the organizer decide? The organizer needs to decide to uninvited? Or is every redelegation in the chain dropped? Double delegations? What if one is a delegatee from two or more bosses?
7.4 Walt Houser mentioned the Contextualization of Resolution BOF (c15n), which seeks to address how to incorporate elements of contextual control information in determining the "appropriate copy" of a resource. This is generally applicable to all URI resolution, but it is more specific than "web caching". Software systems being built to solve this are using specialized, non-interoperable, non-scalable approaches. The individual's context could be implemented in the client using vCard. At present there is no working group addressing this.
Minutes respectfully submitted by Patricia Egen and Bob Mahoney
None received.