idnits 2.17.1 draft-ietf-calsch-capreq-00.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-24) 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 6 longer pages, the longest (page 4) being 80 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.) ** 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 52: '... implementation MUST support, and MAY...' RFC 2119 keyword, line 66: '... MUST...' RFC 2119 keyword, line 106: '... MAY...' RFC 2119 keyword, line 179: '... MUST...' RFC 2119 keyword, line 202: '... MAY...' (2 more instances...) 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 (November 21, 1997) is 9651 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 Alec Dun, Microsoft 4 Frank Dawson, Lotus 5 Steve Mansour, Netscape 6 Pete O'Leary, Amplitude 7 Expires 6 months after: November 21, 1997 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, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced, or made obsolete 20 by other documents at any time. It is not appropriate to use 21 Internet-Drafts as reference material or to cite them other than as a 22 "working draft" or "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 ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Distribution of this document is unlimited. 32 Abstract 34 The Calendar Access Protocol (CAP) protocol defines administrative, 35 calendar management, and calendar component management on calendar 36 stores by owners, designates, and others. The purpose of this 37 document is to set forth a list requirements that CAP must address in 38 order to address the needs of the calendaring and scheduling 39 community. 41 1. Introduction 43 The requirements are broken into the following categories: 45 . Model 47 . Administration 49 . Component Management 51 Each of these is further broken down into requirements that a CAP 52 implementation MUST support, and MAY support. In some cases, 53 functionality which is specifically excluded from CAP is listed in a 55 Courtemanche/Dun/Dawson/Mansour/O'Leary 1 Expires May 1998 56 DOES NOT section. Those items where further input from the working 57 group is needed are listed in a NEEDS DISCUSSION section. 59 1.1 Assumptions 61 1. 62 The data elements of CAP are based on iCalendar. 64 2. Model 66 MUST 68 1. 69 Support two connection models: (a) no data is stored on the client 70 and (b) data is stored on both the client and the server and is 71 synchronized periodically. 73 2. 74 Support a framework for authentication of a calendar user and for 75 one calendar user to act as a designate or proxy for another user. 77 3. 78 Support a framework for the secure transport of data between the 79 CUA and the CS. 81 4. 82 Define a calendar address. 84 5. 85 Specify the granularity of access control on calendar components. 87 6. 88 Enforce access control to calendar components 90 7. 91 Support capabilities negotiation to enable clients to determine 92 the capabilities of a CAP server. Specify how a CUA queries a 93 Calendar Store to determine its attributes. The client must be 94 able to determine which Components are supported by a given 95 Calendar Store. 97 8. 98 Return error codes for valid commands that are not supported by 99 the server. 101 9. 102 Provide the capability to search, select, and operate on calendar 103 stores based on their properties. For example, a property of the 104 store might be its owner. 106 MAY 108 1. 109 Allow Calendar Users to control the access that others have to 110 their calendar. Setting access that a group has to a calendar may 111 be supported. 113 2. 114 Supports two types of transactions. Type 1: if the request cannot 115 be successfully completed on all calendar stores involved, don't 116 do the operation at all. Type 2: complete the operation on as 117 many calendar stores as possible. In either case, any failures 118 must be reported to the client. 120 Courtemanche/Dun/Dawson/Mansour/O'Leary 2 Expires May 1998 121 3. 122 Support server-to-client notification. If the server supports 123 this capability, it must notify a client when a CAP event occurs 124 in which the client has registered interest. 126 4. 127 Supports server fan-out. The fan-out capability can be turned on 128 or off. 130 5. 131 Provide for user-defined rules. Servers are not required to 132 implement this functionality. 134 6. 135 Provide for the archiving (import and export) of calendar stores. 136 Servers are not required to implement archiving. 138 7. 139 Provides for making referrals. That is, supply the new address 140 for a user that is not on this calendar system. Servers are not 141 required to make referrals. 143 8. 144 Support hierarchical calendar stores. 146 9. 147 Group names can be used to invite a list of attendees to an event 148 or to-do. Group names can be used in setting access to events and 149 todos. Servers are not required to explode a group name into a 150 list of individuals. 152 10. 153 Provide support for interrupting a command in progress. 155 11. 156 Provide a mechanism to bound the latency of a response. 158 12. 159 Support the addition of functionality extensions. Commands on the 160 wire should be able invoke the extended functionality. (This is 161 something akin to server plug-ins.) 163 DOES NOT 165 1. 166 Support for fetching components from multiple Calendar Stores 167 simultaneously. (deferred) 169 NEEDS DISCUSSION: 171 1. 172 Should a CAP server provide any directory services or shall 173 directory services be supplied by an external capability. Given 174 that access control to calendar stores must be addressed, is there 175 a need to standardize the way Calendar Users are identified? 177 3. Administration 179 MUST 181 1. 182 Support connect and authenticate the CU. 184 Courtemanche/Dun/Dawson/Mansour/O'Leary 3 Expires May 1998 185 2. 186 Create and delete calendar stores. 188 3. 189 Set and change ownership of a calendar store. 191 4. 192 Support setting and retrieving access control lists on calendars. 193 Determine the access levels. 195 5. 196 Support functions to add, modify, and delete calendar properties. 198 6. 199 Return a handle to a calendar store based on a supplied calendar 200 address and subject to access control. 202 MAY 204 1. 205 List calendar stores subject to access control. 207 DOES NOT 209 1. 210 Provide for server-to-server replication of calendar data. 212 4. Component Management 214 MUST 216 1. 217 Create, modify, and delete components in a calendar store. 219 2. 220 Create or modify a set of component attributes. 222 3. 223 Search for busy time on a calendar store. 225 4. 226 Allow for Draft storage of components 228 5. 229 Fetch components based on a query. The query language must 230 support (a) component property value comparisons and (b) component 231 property parameter value comparisons. The query language must 232 support queries consisting of multiple comparisons joined by 233 boolean operators. 235 6. 236 Return the results of a Get filtered by a supplied list of 237 attributes. 239 7. 240 Read a set of alarms/reminders in a calendar that are set to go 241 off within a range of time. 243 MAY 245 1. 246 Support the expansion of a recurring event or to-do. If recurring 247 expansion is supported, an error must be returned for any problems 248 that occur in the expansion. 250 2. 251 Notifications on multiple stores. 253 3. 254 Modify, delete, and other? operations based on a query. 256 Courtemanche/Dun/Dawson/Mansour/O'Leary 4 Expires May 1998 257 4. 258 Add, modify, or delete components based on a query of calendar 259 stores. 261 NEEDS DISCUSSION 263 1. 264 Get components from multiple stores in a single command. 266 5. Acknowledgments 268 The following have provided input in the drafting of this memo: 270 Mike Weston 272 6. Bibliography 274 7. Author's Address 276 The following address information is provided in a vCard v2.1, 277 Electronic Business Card, format. 279 BEGIN:VCARD 280 FN:Andre Courtemanche 281 ORG:CS&T 282 ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 283 3L5;Canada 284 TEL;WORK;MSG:+1-514-733-8500 285 TEL;WORK;FAX:+1-514-733-8788 286 EMAIL;INTERNET:andre@cst.ca 287 END:VCARD 289 BEGIN:VCARD 290 FN:Frank Dawson 291 ORG:Lotus Development Corporation 292 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 293 3502;USA 294 TEL;WORK;MSG:+1-919-676-9515 295 TEL;WORK;FAX:+1-919-676-9564 296 EMAIL;INTERNET:fdawson@earthlink.net 297 URL:http://home.earthlink.net/~fdawson 298 END:VCARD 300 BEGIN:VCARD 301 FN:Alec Dun 302 ORG:Microsoft Corporation 303 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA; 304 98052-6399;USA 305 TEL;WORK;MSG:+1-206-936-4544 306 TEL;WORK;FAX:+1-206-936-7329 307 EMAIL;INTERNET:alecdu@Microsoft.com 308 END:VCARD 310 BEGIN:VCARD 311 FN:Steve Mansour 313 Courtemanche/Dun/Dawson/Mansour/O'Leary 5 Expires May 1998 314 ORG:Netscape Communications Corporation 315 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 316 View;CA;94043;USA 317 TEL;WORK;MSG:+1-415-937-2378 318 TEL;WORK;FAX:+1-415-428-4059 319 EMAIL;INTERNET:sman@netscape.com 320 END:VCARD 322 BEGIN:VCARD 323 FN:Peter O'Leary 324 ORG:Amplitude Software Corp. 325 ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA; 326 94107;USA 327 TEL;WORK;MSG:+1-415-659-3511 328 TEL;WORK;FAX:+1-415-659-0006 329 EMAIL;INTERNET:poleary@amplitude.com 330 END:VCARD 332 Courtemanche/Dun/Dawson/Mansour/O'Leary 6 Expires May 1998