idnits 2.17.1 draft-ietf-calsch-capreq-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 464 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 63: '...A user MUST be able to:...' RFC 2119 keyword, line 105: '...cation scenarios MUST be supported by ...' RFC 2119 keyword, line 116: '...llowing searches MUST be supported in ...' RFC 2119 keyword, line 141: '...section are MUST HAVE features for the...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 6, 1998) is 9395 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ICAL' on line 317 looks like a reference -- Missing reference section? 'ICMS' on line 314 looks like a reference -- Missing reference section? 'IRIP' on line 330 looks like a reference -- Missing reference section? 'IMIP' on line 326 looks like a reference -- Missing reference section? 'ITIP' on line 321 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Andre Courtemanche, CS&T 3 Internet Draft - CAP Requirements Tony Small, Lisa Lippert, Microsoft 4 Frank Dawson, Lotus 5 Steve Mansour, Netscape 6 Pete O'Leary, Amplitude 7 Expires 6 months after: August 6, 1998 9 CAP Requirements 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months. 19 Internet-Drafts may be updated, replaced, or made obsolete by other 20 documents at any time. It is not appropriate to use Internet-Drafts as 21 reference material or to cite them other than as a "working draft" or 22 "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 27 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 Distribution of this document is unlimited. 31 Abstract 33 The Calendar Access Protocol (CAP) protocol defines calendar 34 administration and calendar component management on calendar stores by 35 owners, designates, and others. The purpose of this document is to set 36 forth a list requirements that CAP must address in order to address the 37 needs of the calendaring and scheduling community. 39 Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 1 40 1. Introduction 42 1.1 Assumptions 44 1. The data elements of CAP are based on [ICAL]. 46 2. The CAP protocol is intended to support both connected and 47 synchronization operation. 49 1.2 Definitions 51 The terms Calendar User (CU), Calendar User Agent (CUA), Calendar 52 Store, and Calendar Service (CS) are defined in [ICMS]. 54 2. Scenarios 56 These are the usage scenarios used to drive the requirements list. 57 Understanding these scenarios and how they are useful to clients and 58 administrators will help with understanding why these requirements were 59 chosen. However, these scenarios are not an exhaustive list. 61 2.1 Access Control 63 A user MUST be able to: 65 * Create an event, to-do, or journal entry such that only the creator 66 can see all properties and others can see only the start and end 67 times. 69 * Create an event or to-do such that only the attendees can see all 70 properties and others can see only the start and end times. 72 * Create an event, to-do, or journal entry such that all properties can 73 be seen by anyone. 75 * Define who can add items to their calendar store. 77 * Enable another person to act on behalf of the user. 79 * Fetch components from another user's calendar, subject to access 80 control 82 * Put requests for user A on user A's calendar, subject to access 83 control 85 * "Direct book" an event or to-do on user A's calendar, subject to 86 access control 88 * Fetch user A's busy time, subject to access control 90 * Perform any calendar operation on behalf of user A, subject to access 91 control. 93 2.2 Implementation Options 95 A server vendor may decide to only support VEVENT components and not 96 support VTODO and VJOURNAL components. The client needs to query the 97 server to see which components are supported. 99 Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 2 100 2.3 Notification 102 Server implementations may wish to allow clients to register for 103 events. When the event occurs, the server can notify the client. 105 The following notification scenarios MUST be supported by the protocol 106 design: 108 * A client wants to be notified by the server whenever any change is 109 made to a particular calendar store. 111 * An alarm for a VEVENT or VTODO has gone off for a particular calendar 112 store. 114 2.4 Search Scenarios 116 The following searches MUST be supported in some manner. 118 * Search for all items of a certain type (e.g. VEVENT) 120 * Search for all items with a start time greater than x OR an end time 121 less than y. 123 * Search for all items of type VEVENT, with start and end types such 124 that the event overlaps a certain period (i.e. 24 hours of one day) 126 * Search for all items with a display name containing a string S 128 * Search for all items with an attendee list that contains the user S 130 3. Requirements 132 The requirements are broken into the following categories: 134 * Basic 136 * Administration 138 * Component Management 140 There is some overlap between the categories. All requirements in this 141 section are MUST HAVE features for the protocol draft to address. 143 3.1 Basic requirements 145 The CAP protocol design must: 147 1. Support the model of storing calendar data only on the server. 149 2. Support the model of storing calendar data on both the client and 150 the server, with some kind of synchronization. 152 3. Support a framework for authentication of a calendar user 154 4. Allow one calendar user to act as a designate or proxy for another 155 user. 157 5. Support the transport of encrypted data between the CUA and the CS. 159 Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 3 160 6. Define calendar addresses that support hierarchical names. 162 7. Specify the granularity of access control on calendars. See the 163 access control scenarios above. 165 8. Allow clients to determine what data components (i.e. VEVENT, VTODO) 166 a CAP server supports. 168 9. Define error codes to be returned for improper commands, unsupported 169 commands, and command failures. 171 10. Allow users to search for calendar stores. 173 11. Allow calendar users to control the access that others have to 174 their calendar. See access control scenarios above. 176 12. Allow a number of simple operations on calendar stores to be 177 grouped such that if any operation cannot be completed on all 178 calendar stores, then no change is made to any calendar store. 180 13. Support server-to-client notification. See notification scenarios 181 above. 183 14. Allow the server implementation to return a referral when a request 184 was made for a calendar or CU located elsewhere. Servers must not be 185 required to make referrals. 187 15. Support functionality such that the client is not forced to remain 188 connected and waiting while a command is in progress. One possible way 189 for the protocol to meet this requirement would be to allow the CU to 190 abort a command that is taking too long. 192 16. Support properties on calendar stores, including a standard 193 property for a human-readable name. 195 3.2 Administration Requirements 197 In order to provide some interoperability of administration functions 198 on calendars, the CAP protocol design must: 200 1. Allow a CUA to connect to the CAP server and authenticate the CU. 202 2. Allow creation and deletion of calendar stores. 204 3. Provide a way to set and change ownership of a calendar. 206 4. Support setting access control lists on a calendar. 208 5. Support retrieving access control lists from a calendar. 210 6. Enumerate the access levels that are possible on a calendar. 212 7. Support functions to add, modify, and delete calendar properties. 214 8. Allow users to list calendar stores (subject to access control). 216 3.3 Component Management Requirements 218 Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 4 219 In order to provide interoperability of component management on 220 calendars, the CAP protocol design must: 222 1. Allow users to create, modify, and delete components in a calendar 223 store. 225 2. Allow users to create an invitation to an event or to-do in someone 226 else's calendar store (subject to access control). 228 3. Allow users to retrieve the busy time on a calendar store. 230 4. Allow the CUA to fetch a list of components based on a query. The 231 query language must support the scenarios outlined above. 233 5. Allow a CUA to specify which properties will be returned in the 234 results of a fetch operation. The CUA should also be able to get the 235 entire component (all properties). 237 6. Allow CUA to fetch a set of alarms/reminders that are set to go off 238 within a range of time. 240 7. Allow the CUA to register for and receive notifications from more 241 than one calendar and from more than one calendar server. 243 8. Allow the CUA to use the result of a query to perform modify, 244 delete, and other operations. 246 Also, 248 9. The protocol will be designed such that a subset of component 249 properties can be updated without having to specify all existing 250 component properties. 252 10. The protocol draft must specify how and where (or how to tell 253 where) expansion of recurring events will occur. 255 3.4 Open Issues 257 1. Given that access control to calendar stores must be addressed, is 258 there a need to standardize the way Calendar Users are identified? 260 4. Future Work 262 These are desirable areas for future work on calendaring access. In 263 order to standardize the basic functionality for a calendaring access 264 protocol in a timely manner, these features will not be in the initial 265 CAP protocol. 267 1. Server fan-out. The fan-out capability can be turned on or off. 268 Server fan-out is the ability for the server to automatically send 269 meeting requests using [IRIP] or [IMIP] to those recipients in a 270 meeting request. With this functionality, the client creates the 271 meeting request on its calendar and the server takes care of the 272 rest. 274 2. User-defined rules. 276 3. Archiving (import and export) of calendar stores. 278 Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 5 279 4. Group names can be used to invite a list of attendees to an event or 280 to-do. Group names can be used in setting access to events and 281 to-dos. Servers could explode a group name into a list of 282 individuals. 284 5. Support more complex types of transactions if a request cannot be 285 completed successfully on all calendar stores involved. For example, 286 do not do the transaction at all or complete the operation on as many 287 calendar stores as possible. In either case, any failures must be 288 reported to the client. 290 6. Support the addition of functionality extensions. Commands on the 291 wire should be able invoke the extended functionality. (This is 292 something akin to server plug-ins.) 294 7. Allow for Draft storage of components 296 8. Add, modify, or delete components based on a query of calendar 297 stores. 299 9. Get components from multiple stores in a single command. 301 10. The capability to list calendar stores based on properties. 303 11. The capability to perform an operation on a number of calendar 304 stores. 306 5. Acknowledgments 308 The following have provided input in the drafting of this memo: 310 Mike Weston 312 6. Bibliography 314 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July 315 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt. 317 [ICAL] "Internet Calendaring and Scheduling Core Object Specification - 318 iCalendar", Internet-Draft, July 1997, 319 ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-02.txt. 321 [ITIP] "iCalendar Transport-Independent Interoperability Protocol 322 (ITIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", 323 Internet-Draft, October 1997, 324 http://www.imc.org/draft-ietf-calsch-itip-01.txt. 326 [IMIP] "iCalendar Message-based Interoperability Protocol (IMIP), 327 Internet-Draft, October 1997, 328 http://www.imc.org/draft-ietf-calsch-imip. 330 [IRIP] "iCalendar Message-based Interoperability Protocol (IRIP), 331 Internet-Draft, October 1997, 332 http://www.imc.org/draft-ietf-calsch-irip. 334 7. Authors' Address 336 The following address information is provided in a vCard v2.1, 337 Electronic Business Card, format. 339 Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 6 340 BEGIN:VCARD 341 FN:Andre Courtemanche 342 ORG:CS&T 343 ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 344 3L5;Canada 345 TEL;WORK;MSG:+1-514-733-8500 346 TEL;WORK;FAX:+1-514-733-8788 347 EMAIL;INTERNET:andre@cst.ca 348 END:VCARD 350 BEGIN:VCARD 351 FN:Frank Dawson 352 ORG:Lotus Development Corporation 353 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford 354 Drive;Raleigh;NC;27613-3502;USA 355 TEL;WORK;MSG:+1-919-676-9515 356 TEL;WORK;FAX:+1-919-676-9564 357 EMAIL;INTERNET:Frank_Dawson@Lotus.com 358 URL:http://home.earthlink.net/~fdawson 359 END:VCARD 361 BEGIN:VCARD 362 FN:Tony Small 363 ORG:Microsoft Corporation 364 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA; 365 98052-6399;USA 366 TEL;WORK;MSG:+1-206-703-2190 367 TEL;WORK;FAX:+1-206-936-7329 368 EMAIL;INTERNET:tonysm@Microsoft.com 369 END:VCARD 371 BEGIN:VCARD 372 FN:Steve Mansour 373 ORG:Netscape Communications Corporation 374 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 375 View;CA;94043;USA 376 TEL;WORK;MSG:+1-650-937-2378 377 TEL;WORK;FAX:+1-650-937-2103 378 EMAIL;INTERNET:sman@netscape.com 379 END:VCARD 381 BEGIN:VCARD 382 FN:Peter O'Leary 383 ORG:Amplitude Software Corp. 384 ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA; 385 94107;USA 386 TEL;WORK;MSG:+1-415-659-3511 387 TEL;WORK;FAX:+1-415-659-0006 388 EMAIL;INTERNET:poleary@amplitude.com 389 END:VCARD 391 This work is part of the Internet Engineering Task Force Calendaring 392 and scheduling Working Group. The chairman of that working group is: 394 BEGIN:VCARD 395 FN:Anik Ganguly 396 ORG:Open Text, Inc. 397 ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road Suite 101; 399 Courtemanche/Dawson/Lippert/Mansour/O'Leary/Small Expires Feb 1999 7 400 Livonia;MI;48152;USA 401 TEL;WORK;MSG:+1-734-542-5955 402 EMAIL;INTERNET:ganguly@acm.org 403 END:VCARD