Network Working Group Andre Courtemanche, CS&T Internet Draft - CAP Requirements Alec Dun, Microsoft Frank Dawson, Lotus Steve Mansour, Netscape Pete O'Leary, Amplitude Expires 6 months after: November 21, 1997 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 ds.internic.net (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 administrative, calendar management, 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. 1. Introduction The requirements are broken into the following categories: . Model . Administration . Component Management Each of these is further broken down into requirements that a CAP implementation MUST support, and MAY support. In some cases, functionality which is specifically excluded from CAP is listed in a Courtemanche/Dun/Dawson/Mansour/O'Leary 1 Expires May 1998 Internet Draft CAP Requirements November 21, 1997 DOES NOT section. Those items where further input from the working group is needed are listed in a NEEDS DISCUSSION section. 1.1 Assumptions 1. The data elements of CAP are based on iCalendar. 2. Model MUST 1. Support two connection models: (a) no data is stored on the client and (b) data is stored on both the client and the server and is synchronized periodically. 2. Support a framework for authentication of a calendar user and for one calendar user to act as a designate or proxy for another user. 3. Support a framework for the secure transport of data between the CUA and the CS. 4. Define a calendar address. 5. Specify the granularity of access control on calendar components. 6. Enforce access control to calendar components 7. Support capabilities negotiation to enable clients to determine the capabilities of a CAP server. Specify how a CUA queries a Calendar Store to determine its attributes. The client must be able to determine which Components are supported by a given Calendar Store. 8. Return error codes for valid commands that are not supported by the server. 9. Provide the capability to search, select, and operate on calendar stores based on their properties. For example, a property of the store might be its owner. MAY 1. Allow Calendar Users to control the access that others have to their calendar. Setting access that a group has to a calendar may be supported. 2. Supports two types of transactions. Type 1: if the request cannot be successfully completed on all calendar stores involved, don't do the operation at all. Type 2: complete the operation on as many calendar stores as possible. In either case, any failures must be reported to the client. Courtemanche/Dun/Dawson/Mansour/O'Leary 2 Expires May 1998 Internet Draft CAP Requirements November 21, 1997 3. Support server-to-client notification. If the server supports this capability, it must notify a client when a CAP event occurs in which the client has registered interest. 4. Supports server fan-out. The fan-out capability can be turned on or off. 5. Provide for user-defined rules. Servers are not required to implement this functionality. 6. Provide for the archiving (import and export) of calendar stores. Servers are not required to implement archiving. 7. Provides for making referrals. That is, supply the new address for a user that is not on this calendar system. Servers are not required to make referrals. 8. Support hierarchical calendar stores. 9. 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 todos. Servers are not required to explode a group name into a list of individuals. 10. Provide support for interrupting a command in progress. 11. Provide a mechanism to bound the latency of a response. 12. 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.) DOES NOT 1. Support for fetching components from multiple Calendar Stores simultaneously. (deferred) NEEDS DISCUSSION: 1. Should a CAP server provide any directory services or shall directory services be supplied by an external capability. Given that access control to calendar stores must be addressed, is there a need to standardize the way Calendar Users are identified? 3. Administration MUST 1. Support connect and authenticate the CU. Courtemanche/Dun/Dawson/Mansour/O'Leary 3 Expires May 1998 Internet Draft CAP Requirements November 21, 1997 2. Create and delete calendar stores. 3. Set and change ownership of a calendar store. 4. Support setting and retrieving access control lists on calendars. Determine the access levels. 5. Support functions to add, modify, and delete calendar properties. 6. Return a handle to a calendar store based on a supplied calendar address and subject to access control. MAY 1. List calendar stores subject to access control. DOES NOT 1. Provide for server-to-server replication of calendar data. 4. Component Management MUST 1. Create, modify, and delete components in a calendar store. 2. Create or modify a set of component attributes. 3. Search for busy time on a calendar store. 4. Allow for Draft storage of components 5. Fetch components based on a query. The query language must support (a) component property value comparisons and (b) component property parameter value comparisons. The query language must support queries consisting of multiple comparisons joined by boolean operators. 6. Return the results of a Get filtered by a supplied list of attributes. 7. Read a set of alarms/reminders in a calendar that are set to go off within a range of time. MAY 1. Support the expansion of a recurring event or to-do. If recurring expansion is supported, an error must be returned for any problems that occur in the expansion. 2. Notifications on multiple stores. 3. Modify, delete, and other? operations based on a query. Courtemanche/Dun/Dawson/Mansour/O'Leary 4 Expires May 1998 Internet Draft CAP Requirements November 21, 1997 4. Add, modify, or delete components based on a query of calendar stores. NEEDS DISCUSSION 1. Get components from multiple stores in a single command. 5. Acknowledgments The following have provided input in the drafting of this memo: Mike Weston 6. Bibliography 7. Author's Address The following address information is provided in a vCard v2.1, Electronic Business Card, format. 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:fdawson@earthlink.net URL:http://home.earthlink.net/~fdawson END:VCARD BEGIN:VCARD FN:Alec Dun ORG:Microsoft Corporation ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA; 98052-6399;USA TEL;WORK;MSG:+1-206-936-4544 TEL;WORK;FAX:+1-206-936-7329 EMAIL;INTERNET:alecdu@Microsoft.com END:VCARD BEGIN:VCARD FN:Steve Mansour Courtemanche/Dun/Dawson/Mansour/O'Leary 5 Expires May 1998 Internet Draft CAP Requirements November 21, 1997 ORG:Netscape Communications Corporation ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain View;CA;94043;USA TEL;WORK;MSG:+1-415-937-2378 TEL;WORK;FAX:+1-415-428-4059 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 Courtemanche/Dun/Dawson/Mansour/O'Leary 6 Expires May 1998