idnits 2.17.1 draft-ietf-calsch-capreq-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 1) being 73 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([ICAL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 47: '...rements that CAP MUST address in order...' RFC 2119 keyword, line 120: '...rements that CAP MUST address in order...' RFC 2119 keyword, line 169: '...example, "events MUST be scheduled in ...' RFC 2119 keyword, line 283: '...AP data elements MUST be based on the ...' RFC 2119 keyword, line 288: '... elements beyond those defined in [ICAL]. These additions MUST be...' (68 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 17, 2000) is 8560 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 1115 looks like a reference -- Missing reference section? 'ITIP' on line 1119 looks like a reference -- Missing reference section? 'IMIP' on line 1123 looks like a reference -- Missing reference section? 'RFC1738' on line 270 looks like a reference -- Missing reference section? 'IRIP' on line 1126 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 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 Frank Dawson, Lotus 4 Steve Mansour, Netscape 5 Pete O'Leary, Amplitude 6 Doug Royer, Sun Microsystems 7 Tony Small, Microsoft 8 Expires six months after: November 17, 2000 10 CAP Requirements 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or made obsolete by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 To learn the current status of any Internet-Draft, please check the 35 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 36 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 37 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 38 Rim). 40 Distribution of this document is unlimited. 42 Abstract 44 The Calendar Access Protocol (CAP) is an Internet protocol for 45 accessing an [ICAL] based calendar store (CS) from a calendar user 46 agent (CUA). The purpose of this document is to set forth a list of 47 requirements that CAP MUST address in order to meet the needs of the 48 calendaring and scheduling community. 50 This document is based on discussions within the Internet Engineering 51 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 52 More information about the IETF CALSCH working group activities can 53 be found on the IMC web site at http://www.imc.org, the IETF web site 54 at http://www.ietf.org/html.charters/calsch-charter.html. Refer to 55 the references within this document for further information on how to 56 access these various documents. 58 Distribution of this document is unlimited. Comments and suggestions 59 for improvement should be sent to the authors. 61 Copyright (C) The Internet Society 1998. All Rights Reserved. 63 Change History 65 Version 00 - Initial draft. 67 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 68 Version 01 - Revised format; Included initial set of scenarios and 69 requirements. 71 Version 02 - Revised format; Significant modification to set of 72 requirements. Included lists of requirements that are deferred to 73 later versions of CAP or to other drafts. 75 Version 03 - Resubmittal because draft expired. Work is continuing 76 on CAP draft. Added line about RFC2026 conformance. 78 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 79 Table of Contents 80 1. Introduction........................................................4 81 2. Terminology.........................................................4 82 3. Relationship To iCalendar, iTIP and iMIP/iRIP.......................7 83 4. Requirements........................................................7 84 4.1 Basic Usage ......................................................7 85 4.2 Infrastructure ...................................................8 86 4.2.1 Connection Models .............................................8 87 4.2.2 Store Location Models .........................................9 88 4.2.3 Calendar Stores ..............................................10 89 4.2.4 Exception Reporting ..........................................11 90 4.3 Operations on a Calendar ........................................11 91 4.3.1 Deferred Requirements for Operations on a Calendar ...........12 92 4.4 Component Management ............................................12 93 4.4.1 Recurrence ...................................................13 94 4.4.2 Calendar and Component Policies ..............................14 95 4.4.3 Deferred Requirements for Component Management ...............14 96 4.5 Lookup, Query and Discovery .....................................15 97 4.5.1 Lookup .......................................................15 98 4.5.2 Query Capabilities ...........................................15 99 4.5.3 Specific Queries .............................................17 100 4.5.4 Discovery ....................................................17 101 4.5.5 Deferred Requirements for Search .............................18 102 4.6 Security ........................................................18 103 4.7 Designates and Delegation .......................................18 104 4.8 Notification (deferred) .........................................19 105 4.9 Access Control (deferred) .......................................19 106 4.10 Resource Groups and Pools (deferred) ...........................20 107 4.11 CAP Non-requirements ...........................................21 108 5. Open Issues........................................................21 109 6. Acknowledgments....................................................22 110 7. Bibliography.......................................................22 111 8. Authors' Address...................................................22 112 9. Full Copyright Statement...........................................24 114 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 115 1. Introduction 117 The Calendar Access Protocol (CAP) is an Internet protocol for 118 accessing an [ICAL] based calendar store (CS) from a calendar user 119 agent (CUA). The purpose of this document is to set forth a list of 120 requirements that CAP MUST address in order to meet the needs of the 121 calendaring and scheduling community. 123 2. Terminology 125 The terminology used in [ICAL], [ITIP] and [IMIP] are also used 126 within this memo. 128 Calendar 129 A collection of logically related objects or entities each of 130 which may be associated with a calendar date and possibly time of 131 day. These entities can include other calendar properties or 132 calendar components. In addition, a calendar might be 133 hierarchically structured and consist of other sub-calendars. The 134 [ICAL] defines calendar properties, calendar components and 135 component properties. A calendar is identified by its unique 136 calendar identifier. 138 Calendar Access Protocol 139 An Internet protocol that allows a CUA to access and operate on a 140 CS. 142 Calendar Access Rights 143 Some method for specifying permitted operational capabilities for 144 a calendar user. 146 Calendar Component 147 An entity within a calendar. Types of calendar components include 148 events, to-dos, journals, alarms, time zones and freebusy data. A 149 calendar component consists of component properties and possibly 150 other sub-components. For example, an event can consist of an 151 alarm component. 153 Calendar Component Properties 154 An attribute of a particular calendar component. Some calendar 155 component properties are applicable to different types of 156 calendar components. For example, DTSTART is applicable to 157 VEVENT, VTODO, VJOURNAL calendar components. Other calendar 158 components are applicable only to an individual type of calendar 159 component. For example, TZURL is only applicable to VTIMEZONE 160 calendar components. 162 Calendar Identifier 163 Also known as "CalID". A globally unique identifier associated 164 with a calendar within a CS. 166 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 167 Calendar Policy 168 An operational restriction on the access or manipulation of a 169 calendar. For example, "events MUST be scheduled in unit 170 intervals of one hour". 172 Calendar Properties 173 An attribute of a calendar. The attibute applies to the calendar, 174 as a whole. For example, CALSCALE specifies the calendar scale 175 (e.g., GREGORIAN) for the whole calendar. 177 Calendar Service 178 An implementation of an application that manages one or more 179 calendars. 181 Calendar Store 182 Also known as "CS". The data model definition for a Calendar 183 Service. 185 Calendar Store Identifier 186 Also known as "CSID". The identifier for an individual calendar 187 store. A CSID consists of the user, password, host and port 188 portions of a "Common Internet Scheme Syntax" part of a URL, as 189 defined by [RFC1738]. 191 Calendar Store Components 192 Components maintained in a Calendar Store that are not part of 193 any calendar. 195 Calendar Store Properties 196 Properties maintained in a Calendar Store that are not part of 197 any calendar. 199 Calendar User 200 The entity that is associated with the credentials presented by 201 the Calendar User Agent to the Calendar Store. 203 Calendar User Agent 204 Also known as "CUA". The CUA is the software client operated by 205 the calendar user. 207 Calendaring and Scheduling System 208 The computer sub-system that provides the services for accessing, 209 manipulating calendars and scheduling calendar components. 211 Connected Mode 212 A mobile computing mode where the CUA is directly connected to 213 the calendar store. 215 Delegate 216 Is a calendar user (sometimes called the delegatee) who has been 217 assigned participation in a scheduled calendar component (e.g., 218 VEVENT) by one of the attendees in the scheduled calendar 219 component (sometimes called the delegator). An example of a 220 delegate is a team member told to go to a particular meeting. 222 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 223 Designate 224 Is a calendar user who is authorized to act on behalf of another 225 calendar user. An example of a designate is an assistant. 227 Disconnected Mode 228 A mobile computing mode where a CUA can be disconnected from a 229 calendar store. When the CUA is disconnected, it is in the 230 disconnected mode. 232 Fan Out 233 The process by which a calendar store forwards scheduling 234 operations to the attendees not associated with the current 235 calendar. 237 Hierarchical Calendars 238 A CS feature where calendars may contain sub-calendars. The top- 239 most calendar in a hierarchy of calendars is called the root 240 calendar. There may be multiple root calendars in a single CS. 241 Within a hierarchy of calendars, all sub-calendars have a 242 calendar with a parent topographical relationship. In addition, 243 sub-calendars may have sub-calendars (child topographical 244 relationship). In addition, the sub-calendar may have one or more 245 calendars with a sibling topographical relationship. 247 High Bandwidth Connection 248 A communications connection supporting high transfer rates; 249 transfer rates commonly found within a LAN. 251 Local Store 252 A store which is on the same hardware as the CUA. 254 Low Bandwidth Connection 255 A communications connection supporting slow transfer rates; 256 transfer rates commonly found in modem technology. 258 Relative Calendar Identifier 259 Also known as "Relative CalID". A relative identifier for an 260 individual calendar in a calendar store. A Relative CalID 261 consists of the portion of the "scheme part" of a Qualified 262 CalID, following the Calendar Store Identifier. This is the same 263 as the "URL path" of the "Common Internet Scheme Syntax" portion 264 of a URL, as defined by [RFC1738]. 266 Qualified Calendar Identifier 267 Also known as "Qualified CalID". A complete Internet identifier 268 for a specific calendar. A Qualified CalID consists of a CAP 269 specific "scheme" and "scheme part" portion of a URL, as defined 270 in [RFC1738]. A Qualified CalID are written only with the graphic 271 printable characters of the US-ASCII coded character set. 273 Remote Store 274 A store which is not on the same hardware as the CUA. 276 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 277 Sub-calendars 278 Calendars that are contained within other calendars in a 279 hierarchical relationship. 281 3. Relationship To iCalendar, iTIP and iMIP/iRIP 283 The CAP data elements MUST be based on the calendar architecture set 284 forth in [ICAL]. More precisely, CAP will define an Internet protocol 285 for accessing a CS that consists of one or more calendars, each 286 consisting of numerous [ICAL] components. The definition of CAP might 287 necessitate adding components, properties, parameters and other 288 elements beyond those defined in [ICAL]. These additions MUST be 289 defined in a manner consistent with and upwards compatible to the 290 data model defined by [ICAL]. 292 Where it makes practical sense, CAP SHOULD make use of the scheduling 293 workflow defined by [ITIP]. 295 CAP will not require that [IMIP] or [IRIP] MUST be used to 296 communicate with other calendar users. 298 4. Requirements 300 4.1 Basic Usage 302 CAP MUST specify: 304 - How to provide a standard protocol to allow a CUA to 305 interoperate with a CS. 307 - Using only CAP, a CUA MUST be able to access and manipulate a 308 calendar. CAP MUST provide the complete, if minimal, functionality 309 that allows a CUA to access a calendar. 311 - How to allow a CUA to be developed independently of a CS and a 312 CS independently of a CUA. 314 - How to allow an organization to have a mixture of CUAs and CSs 315 from different vendors. With CAP, any CUA in the organization MUST 316 be able to interoperate with any CS. 318 - How to allow for a single CUA to access multiple CSs or 319 calendars. 321 For example, a CUA MUST be able to create calendar components on 322 multiple calendars and/or retrieve calendar components from 323 multiple calendars. 325 - How to allow for a rich featured CUA. 327 For example, allow a CUA to be part of a client which offers 328 rich calendaring, scheduling and related functionality, with the 329 possibility of extending from concepts and services offered by 330 CAP, while still using CAP to access a calendar. 332 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 333 - How to extend the base features in CAP. 335 - How to allow for interpersonal applications to be calendar 336 enabled. 338 For example, a chat application MUST be able to offer a calendar 339 button to create an event between the two or more parties. 341 - How to allow for non-interpersonal applications to be calendar 342 enabled. 344 For example, a reservation system MUST be able to retrieve and 345 update calendar components from a calendar. Other examples of 346 non-interpersonal applications include event planning, resource 347 scheduling, and Human Asset Management (HAM). 349 - How to allow for CUAs without local store and with minimal 350 memory. 352 For example, a cell phone MUST be able to act as a CUA. 354 - How to allow for CUAs with local store that can be kept 355 synchronized with the remote store. 357 For example, a robust featured application might act as a CUA 358 and also provide extra functionality using the local store. 360 - How to allow for CUAs over disconnected, low-bandwidth 361 connections. 363 For example, a PDA MUST be able to act as a CUA and interoperate 364 with a CS over a low-bandwidth wireless connection. 366 - How to allow for CUAs over high bandwidth connections. 368 For example, a PC MUST be able to act as a CUA and interoperate 369 with a CS over a high-speed Ethernet connection. 371 4.2 Infrastructure 373 This section defines a set of infrastructure requirements for CAP. 375 4.2.1 Connection Models 377 CAP MUST support a number of CUA-to-CS connection models. In 378 particular, CAP MUST allow connected and disconnected operation. 380 CUAs and CSs often support the "connected model", where clients 381 maintain long-term connections to servers. Because of this, CAP MUST 382 specify how the connection between a CUA and a CS can be maintained. 384 CAP MUST NOT prevent servers from dropping client connections, 385 particularly idle client connections. CAP MUST provide some ways for 386 clients to indicate that they would like to stay connected, or that 388 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 389 they would like to drop the connection after the current 390 request/response. These requirements are open issues. 392 4.2.2 Store Location Models 394 CAP MUST allow CUAs with local stores and CUAs without local stores. 396 SINGLE REMOTE CS 398 CAP MUST support the store location model where a CUA needs to 399 retrieve everything from a single remote CS. In this model, the CUA 400 does not have a local CS. Instead, a single CS resides remotely and 401 is accessed through CAP. The client MUST always establish the CAP 402 connection in order to function. 404 MULTIPLE REMOTE CS 406 CAP MUST support the model where a CUA has no local CS, but needs to 407 retrieve everything from multiple remote CS. In this model, the CUA 408 does not have any local CS. Instead, multiple CSs reside remotely and 409 are accessed through CAP. The client MUST always establish one or 410 more CAP connections in order to function. 412 SINGLE LOCAL, SINGLE REMOTE CS 414 CAP MUST support the model where a CUA can retrieve everything from 415 the local store and periodically synchronize the local store with a 416 single remote CS. When there is no CAP connection, the CUA can still 417 function. When the CAP connection is re-established, the CUA can 418 update the remote CS with information modified on the local CS while 419 it was disconnected. In addition, the CUA can update its single local 420 CS with information that was modified on the remote CS while the CUA 421 was disconnected. 423 SINGLE LOCAL, MULTIPLE REMOTE CS 425 CAP MUST support the model where a CUA can retrieve everything from a 426 local CS and periodically synchronize with multiple remote CS. When 427 the CAP connection is not established, the CUA can still function. 428 When the CUA re-establishes a connection with each remote CS, it can 429 update the remote CS with information modified while disconnected. In 430 addition, the CUA can update the single local CS with information 431 that was modified on remote CS while the CUA was disconnected. 433 MULTIPLE LOCAL, MULTIPLE REMOTE CS 435 CAP MUST support the model where a CUA can retrieve everything from 436 multiple local CS and periodically synchronize them with multiple 437 remote CS. When a CAP connection is not established, the CUA can 438 still function. When the CUA re-establishes a connection with each 439 remote CS, it can update the remote CS with information modified 440 while disconnected. In addition, the CS associated with the CAP 441 connection can update any of the local CS with information that was 443 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 444 modified while it was disconnected from the remote CS. Multiple local 445 and remote CS can be updated in sequence. 447 When remote and local CSs are involved, it MUST be possible to 448 identify conflicts between the local and remote CSs. It is the 449 responsibility of the CUA to resolve conflicts. 451 "Modified information" includes new, changed and deleted components, 452 as well as properties on calendars and components. 454 4.2.3 Calendar Stores 456 The diagram below describes the data objects maintained in a CS. CAP 457 defines how data in the CS is manipulated. The data consists of: 459 - Calendar Store properties, e.g. local time zone 461 - Calendars, e.g. a user's calendar 463 - Calendar properties, e.g. a user name 465 - Calendar components, e.g. an iCAL VEVENT 467 - Component properties, e.g. DTSTART on a VEVENT 469 - Property attributes, e.g. TZID on DTSTART 471 - Access control rights (deferred) 473 A calendar may contain other calendars to form a hierarchy. Every 474 calendar has its own properties. 476 CAP does not define users. CAP does not define any default or implied 477 relationship between a user and a calendar. Users, via a CUA, 478 authenticate themselves to a CS to access information. All access is 479 subject to access control. 481 Editor Note: Insert calendar store diagram here. In the interim 482 refer to http://www.imc.org/ietf-calendar/csmodel.jpg 484 Calendars are always referenced by their CalIDs. Open issue: whether 485 calendars can also be referenced by their hierarchical name. 487 CalIDs are used in all operations 489 Attendees values can be Qualified CalIDs of varying schemes. For 490 example: 492 ATTENDEE[...]:mailto:a@example.com 493 ATTENDEE[...]:irip://cal-1.example.com/b 494 ATTENDEE[...]:cap://calendar.example.com/c 496 Editor Note: The MAILTO URL is illustrating an "iMIP" URL. 498 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 499 CAP MUST provide a way for the CUA to determine whether or not the CS 500 supports optional or varying capabilities. For example: 502 - Is a particular optional feature (like fan out, or calendar 503 access rights) supported? 505 - Determine what, if any, limitation the CS imposes on unbounded 506 recurrence rules. 508 - Provide a way for the CUA to determine what, if any, limitations 509 the CS imposes on date/time values. For example, there may be dates 510 in the past and future beyond which the CS cannot represent. 512 4.2.4 Exception Reporting 514 The granularity of exception report can be at the level of the 515 calendar, the calendar component, component property, or property 516 attribute as appropriate. 518 CAP MUST provide a way to determine the results of delayed 519 operations. Delayed operations arise from the use of other protocols 520 (IMIP, IRIP), which may take a long time to resolve. Delayed 521 operations have a return code and may have associated calendar data. 522 As an example, an ITIP request for free/busy information may result 523 in the delivery of a VFREEBUSY component. A CUA MUST be able to use 524 CAP to retrieve the VFREEBUSY component. If the operation failed, the 525 CUA MUST be able to determine the reply code. It is an open issue 526 whether CAP MUST support delayed operations and what that means, and 527 how results are returned. 529 4.3 Operations on a Calendar 531 A calendar is assumed to reside on a CS. CAP MUST specify: 533 - How a CUA can create a calendar or sub-calendar. 535 For example, sub-calendars might be used to organize calendar 536 information based on criteria defined by the CUA. 538 - How a CUA can rename a calendar or sub-calendar. 540 For example, the CUA may decide to change the name of a calendar 541 after the calendar has been created. 543 - How a CUA can delete a calendar or sub-calendar. 545 When deleting a calendar, all sub-calendars of the calendar MUST 546 be deleted. This is an open issue. 548 - A CUA can delete a calendar regardless of whether or not the 549 calendar has any entities in it. 551 - A CUA can set and retrieve properties of a calendar or sub- 552 calendar on a CS. 554 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 555 This should include the ability to set and retrieve standard and 556 custom properties, the time zone of a calendar, and the 557 operational hours of a calendar. 559 For example, the CUA may want to schedule an event based on the 560 operational hours of a calendar. 562 4.3.1 Deferred Requirements for Operations on a Calendar 564 CAP is not required to specify: 566 - How to copy a calendar on a CS or between CSs. 568 - How a group operations on a set of calendars. 570 - How to undelete a calendar. 572 - Auto processing on scheduled components in a calendar that need 573 action. 575 For example, if someone tries to create a meeting on a calendar 576 for a user who is on vacation, the CS may automatically delegate 577 the meeting to another user. 579 4.4 Component Management 581 CAP MUST specify, subject to access control: 583 - How the CUA can create a component (event/to-do/journal) on a 584 calendar (direct booking) 586 - How the CUA can create a component on another user's calendar 588 This capability permits the CUA to create calendar components on 589 another calendar, other than their own, but does not necessarily 590 give them the capability to read or modify calendar components. 592 - How the CUA can modify a component on a given calendar 594 - How the CUA can delete a component from one or more calendars 596 - The requirement to delete from multiple calendars might be met 597 with separate requests. 599 - How the CUA can modify, add or delete an arbitrary component 600 property within a specified calendar. 602 For example, modify the SUMMARY property on a calendar 603 component. 605 - How the CUA can modify a parameter of a multi-valued component 606 property within a specified calendar. 608 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 609 For example, modify the PARTSTAT parameter on an ATTENDEE 610 property associated with a particular attendee on a calendar 611 component. 613 - How the CUA can add or modify attachment properties on a 614 specified component. 616 The attachments may be large, and the CUA ought not have to 617 resend the entire component. 619 - How the CUA can send an attachment to the CS. 621 The attachment would be appended to a particular component. 623 - How the CUA can remove a specified attachment from the CS and 624 its property from the specified component. 626 - How hierarchical name can be used for all operations. 628 This requirement indicates that any calendaring or scheduling 629 operation performed on a component or calendar by specifying the 630 UID or CSID, MUST also be available by specifying the 631 hierarchical name. The two exceptions are the request for the 632 hierarchical name given the UID or vice versa. 634 Open Issue: This is still open to discussion. 636 CAP MUST also allow the CUA to do synchronization of two calendars to 637 which it has access. 639 4.4.1 Recurrence 641 CAP MUST specify, subject to access control: 643 - How the CUA can retrieve or delete a calendar component based on 644 the UID, and an optional RECURRENCE-ID. 646 For example, retrieve the single instance of a recurring meeting 647 by specifying both the UID for the recurring meeting and the 648 RECURRENCE-ID of the instance. 650 - How the CUA can modify or delete an instance of a recurring 651 component, or all recurrences. 653 - How the CUA can modify all instances of a recurring component 654 that occur before a specified date, or after a particular date. 656 Open issue: whether the following requirements related to expansion 657 of recurrence are deferred. 659 - How the CUA can request the CS to send down components with or 660 without expansion of recurring calendar components. 662 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 663 - CAP MUST permit the CS to refuse this request, so that if the CS 664 normally provides expansions of recurring calendar components, it 665 can refuse the request to not expand. However, the CS MUST 666 terminate the expansion eventually. 668 - How the CUA can find out, and perhaps change, the length of time 669 for which recurring calendar components are expanded. 671 - How the CUA can retrieve, and perhaps set, the period for or 672 number of recurrences expanded on a recurring component. 674 This could be 0, infinity, a specific DTEND, or a consistent 675 length of time from "today" into the future. 677 4.4.2 Calendar and Component Policies 679 CAP MUST specify: 681 - How the CUA tells the CS to prevent conflicts (double booking) 682 on a calendar 684 The scenario is that a calendar could be marked for "allow no 685 conflicts", and the CS would automatically prevent this. This 686 might apply to direct booking or scheduling or both. 688 - How operational hours for a calendar are enforced 690 Each calendar MUST have a property for operational hours, and 691 CAP MUST specify how the CUA tells the CS to enforce those 692 operational hours. This means that the CS prevents components 693 from being added in a manner that violates the operational hours 694 set by the user. CAP MUST specify how policy enforcement can be 695 overridden by the owner of the calendar. CAP MUST specify 696 whether this includes alarms. This might apply to direct booking 697 or scheduling or both. 699 Open issue: Whether the ability to set a policy of turning down 700 requests that exceed a maximum duration (or length of time between 701 DTSTART and DTEND) is a requirement. 703 4.4.3 Deferred Requirements for Component Management 705 CAP is not required to specify: 707 - Undelete and purge deleted calendar entries. 709 - Modify inline attachment to URL; provide URL to fetch. 711 - Merge or aggregate more than one calendar. 713 - Lock access to calendar. 715 - Delayed or asynchronous transactions. 717 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 718 - The CUA requesting a size limit before retrieving components 719 from the CS. The CS might send partial components if the 720 component's size exceeded the limit. CAP would permdit the CS to 721 refuse the request or give its preferred value. 723 - The CS synchronizing 2 calendars. 725 - How the CUA tells the CS to prevent conflicts with respect to an 726 individual component in the calendar. The scenario for this is that 727 a component could be marked for "allow no conflicts", and the CS 728 would automatically prevent a new component from being added in a 729 way which would cause a conflict. This might apply to either direct 730 booking or scheduling or both. 732 - How the CUA can create multiple entries on many CSs. 734 This may occur in one or more operations, perhaps using 735 different calendar protocols (CAP, iRIP, iMIP). 737 4.5 Lookup, Query and Discovery 739 Lookup includes the capability to list things. Querying enables 740 searching and filtering features. Discovery covers requests for 741 information such as what features are supported by the CS. 743 4.5.1 Lookup 745 CAP MUST specify, subject to access control: 747 - How the CUA can list calendars in a single CS, by fetching all 748 the top level CSIDs of the CS. 750 - How the CUA can list all the sub-calendars within a given 751 calendar. 753 - How the CUA can list all component UIDs in a calendar. 755 - How the CUA can retrieve all the free/busy data for a calendar. 757 - How the CUA can retrieve a list of properties for a component or 758 a set of components. 760 For this requirement, the set of components is defined either as 761 all the components in a calendar, or where the set of components 762 is defined by a search query (search query requirements are 763 elaborated in the Query Capabilities section). For example, the 764 CUA could ask for the DTSTART, DTEND and SUMMARY properties for 765 all components with DTSTART later than 9:00 p.m. today. 767 4.5.2 Query Capabilities 769 CAP MUST allow the CUA to retrieve CalIDs, component UIDs or 770 component hierarchical names (open issue) from a given calendar, 771 using queries which specify: 773 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 774 - How the CUA can retrieve data from multiple calendars. 776 This requirement allows the CUA to display multiple calendars to 777 the user. This requirement does not constrain this functionality 778 to a single request as it may be done in multiple requests. 780 - How the CUA to retrieve any named property for a calendar or 781 component. 783 For example, the CUA can retrieve the SUMMARY property for a 784 given component. 786 - Property value equivalence query (e.g., equal to) 788 For example, such as matching the organizer with a specified 789 user, or matching the location with a particular conference 790 room. This should work for all properties. 792 - Pattern-matching string comparison query (e.g., contains) 794 The pattern-matching query MUST be applied to a string property 795 such as a "name" property. The response MUST include a list of 796 calendar (or component) identifiers and MAY include property 797 values for those items. The CUA MUST be able to request which 798 properties (or the entire component) to retrieve. 800 - Property value comparison query (e.g., greater than, less than) 802 This requirement includes only those properties for which a 803 comparison query is possible. This list of properties MUST 804 include DTSTART, DTEND, DURATION. For example, this allows the 805 CUA to ask for all components that begin later than (greater 806 than) the specified time. 808 This requirement MUST be met in a way which allows the CUA to 809 discover which alarms will trigger in a given period. 811 - Multiple property value comparisons combined using Boolean 812 elements (e.g., logical and, logical or, negatation). 814 The CUA MUST be able to discover which components have durations 815 which occur at least partially in a given range of time, either 816 by retrieving the list of UIDs or by retrieving all of the 817 components properties. This requirement allows the CUA to 818 discover all components during a particular day or other time 819 period. This includes instantaneous and all-day calendar items. 820 This requirement does not state that the components MUST be 821 retrieved in their entirety in the same interaction as the 822 query; the query and the component retrieval can be separate 823 interactions between the CUA and the CS. 825 CAP MUST allow synchronization, meaning at a minimum that the CUA is 826 able to find and retrieve new, modified or deleted entries for a 827 given time period. The CUA MUST be able to find out which entries 829 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 830 have been added, modified or deleted since it last synchronized, in 831 order to operate in disconnected mode. This requirement may be 832 satisfied using the query requirements already defined. 834 4.5.3 Specific Queries 836 These are specific scenarios required by calendaring operations which 837 may require special attention to ensure that they can be done with 838 the querying and lookup functionality of CAP. 840 CAP MUST allow, subject to access control: 842 - The CUA to retrieve the CSID for a calendar specified by giving 843 its hierarchical name, and vice versa. 845 This requirement means that hierarchical calendar names MUST be 846 unique on the CS. 848 Open Issue: This is an open issue. 850 - The CUA to discover conflicts given a list of calendars and a 851 time period 853 This feature is to allow the CUA to schedule a group of 854 attendees for a meeting at a particular time; the CUA MUST be 855 able to find out if those attendees are free at that time. This 856 requirement does not specify whether the discovery is done 857 mainly on the CS or on the CUA. For example, the CUA could ask 858 for the free/busy data for each calendar during the period and 859 then determine conflicts itself, or the CUA could ask the CS 860 which attendees have conflicts during the period. Either 861 approach would satisfy this requirement. 863 - The CUA to discover which calendar components need action. 865 iCalendar entries which need action include scheduled components 866 that have not yet been accepted or declined. The CUA needs to 867 know this list in order to present the items to the user to 868 resolve them. 870 4.5.4 Discovery 872 CAP MUST specify: 874 - How the CUA can query the calendar components which are 875 supported on a named calendar. 877 - How the CUA can query the names of all properties which exist on 878 a given calendar, or the properties which exist on a given 879 component. 881 - How the CUA can query the names of component properties 882 supported by a CS. 884 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 885 - How the CUA can query the time zones supported by the CS 887 4.5.5 Deferred Requirements for Search 889 CAP is not required to specify: 891 - How to roll up free/busy information for a number of calendars 892 (perhaps sub-calendars) into a single free/busy component. 894 - How to fetch all components marked for deletion in a certain 895 range. This could include components somehow marked for deletion 896 but not yet purged from the CS. 898 - How the CUA can determine whether the CS supports multiple 899 reads/writes in the same operation. 901 This would include, for example, the ability to name a number of 902 calendars to add a component to in a single operation 904 4.6 Security 906 CAP MUST specify: 908 - How the CUA authenticates itself to the CS (not the calendar). 910 Authentication to the CS is required for all access to the CS. 911 The CS MUST be able to uniquely identify each user for the 912 purposes of authentication and authorization. 914 - How anonymous access to calendars is specified (if allowed). 916 - How the CUA authenticates to CS using SASL. 918 - How the CUA and the CS negotiate encryption mechanism for a 919 secure connection. 921 - How calendars can be made secure from unwanted access and false 922 entries. 924 - How the CUA and CS can specify denial of service to another 925 calendar user. 927 4.7 Designates and Delegation 929 CAP MUST specify, subject to access control: 931 - How a list of designates is created. 933 - How the CS knows that a user is a valid designate, through 934 authentication or some other mechanism. 936 - How the CUA can delegate to another calendar user. 938 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 939 4.8 Notification (deferred) 941 There are no notification features that are required in CAP. 942 Notification is deemed not to be a requirement, because: 944 - A CUA can poll the CS for new/changed/deleted components, 945 including new ITIP messages. This functionality is needed to 946 support synchronization. 948 - A CUA can handle alarms on components itself. 950 The notification features that were considered but have been deferred 951 include: 953 - Notify the CUA when a change is made to a calendar. 955 - Notify the CUA when an alarm triggers. 957 - Notify the CUA when a calendar component NEEDS-ACTION. 959 - Notify when a CUA attempts to access a calendar, delete, modify, 960 or add a calendar component. 962 4.9 Access Control (deferred) 964 The ability to get and set access control data on calendars and 965 calendar components is useful, but beyond the scope of the initial 966 CAP specification. A CS may apply access control entries to calendars 967 and components, but CAP need not specify how these are to be set and 968 retrieved. Access control entries could be set and retrieved by 969 administrators on the CS through another protocol. Additionally, a CS 970 can enforce the class of each component, by restricting access to 971 "confidential" and "private" components, without any design in CAP to 972 allow this. 974 Access control requirements that were considered but have been 975 deferred include: 977 - CUA query the calendar access rights for the currently 978 authenticated calendar user. 980 - CUA grant/deny designate rights to a given calendar user. 982 - CUA removes OR denies all rights to a given calendar for given 983 calendar users. 985 - CUA grants free/busy view rights on a given calendar to a 986 calendar user. 988 - CUA grants full access rights on a given calendar to a calendar 989 user. 991 - CS performs calendar access rights inheritance on sub-calendars. 993 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 994 - CUA grants/denies access rights to individual properties of 995 individual components. 997 For example, user A can see subject of event B, or user A can 998 set time of event B. 1000 - CUA can set operation limits for user A on calendar B. 1002 For example: 1004 - (a) set time limit C on events for user D can schedule on my 1005 calendar, 1007 - (b) set limit number of events by user E, or 1009 - (c) grant limited access on a calendar such that a user F can 1010 only create events during specified hours. 1012 4.10 Resource Groups and Pools (deferred) 1014 A specification for how to handle resource groups and pools is not a 1015 requirement. These kinds of features will be addressed in a separate, 1016 later draft. 1018 A group has a list of members, all of whom should be included in any 1019 scheduled calendar component. For example, a group could contain a 1020 particular conference room and a particular projector, both of which 1021 should be scheduled for a meeting. Or a group could contain a number 1022 of people working together, all of whom should be scheduled for group 1023 meetings. When a group is included as an attendee, the CS MUST 1024 schedule each of the members of the group. 1026 A pool has a list of members, all of which are identical for the 1027 purposes of scheduling, and only one of them should be scheduled. 1028 When a pool is included as an attendee, the CS MUST schedule the 1029 number of them that was requested. For example, a pool could contain 1030 a number of VCRs, any of which can be scheduled for meetings, when 1031 only one VCR is usually needed. 1033 Resource group and pool features that were considered but were 1034 deferred include: 1036 - CUA can create a list of CSIDs which is a group or pool. 1038 - CUA can request to add a component to every calendar for every 1039 CSID in a group 1041 - CUA can send a single schedule request to the CS, where the 1042 attendee list includes a group. The CS then fans out the request. 1043 Fanning out might be achieved by forwarding the request to all 1044 members of a group, or by placing the request on the calendar of 1045 every member of the group. The members of the group may be on 1046 multiple CSs. 1048 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1049 - CUA can schedule one CSID by scheduling one instance from a 1050 pool. 1052 - Each group/pool itself has properties. 1054 - Access restrictions can be set on a group/pool, to restrict who 1055 can get/set properties and who can schedule the group/pool. 1057 4.11 CAP Non-requirements 1059 CAP is not required to be: 1061 - A client-to-client protocol. 1063 - A server-to-server protocol. 1065 For example, it would not specify how server-to-server updates 1066 of calendaring or scheduling operations are accomplished. 1068 The initial version of CAP is not required to specify: 1070 - How to do a full administration CUA, e.g., add user, delete 1071 user, move user, archive calendar, delete user, change 1072 user/calendar name. 1074 - Inheritance of calendar access rights, property values, etc. 1076 5. Open Issues 1078 Open issues include the following: 1080 - Whether CAP should specify how clients can request their 1081 connections to be kept open, and whether servers can drop 1082 connections at any time. 1084 - Whether calendars can also be referenced by their hierarchical 1085 name. 1087 - Is a particular optional feature (like fan-out, or calendar 1088 access rights) supported? 1090 - Determine what, if any, limitation the CS imposes on unbounded 1091 recurrence rules. 1093 - Whether CAP MUST support delayed operations and what that means, 1094 and how results are returned. 1096 - Whether all sub-calendars of a deleted calendar MUST be deleted. 1098 - Whether the ability to set a policy of turning down requests 1099 that exceed a maximum duration is a requirement. 1101 - Whether expansion of recurrences is required. 1103 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1104 - Whether or not CAP operations support bounding the latency of 1105 responses to operations. 1107 6. Acknowledgments 1109 The following have provided input in the drafting of this memo: 1111 Lisa Lippert, Surendra Reddy, Richard Shusterman. 1113 7. Bibliography 1115 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 1116 - iCalendar", RFC 2445, November 1998, 1117 http://www.ietf.org/rfc/rfc2445.txt. 1119 [ITIP] "iCalendar Transport-Independent Interoperability Protocol 1120 (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", 1121 RFC 2446, November 1998, http://www.ietf.org/rfc/rfc2446.txt. 1123 [IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), RFC 1124 2447, November 1998, http://www.ietf.org/rfc/rfc2447.txt. 1126 [IRIP] "iCalendar Message-based Interoperability Protocol (iRIP), 1127 Internet-Draft, November 1998, , ftp://ftp.ietf.org/internet- 1128 drafts/draft-ietf-calsch-irip-02.txt. 1130 8. Authors' Address 1132 The following address information is provided in a vCard v2.1, 1133 Electronic Business Card, format. 1135 BEGIN:VCARD 1136 VERSION:3.0 1137 FN:Andre Courtemanche 1138 N:Courtemanche;Andre 1139 ORG:CS&T 1140 ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 1141 3L5;Canada 1142 TEL;TYPE=WORK,MSG:+1-514-733-8500 1143 TEL;TYPE=WORK,FAX:+1-514-733-8788 1144 EMAIL;TYPE=INTERNET:andre@cst.ca 1145 END:VCARD 1147 BEGIN:VCARD 1148 VERSION:3.0 1149 FN:Frank Dawson 1150 N:Dawson;Frank 1151 ORG:Lotus Development Corporation 1152 ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; Raleigh; 1153 NC;27613-3502;USA 1154 TEL;TYPE=WORK,MSG:+1-617-693-8728 1155 TEL;TYPE=WORK,FAX:+1-617-693-5552 1156 EMAIL;TYPE=INTERNET:Frank_Dawson@Lotus.com 1157 URL:http://home.earthlink.net/~fdawson 1159 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1160 END:VCARD 1162 BEGIN:VCARD 1163 VERSION:3.0 1164 FN:Tony Small 1165 N:Small;Tony 1166 ORG:Microsoft Corporation 1167 ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; Redmond;WA; 1168 98052-6399;USA 1169 TEL;TYPE=WORK,MSG:+1-206-703-2190 1170 TEL;TYPE=WORK,FAX:+1-206-936-7329 1171 EMAIL;TYPE=INTERNET:tonysm@Microsoft.com 1172 END:VCARD 1174 BEGIN:VCARD 1175 VERSION:3.0 1176 FN:Steve Mansour 1177 N:Mansour;Steve 1178 ORG:Netscape Communications Corporation 1179 ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain 1180 View;CA;94043;USA 1181 TEL;TYPE=WORK,MSG:+1-650-937-2378 1182 TEL;TYPE=WORK,FAX:+1-650-937-2103 1183 EMAIL;TYPE=INTERNET:sman@netscape.com 1184 END:VCARD 1186 BEGIN:VCARD 1187 VERSION:3.0 1188 FN:Peter O'Leary 1189 N:O'Leary;Peter 1190 ORG:Amplitude Software Corp. 1191 ADR;TYPE=WORK,POSTAL,PARCEL:;;185 Berry St. Suite 4700; San 1192 Francisco;CA;94107;USA 1193 TEL;TYPE=WORK,MSG:+1-415-659-3511 1194 TEL;TYPE=WORK,FAX:+1-415-659-0006 1195 EMAIL;TYPE=INTERNET:poleary@amplitude.com 1196 END:VCARD 1198 BEGIN:VCARD 1199 VERSION:3.0 1200 FN:Doug Royer 1201 N:Royer;Doug 1202 ORG:Sun Microsystems 1203 ADR;TYPE=WORK,POSTAL,PARCEL:;;901 San Antonio Road, MS MPK17-105; 1204 Palo Alto;CA;94303;USA 1205 TEL;TYPE=WORK,MSG:+1-650-786-7599 1206 EMAIL;TYPE=INTERNET:doug.royer@sun.com 1207 END:VCARD 1209 This work is part of the Internet Engineering Task Force Calendaring 1210 and scheduling Working Group. The chairmen of that working group are: 1212 BEGIN:VCARD 1213 VERSION:3.0 1215 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1216 FN:Anik Ganguly 1217 N:Ganguly;Anik 1218 ORG:Open Text, Inc. 1219 ADR;TYPE=WORK,POSTAL,PARCEL:;;38777 West Six Mile Road Suite 101; 1220 Livonia;MI;48152;USA 1221 TEL;TYPE=WORK,MSG:+1-734-542-5955 1222 EMAIL;TYPE=INTERNET:ganguly@acm.org 1223 END:VCARD 1225 BEGIN:VCARD 1226 VERSION:3.0 1227 FN:Robert Moskowitz 1228 N:Moskowitz;Robert 1229 EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com 1230 END:VCARD 1232 9. Full Copyright Statement 1234 Copyright (C) The Internet Society (1998). All Rights Reserved. 1236 This document and translations of it may be copied and furnished to 1237 others, and derivative works that comment on or otherwise explain it 1238 or assist in its implementation may be prepared, copied, published 1239 and distributed, in whole or in part, without restriction of any 1240 kind, provided that the above copyright notice and this paragraph are 1241 included on all such copies and derivative works. However, this 1242 document itself may not be modified in any way, such as by removing 1243 the copyright notice or references to the Internet Society or other 1244 Internet organizations, except as needed for the purpose of 1245 developing Internet standards in which case the procedures for 1246 copyrights defined in the Internet Standards process MUST be 1247 followed, or as required to translate it into languages other than 1248 English. 1250 The limited permissions granted above are perpetual and will not be 1251 revoked by the Internet Society or its successors or assigns. 1253 This document and the information contained herein is provided on an 1254 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1255 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1256 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1257 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1258 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1260 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small