HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 01:23:22 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 14 Aug 1998 13:07:00 GMT ETag: "2e9efe-3678-35d43674" Accept-Ranges: bytes Content-Length: 13944 Connection: close Content-Type: text/plain Network Working Group Andre Courtemanche, CS&T Internet Draft - CAP Requirements Tony Small, Lisa Lippert, Microsoft Frank Dawson, Lotus Steve Mansour, Netscape Pete O'Leary, Amplitude Expires 6 months after: August 6, 1998 CAP Requirements Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Abstract The Calendar Access Protocol (CAP) protocol defines calendar administration and calendar component management on calendar stores by owners, designates, and others. The purpose of this document is to set forth a list requirements that CAP must address in order to address the needs of the calendaring and scheduling community. Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 1 Internet Draft CAP Requirements August 6, 1998 1. Introduction 1.1 Assumptions 1. The data elements of CAP are based on [ICAL]. 2. The CAP protocol is intended to support both connected and synchronization operation. 1.2 Definitions The terms Calendar User (CU), Calendar User Agent (CUA), Calendar Store, and Calendar Service (CS) are defined in [ICMS]. 2. Scenarios These are the usage scenarios used to drive the requirements list. Understanding these scenarios and how they are useful to clients and administrators will help with understanding why these requirements were chosen. However, these scenarios are not an exhaustive list. 2.1 Access Control A user MUST be able to: * Create an event, to-do, or journal entry such that only the creator can see all properties and others can see only the start and end times. * Create an event or to-do such that only the attendees can see all properties and others can see only the start and end times. * Create an event, to-do, or journal entry such that all properties can be seen by anyone. * Define who can add items to their calendar store. * Enable another person to act on behalf of the user. * Fetch components from another user's calendar, subject to access control * Put requests for user A on user A's calendar, subject to access control * "Direct book" an event or to-do on user A's calendar, subject to access control * Fetch user A's busy time, subject to access control * Perform any calendar operation on behalf of user A, subject to access control. 2.2 Implementation Options A server vendor may decide to only support VEVENT components and not support VTODO and VJOURNAL components. The client needs to query the server to see which components are supported. Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 2 Internet Draft CAP Requirements August 6, 1998 2.3 Notification Server implementations may wish to allow clients to register for events. When the event occurs, the server can notify the client. The following notification scenarios MUST be supported by the protocol design: * A client wants to be notified by the server whenever any change is made to a particular calendar store. * An alarm for a VEVENT or VTODO has gone off for a particular calendar store. 2.4 Search Scenarios The following searches MUST be supported in some manner. * Search for all items of a certain type (e.g. VEVENT) * Search for all items with a start time greater than x OR an end time less than y. * Search for all items of type VEVENT, with start and end types such that the event overlaps a certain period (i.e. 24 hours of one day) * Search for all items with a display name containing a string S * Search for all items with an attendee list that contains the user S 3. Requirements The requirements are broken into the following categories: * Basic * Administration * Component Management There is some overlap between the categories. All requirements in this section are MUST HAVE features for the protocol draft to address. 3.1 Basic requirements The CAP protocol design must: 1. Support the model of storing calendar data only on the server. 2. Support the model of storing calendar data on both the client and the server, with some kind of synchronization. 3. Support a framework for authentication of a calendar user 4. Allow one calendar user to act as a designate or proxy for another user. 5. Support the transport of encrypted data between the CUA and the CS. Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 3 Internet Draft CAP Requirements August 6, 1998 6. Define calendar addresses that support hierarchical names. 7. Specify the granularity of access control on calendars. See the access control scenarios above. 8. Allow clients to determine what data components (i.e. VEVENT, VTODO) a CAP server supports. 9. Define error codes to be returned for improper commands, unsupported commands, and command failures. 10. Allow users to search for calendar stores. 11. Allow calendar users to control the access that others have to their calendar. See access control scenarios above. 12. Allow a number of simple operations on calendar stores to be grouped such that if any operation cannot be completed on all calendar stores, then no change is made to any calendar store. 13. Support server-to-client notification. See notification scenarios above. 14. Allow the server implementation to return a referral when a request was made for a calendar or CU located elsewhere. Servers must not be required to make referrals. 15. Support functionality such that the client is not forced to remain connected and waiting while a command is in progress. One possible way for the protocol to meet this requirement would be to allow the CU to abort a command that is taking too long. 16. Support properties on calendar stores, including a standard property for a human-readable name. 3.2 Administration Requirements In order to provide some interoperability of administration functions on calendars, the CAP protocol design must: 1. Allow a CUA to connect to the CAP server and authenticate the CU. 2. Allow creation and deletion of calendar stores. 3. Provide a way to set and change ownership of a calendar. 4. Support setting access control lists on a calendar. 5. Support retrieving access control lists from a calendar. 6. Enumerate the access levels that are possible on a calendar. 7. Support functions to add, modify, and delete calendar properties. 8. Allow users to list calendar stores (subject to access control). 3.3 Component Management Requirements Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 4 Internet Draft CAP Requirements August 6, 1998 In order to provide interoperability of component management on calendars, the CAP protocol design must: 1. Allow users to create, modify, and delete components in a calendar store. 2. Allow users to create an invitation to an event or to-do in someone else's calendar store (subject to access control). 3. Allow users to retrieve the busy time on a calendar store. 4. Allow the CUA to fetch a list of components based on a query. The query language must support the scenarios outlined above. 5. Allow a CUA to specify which properties will be returned in the results of a fetch operation. The CUA should also be able to get the entire component (all properties). 6. Allow CUA to fetch a set of alarms/reminders that are set to go off within a range of time. 7. Allow the CUA to register for and receive notifications from more than one calendar and from more than one calendar server. 8. Allow the CUA to use the result of a query to perform modify, delete, and other operations. Also, 9. The protocol will be designed such that a subset of component properties can be updated without having to specify all existing component properties. 10. The protocol draft must specify how and where (or how to tell where) expansion of recurring events will occur. 3.4 Open Issues 1. Given that access control to calendar stores must be addressed, is there a need to standardize the way Calendar Users are identified? 4. Future Work These are desirable areas for future work on calendaring access. In order to standardize the basic functionality for a calendaring access protocol in a timely manner, these features will not be in the initial CAP protocol. 1. Server fan-out. The fan-out capability can be turned on or off. Server fan-out is the ability for the server to automatically send meeting requests using [IRIP] or [IMIP] to those recipients in a meeting request. With this functionality, the client creates the meeting request on its calendar and the server takes care of the rest. 2. User-defined rules. 3. Archiving (import and export) of calendar stores. Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 5 Internet Draft CAP Requirements August 6, 1998 4. Group names can be used to invite a list of attendees to an event or to-do. Group names can be used in setting access to events and to-dos. Servers could explode a group name into a list of individuals. 5. Support more complex types of transactions if a request cannot be completed successfully on all calendar stores involved. For example, do not do the transaction at all or complete the operation on as many calendar stores as possible. In either case, any failures must be reported to the client. 6. Support the addition of functionality extensions. Commands on the wire should be able invoke the extended functionality. (This is something akin to server plug-ins.) 7. Allow for Draft storage of components 8. Add, modify, or delete components based on a query of calendar stores. 9. Get components from multiple stores in a single command. 10. The capability to list calendar stores based on properties. 11. The capability to perform an operation on a number of calendar stores. 5. Acknowledgments The following have provided input in the drafting of this memo: Mike Weston 6. Bibliography [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt. [ICAL] "Internet Calendaring and Scheduling Core Object Specification - iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-02.txt. [ITIP] "iCalendar Transport-Independent Interoperability Protocol (ITIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch-itip-01.txt. [IMIP] "iCalendar Message-based Interoperability Protocol (IMIP), Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch-imip. [IRIP] "iCalendar Message-based Interoperability Protocol (IRIP), Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch-irip. 7. Authors' Address The following address information is provided in a vCard v2.1, Electronic Business Card, format. Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 6 Internet Draft CAP Requirements August 6, 1998 BEGIN:VCARD FN:Andre Courtemanche ORG:CS&T ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 3L5;Canada TEL;WORK;MSG:+1-514-733-8500 TEL;WORK;FAX:+1-514-733-8788 EMAIL;INTERNET:andre@cst.ca END:VCARD BEGIN:VCARD FN:Frank Dawson ORG:Lotus Development Corporation ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-3502;USA TEL;WORK;MSG:+1-919-676-9515 TEL;WORK;FAX:+1-919-676-9564 EMAIL;INTERNET:Frank_Dawson@Lotus.com URL:http://home.earthlink.net/~fdawson END:VCARD BEGIN:VCARD FN:Tony Small ORG:Microsoft Corporation ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA; 98052-6399;USA TEL;WORK;MSG:+1-206-703-2190 TEL;WORK;FAX:+1-206-936-7329 EMAIL;INTERNET:tonysm@Microsoft.com END:VCARD BEGIN:VCARD FN:Steve Mansour ORG:Netscape Communications Corporation ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain View;CA;94043;USA TEL;WORK;MSG:+1-650-937-2378 TEL;WORK;FAX:+1-650-937-2103 EMAIL;INTERNET:sman@netscape.com END:VCARD BEGIN:VCARD FN:Peter O'Leary ORG:Amplitude Software Corp. ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA; 94107;USA TEL;WORK;MSG:+1-415-659-3511 TEL;WORK;FAX:+1-415-659-0006 EMAIL;INTERNET:poleary@amplitude.com END:VCARD This work is part of the Internet Engineering Task Force Calendaring and scheduling Working Group. The chairman of that working group is: BEGIN:VCARD FN:Anik Ganguly ORG:Open Text, Inc. ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road Suite 101; Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 7 Internet Draft CAP Requirements August 6, 1998 Livonia;MI;48152;USA TEL;WORK;MSG:+1-734-542-5955 EMAIL;INTERNET:ganguly@acm.org END:VCARD