idnits 2.17.1 draft-ietf-calsch-capreq-03.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: ---------------------------------------------------------------------------- ** 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 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 1 longer page, the longest (page 1) being 1343 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.) ** 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 37: '...rements that CAP MUST address in order...' RFC 2119 keyword, line 112: '...rements that CAP MUST address in order...' RFC 2119 keyword, line 162: '...example, "events MUST be scheduled in ...' RFC 2119 keyword, line 278: '...AP data elements MUST be based on the ...' RFC 2119 keyword, line 283: '... 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 (May 27, 1999) is 9094 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 1125 looks like a reference -- Missing reference section? 'ITIP' on line 1129 looks like a reference -- Missing reference section? 'IMIP' on line 1133 looks like a reference -- Missing reference section? 'RFC1738' on line 264 looks like a reference -- Missing reference section? 'IRIP' on line 1136 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Andre Courtemanche, CS&T 2 Internet Draft Frank Dawson, Lotus 3 Steve Mansour, Netscape 4 Pete O'Leary, Amplitude 5 Doug Royer, Sun Microsystems 6 Tony Small, Microsoft 7 Expires six months after: May 27, 1999 9 CAP Requirements 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The Calendar Access Protocol (CAP) is an Internet protocol for 35 accessing an [ICAL] based calendar store (CS) from a calendar user 36 agent (CUA). The purpose of this document is to set forth a list of 37 requirements that CAP MUST address in order to meet the needs of the 38 calendaring and scheduling community. 40 This document is based on discussions within the Internet Engineering 41 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 42 More information about the IETF CALSCH working group activities can 43 be found on the IMC web site at http://www.imc.org, the IETF web site 44 at http://www.ietf.org/html.charters/calsch-charter.html. Refer to 45 the references within this document for further information on how to 46 access these various documents. 48 Distribution of this document is unlimited. Comments and suggestions 49 for improvement should be sent to the authors. 51 Copyright (C) The Internet Society 1998. All Rights Reserved. 53 Change History 55 Version 00 - Initial draft. 57 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 58 1 Expires November 1999 59 Version 01 - Revised format; Included initial set of scenarios and 60 requirements. 62 Version 02 - Revised format; Significant modification to set of 63 requirements. Included lists of requirements that are deferred to 64 later versions of CAP or to other drafts. 66 Version 03 - Repost of version 02. 68 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 69 2 Expires November 1999 70 Table of Contents 71 1. Introduction........................................................4 72 2. Terminology.........................................................4 73 3. Relationship To iCalendar, iTIP and iMIP/iRIP.......................7 74 4. Requirements........................................................7 75 4.1 Basic Usage ......................................................7 76 4.2 Infrastructure ...................................................8 77 4.2.1 Connection Models .............................................8 78 4.2.2 Store Location Models .........................................9 79 4.2.3 Calendar Stores ..............................................10 80 4.2.4 Exception Reporting ..........................................11 81 4.3 Operations on a Calendar ........................................11 82 4.3.1 Deferred Requirements for Operations on a Calendar ...........12 83 4.4 Component Management ............................................12 84 4.4.1 Recurrence ...................................................13 85 4.4.2 Calendar and Component Policies ..............................14 86 4.4.3 Deferred Requirements for Component Management ...............14 87 4.5 Lookup, Query and Discovery .....................................15 88 4.5.1 Lookup .......................................................15 89 4.5.2 Query Capabilities ...........................................15 90 4.5.3 Specific Queries .............................................17 91 4.5.4 Discovery ....................................................17 92 4.5.5 Deferred Requirements for Search .............................18 93 4.6 Security ........................................................18 94 4.7 Designates and Delegation .......................................18 95 4.8 Notification (deferred) .........................................19 96 4.9 Access Control (deferred) .......................................19 97 4.10 Resource Groups and Pools (deferred) ...........................20 98 4.11 CAP Non-requirements ...........................................21 99 5. Open Issues........................................................21 100 6. Acknowledgments....................................................22 101 7. Bibliography.......................................................22 102 8. Authors' Address...................................................22 103 9. Full Copyright Statement...........................................24 105 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 106 3 Expires November 1999 107 1. Introduction 109 The Calendar Access Protocol (CAP) is an Internet protocol for 110 accessing an [ICAL] based calendar store (CS) from a calendar user 111 agent (CUA). The purpose of this document is to set forth a list of 112 requirements that CAP MUST address in order to meet the needs of the 113 calendaring and scheduling community. 115 2. Terminology 117 The terminology used in [ICAL], [ITIP] and [IMIP] are also used 118 within this memo. 120 Calendar 121 A collection of logically related objects or entities each of 122 which may be associated with a calendar date and possibly time of 123 day. These entities can include other calendar properties or 124 calendar components. In addition, a calendar might be 125 hierarchically structured and consist of other sub-calendars. The 126 [ICAL] defines calendar properties, calendar components and 127 component properties. A calendar is identified by its unique 128 calendar identifier. 130 Calendar Access Protocol 131 An Internet protocol that allows a CUA to access and operate on a 132 CS. 134 Calendar Access Rights 135 Some method for specifying permitted operational capabilities for 136 a calendar user. 138 Calendar Component 139 An entity within a calendar. Types of calendar components include 140 events, to-dos, journals, alarms, time zones and freebusy data. A 141 calendar component consists of component properties and possibly 142 other sub-components. For example, an event can consist of an 143 alarm component. 145 Calendar Component Properties 146 An attribute of a particular calendar component. Some calendar 147 component properties are applicable to different types of 148 calendar components. For example, DTSTART is applicable to 149 VEVENT, VTODO, VJOURNAL calendar components. Other calendar 150 components are applicable only to an individual type of calendar 151 component. For example, TZURL is only applicable to VTIMEZONE 152 calendar components. 154 Calendar Identifier 155 Also known as "CalID". A globally unique identifier associated 156 with a calendar within a CS. 158 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 159 4 Expires November 1999 160 Calendar Policy 161 An operational restriction on the access or manipulation of a 162 calendar. For example, "events MUST be scheduled in unit 163 intervals of one hour". 165 Calendar Properties 166 An attribute of a calendar. The attibute applies to the calendar, 167 as a whole. For example, CALSCALE specifies the calendar scale 168 (e.g., GREGORIAN) for the whole calendar. 170 Calendar Service 171 An implementation of an application that manages one or more 172 calendars. 174 Calendar Store 175 Also known as "CS". The data model definition for a Calendar 176 Service. 178 Calendar Store Identifier 179 Also known as "CSID". The identifier for an individual calendar 180 store. A CSID consists of the user, password, host and port 181 portions of a "Common Internet Scheme Syntax" part of a URL, as 182 defined by [RFC1738]. 184 Calendar Store Components 185 Components maintained in a Calendar Store that are not part of 186 any calendar. 188 Calendar Store Properties 189 Properties maintained in a Calendar Store that are not part of 190 any calendar. 192 Calendar User 193 The entity that is associated with the credentials presented by 194 the Calendar User Agent to the Calendar Store. 196 Calendar User Agent 197 Also known as "CUA". The CUA is the software client operated by 198 the calendar user. 200 Calendaring and Scheduling System 201 The computer sub-system that provides the services for accessing, 202 manipulating calendars and scheduling calendar components. 204 Connected Mode 205 A mobile computing mode where the CUA is directly connected to 206 the calendar store. 208 Delegate 209 Is a calendar user (sometimes called the delegatee) who has been 210 assigned participation in a scheduled calendar component (e.g., 211 VEVENT) by one of the attendees in the scheduled calendar 212 component (sometimes called the delegator). An example of a 213 delegate is a team member told to go to a particular meeting. 215 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 216 5 Expires November 1999 217 Designate 218 Is a calendar user who is authorized to act on behalf of another 219 calendar user. An example of a designate is an assistant. 221 Disconnected Mode 222 A mobile computing mode where a CUA can be disconnected from a 223 calendar store. When the CUA is disconnected, it is in the 224 disconnected mode. 226 Fan Out 227 The process by which a calendar store forwards scheduling 228 operations to the attendees not associated with the current 229 calendar. 231 Hierarchical Calendars 232 A CS feature where calendars may contain sub-calendars. The top- 233 most calendar in a hierarchy of calendars is called the root 234 calendar. There may be multiple root calendars in a single CS. 235 Within a hierarchy of calendars, all sub-calendars have a 236 calendar with a parent topographical relationship. In addition, 237 sub-calendars may have sub-calendars (child topographical 238 relationship). In addition, the sub-calendar may have one or more 239 calendars with a sibling topographical relationship. 241 High Bandwidth Connection 242 A communications connection supporting high transfer rates; 243 transfer rates commonly found within a LAN. 245 Local Store 246 A store which is on the same hardware as the CUA. 248 Low Bandwidth Connection 249 A communications connection supporting slow transfer rates; 250 transfer rates commonly found in modem technology. 252 Relative Calendar Identifier 253 Also known as "Relative CalID". A relative identifier for an 254 individual calendar in a calendar store. A Relative CalID 255 consists of the portion of the "scheme part" of a Qualified 256 CalID, following the Calendar Store Identifier. This is the same 257 as the "URL path" of the "Common Internet Scheme Syntax" portion 258 of a URL, as defined by [RFC1738]. 260 Qualified Calendar Identifier 261 Also known as "Qualified CalID". A complete Internet identifier 262 for a specific calendar. A Qualified CalID consists of a CAP 263 specific "scheme" and "scheme part" portion of a URL, as defined 264 in [RFC1738]. A Qualified CalID are written only with the graphic 265 printable characters of the US-ASCII coded character set. 267 Remote Store 268 A store which is not on the same hardware as the CUA. 270 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 271 6 Expires November 1999 272 Sub-calendars 273 Calendars that are contained within other calendars in a 274 hierarchical relationship. 276 3. Relationship To iCalendar, iTIP and iMIP/iRIP 278 The CAP data elements MUST be based on the calendar architecture set 279 forth in [ICAL]. More precisely, CAP will define an Internet protocol 280 for accessing a CS that consists of one or more calendars, each 281 consisting of numerous [ICAL] components. The definition of CAP might 282 necessitate adding components, properties, parameters and other 283 elements beyond those defined in [ICAL]. These additions MUST be 284 defined in a manner consistent with and upwards compatible to the 285 data model defined by [ICAL]. 287 Where it makes practical sense, CAP SHOULD make use of the scheduling 288 workflow defined by [ITIP]. 290 CAP will not require that [IMIP] or [IRIP] MUST be used to 291 communicate with other calendar users. 293 4. Requirements 295 4.1 Basic Usage 297 CAP MUST specify: 299 - How to provide a standard protocol to allow a CUA to 300 interoperate with a CS. 302 - Using only CAP, a CUA MUST be able to access and manipulate a 303 calendar. CAP MUST provide the complete, if minimal, functionality 304 that allows a CUA to access a calendar. 306 - How to allow a CUA to be developed independently of a CS and a 307 CS independently of a CUA. 309 - How to allow an organization to have a mixture of CUAs and CSs 310 from different vendors. With CAP, any CUA in the organization MUST 311 be able to interoperate with any CS. 313 - How to allow for a single CUA to access multiple CSs or 314 calendars. 316 For example, a CUA MUST be able to create calendar components on 317 multiple calendars and/or retrieve calendar components from 318 multiple calendars. 320 - How to allow for a rich featured CUA. 322 For example, allow a CUA to be part of a client which offers 323 rich calendaring, scheduling and related functionality, with the 324 possibility of extending from concepts and services offered by 325 CAP, while still using CAP to access a calendar. 327 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 328 7 Expires November 1999 329 - How to extend the base features in CAP. 331 - How to allow for interpersonal applications to be calendar 332 enabled. 334 For example, a chat application MUST be able to offer a calendar 335 button to create an event between the two or more parties. 337 - How to allow for non-interpersonal applications to be calendar 338 enabled. 340 For example, a reservation system MUST be able to retrieve and 341 update calendar components from a calendar. Other examples of 342 non-interpersonal applications include event planning, resource 343 scheduling, and Human Asset Management (HAM). 345 - How to allow for CUAs without local store and with minimal 346 memory. 348 For example, a cell phone MUST be able to act as a CUA. 350 - How to allow for CUAs with local store that can be kept 351 synchronized with the remote store. 353 For example, a robust featured application might act as a CUA 354 and also provide extra functionality using the local store. 356 - How to allow for CUAs over disconnected, low-bandwidth 357 connections. 359 For example, a PDA MUST be able to act as a CUA and interoperate 360 with a CS over a low-bandwidth wireless connection. 362 - How to allow for CUAs over high bandwidth connections. 364 For example, a PC MUST be able to act as a CUA and interoperate 365 with a CS over a high-speed Ethernet connection. 367 4.2 Infrastructure 369 This section defines a set of infrastructure requirements for CAP. 371 4.2.1 Connection Models 373 CAP MUST support a number of CUA-to-CS connection models. In 374 particular, CAP MUST allow connected and disconnected operation. 376 CUAs and CSs often support the "connected model", where clients 377 maintain long-term connections to servers. Because of this, CAP MUST 378 specify how the connection between a CUA and a CS can be maintained. 380 CAP MUST NOT prevent servers from dropping client connections, 381 particularly idle client connections. CAP MUST provide some ways for 382 clients to indicate that they would like to stay connected, or that 384 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 385 8 Expires November 1999 386 they would like to drop the connection after the current 387 request/response. These requirements are open issues. 389 4.2.2 Store Location Models 391 CAP MUST allow CUAs with local stores and CUAs without local stores. 393 SINGLE REMOTE CS 395 CAP MUST support the store location model where a CUA needs to 396 retrieve everything from a single remote CS. In this model, the CUA 397 does not have a local CS. Instead, a single CS resides remotely and 398 is accessed through CAP. The client MUST always establish the CAP 399 connection in order to function. 401 MULTIPLE REMOTE CS 403 CAP MUST support the model where a CUA has no local CS, but needs to 404 retrieve everything from multiple remote CS. In this model, the CUA 405 does not have any local CS. Instead, multiple CSs reside remotely and 406 are accessed through CAP. The client MUST always establish one or 407 more CAP connections in order to function. 409 SINGLE LOCAL, SINGLE REMOTE CS 411 CAP MUST support the model where a CUA can retrieve everything from 412 the local store and periodically synchronize the local store with a 413 single remote CS. When there is no CAP connection, the CUA can still 414 function. When the CAP connection is re-established, the CUA can 415 update the remote CS with information modified on the local CS while 416 it was disconnected. In addition, the CUA can update its single local 417 CS with information that was modified on the remote CS while the CUA 418 was disconnected. 420 SINGLE LOCAL, MULTIPLE REMOTE CS 422 CAP MUST support the model where a CUA can retrieve everything from a 423 local CS and periodically synchronize with multiple remote CS. When 424 the CAP connection is not established, the CUA can still function. 425 When the CUA re-establishes a connection with each remote CS, it can 426 update the remote CS with information modified while disconnected. In 427 addition, the CUA can update the single local CS with information 428 that was modified on remote CS while the CUA was disconnected. 430 MULTIPLE LOCAL, MULTIPLE REMOTE CS 432 CAP MUST support the model where a CUA can retrieve everything from 433 multiple local CS and periodically synchronize them with multiple 434 remote CS. When a CAP connection is not established, the CUA can 435 still function. When the CUA re-establishes a connection with each 436 remote CS, it can update the remote CS with information modified 437 while disconnected. In addition, the CS associated with the CAP 438 connection can update any of the local CS with information that was 440 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 441 9 Expires November 1999 442 modified while it was disconnected from the remote CS. Multiple local 443 and remote CS can be updated in sequence. 445 When remote and local CSs are involved, it MUST be possible to 446 identify conflicts between the local and remote CSs. It is the 447 responsibility of the CUA to resolve conflicts. 449 "Modified information" includes new, changed and deleted components, 450 as well as properties on calendars and components. 452 4.2.3 Calendar Stores 454 The diagram below describes the data objects maintained in a CS. CAP 455 defines how data in the CS is manipulated. The data consists of: 457 - Calendar Store properties, e.g. local time zone 459 - Calendars, e.g. a user's calendar 461 - Calendar properties, e.g. a user name 463 - Calendar components, e.g. an iCAL VEVENT 465 - Component properties, e.g. DTSTART on a VEVENT 467 - Property attributes, e.g. TZID on DTSTART 469 - Access control rights (deferred) 471 A calendar may contain other calendars to form a hierarchy. Every 472 calendar has its own properties. 474 CAP does not define users. CAP does not define any default or implied 475 relationship between a user and a calendar. Users, via a CUA, 476 authenticate themselves to a CS to access information. All access is 477 subject to access control. 479 Editor Note: Insert calendar store diagram here. In the interim 480 refer to http://www.imc.org/ietf-calendar/csmodel.jpg 482 Calendars are always referenced by their CalIDs. Open issue: whether 483 calendars can also be referenced by their hierarchical name. 485 CalIDs are used in all operations 487 Attendees values can be Qualified CalIDs of varying schemes. For 488 example: 490 ATTENDEE[...]:mailto:a@example.com 491 ATTENDEE[...]:irip://cal-1.example.com/b 492 ATTENDEE[...]:cap://calendar.example.com/c 494 Editor Note: The MAILTO URL is illustrating an "iMIP" URL. 496 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 497 10 Expires November 1999 498 CAP MUST provide a way for the CUA to determine whether or not the CS 499 supports optional or varying capabilities. For example: 501 - Is a particular optional feature (like fan out, or calendar 502 access rights) supported? 504 - Determine what, if any, limitation the CS imposes on unbounded 505 recurrence rules. 507 - Provide a way for the CUA to determine what, if any, limitations 508 the CS imposes on date/time values. For example, there may be dates 509 in the past and future beyond which the CS cannot represent. 511 4.2.4 Exception Reporting 513 The granularity of exception report can be at the level of the 514 calendar, the calendar component, component property, or property 515 attribute as appropriate. 517 CAP MUST provide a way to determine the results of delayed 518 operations. Delayed operations arise from the use of other protocols 519 (IMIP, IRIP), which may take a long time to resolve. Delayed 520 operations have a return code and may have associated calendar data. 521 As an example, an ITIP request for free/busy information may result 522 in the delivery of a VFREEBUSY component. A CUA MUST be able to use 523 CAP to retrieve the VFREEBUSY component. If the operation failed, the 524 CUA MUST be able to determine the reply code. It is an open issue 525 whether CAP MUST support delayed operations and what that means, and 526 how results are returned. 528 4.3 Operations on a Calendar 530 A calendar is assumed to reside on a CS. CAP MUST specify: 532 - How a CUA can create a calendar or sub-calendar. 534 For example, sub-calendars might be used to organize calendar 535 information based on criteria defined by the CUA. 537 - How a CUA can rename a calendar or sub-calendar. 539 For example, the CUA may decide to change the name of a calendar 540 after the calendar has been created. 542 - How a CUA can delete a calendar or sub-calendar. 544 When deleting a calendar, all sub-calendars of the calendar MUST 545 be deleted. This is an open issue. 547 - A CUA can delete a calendar regardless of whether or not the 548 calendar has any entities in it. 550 - A CUA can set and retrieve properties of a calendar or sub- 551 calendar on a CS. 553 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 554 11 Expires November 1999 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 12 Expires November 1999 610 For example, modify the PARTSTAT parameter on an ATTENDEE 611 property associated with a particular attendee on a calendar 612 component. 614 - How the CUA can add or modify attachment properties on a 615 specified component. 617 The attachments may be large, and the CUA ought not have to 618 resend the entire component. 620 - How the CUA can send an attachment to the CS. 622 The attachment would be appended to a particular component. 624 - How the CUA can remove a specified attachment from the CS and 625 its property from the specified component. 627 - How hierarchical name can be used for all operations. 629 This requirement indicates that any calendaring or scheduling 630 operation performed on a component or calendar by specifying the 631 UID or CSID, MUST also be available by specifying the 632 hierarchical name. The two exceptions are the request for the 633 hierarchical name given the UID or vice versa. 635 Open Issue: This is still open to discussion. 637 CAP MUST also allow the CUA to do synchronization of two calendars to 638 which it has access. 640 4.4.1 Recurrence 642 CAP MUST specify, subject to access control: 644 - How the CUA can retrieve or delete a calendar component based on 645 the UID, and an optional RECURRENCE-ID. 647 For example, retrieve the single instance of a recurring meeting 648 by specifying both the UID for the recurring meeting and the 649 RECURRENCE-ID of the instance. 651 - How the CUA can modify or delete an instance of a recurring 652 component, or all recurrences. 654 - How the CUA can modify all instances of a recurring component 655 that occur before a specified date, or after a particular date. 657 Open issue: whether the following requirements related to expansion 658 of recurrence are deferred. 660 - How the CUA can request the CS to send down components with or 661 without expansion of recurring calendar components. 663 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 664 13 Expires November 1999 665 - CAP MUST permit the CS to refuse this request, so that if the CS 666 normally provides expansions of recurring calendar components, it 667 can refuse the request to not expand. However, the CS MUST 668 terminate the expansion eventually. 670 - How the CUA can find out, and perhaps change, the length of time 671 for which recurring calendar components are expanded. 673 - How the CUA can retrieve, and perhaps set, the period for or 674 number of recurrences expanded on a recurring component. 676 This could be 0, infinity, a specific DTEND, or a consistent 677 length of time from "today" into the future. 679 4.4.2 Calendar and Component Policies 681 CAP MUST specify: 683 - How the CUA tells the CS to prevent conflicts (double booking) 684 on a calendar 686 The scenario is that a calendar could be marked for "allow no 687 conflicts", and the CS would automatically prevent this. This 688 might apply to direct booking or scheduling or both. 690 - How operational hours for a calendar are enforced 692 Each calendar MUST have a property for operational hours, and 693 CAP MUST specify how the CUA tells the CS to enforce those 694 operational hours. This means that the CS prevents components 695 from being added in a manner that violates the operational hours 696 set by the user. CAP MUST specify how policy enforcement can be 697 overridden by the owner of the calendar. CAP MUST specify 698 whether this includes alarms. This might apply to direct booking 699 or scheduling or both. 701 Open issue: Whether the ability to set a policy of turning down 702 requests that exceed a maximum duration (or length of time between 703 DTSTART and DTEND) is a requirement. 705 4.4.3 Deferred Requirements for Component Management 707 CAP is not required to specify: 709 - Undelete and purge deleted calendar entries. 711 - Modify inline attachment to URL; provide URL to fetch. 713 - Merge or aggregate more than one calendar. 715 - Lock access to calendar. 717 - Delayed or asynchronous transactions. 719 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 720 14 Expires November 1999 721 - The CUA requesting a size limit before retrieving components 722 from the CS. The CS might send partial components if the 723 component's size exceeded the limit. CAP would permdit the CS to 724 refuse the request or give its preferred value. 726 - The CS synchronizing 2 calendars. 728 - How the CUA tells the CS to prevent conflicts with respect to an 729 individual component in the calendar. The scenario for this is that 730 a component could be marked for "allow no conflicts", and the CS 731 would automatically prevent a new component from being added in a 732 way which would cause a conflict. This might apply to either direct 733 booking or scheduling or both. 735 - How the CUA can create multiple entries on many CSs. 737 This may occur in one or more operations, perhaps using 738 different calendar protocols (CAP, iRIP, iMIP). 740 4.5 Lookup, Query and Discovery 742 Lookup includes the capability to list things. Querying enables 743 searching and filtering features. Discovery covers requests for 744 information such as what features are supported by the CS. 746 4.5.1 Lookup 748 CAP MUST specify, subject to access control: 750 - How the CUA can list calendars in a single CS, by fetching all 751 the top level CSIDs of the CS. 753 - How the CUA can list all the sub-calendars within a given 754 calendar. 756 - How the CUA can list all component UIDs in a calendar. 758 - How the CUA can retrieve all the free/busy data for a calendar. 760 - How the CUA can retrieve a list of properties for a component or 761 a set of components. 763 For this requirement, the set of components is defined either as 764 all the components in a calendar, or where the set of components 765 is defined by a search query (search query requirements are 766 elaborated in the Query Capabilities section). For example, the 767 CUA could ask for the DTSTART, DTEND and SUMMARY properties for 768 all components with DTSTART later than 9:00 p.m. today. 770 4.5.2 Query Capabilities 772 CAP MUST allow the CUA to retrieve CalIDs, component UIDs or 773 component hierarchical names (open issue) from a given calendar, 774 using queries which specify: 776 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 777 15 Expires November 1999 778 - How the CUA can retrieve data from multiple calendars. 780 This requirement allows the CUA to display multiple calendars to 781 the user. This requirement does not constrain this functionality 782 to a single request as it may be done in multiple requests. 784 - How the CUA to retrieve any named property for a calendar or 785 component. 787 For example, the CUA can retrieve the SUMMARY property for a 788 given component. 790 - Property value equivalence query (e.g., equal to) 792 For example, such as matching the organizer with a specified 793 user, or matching the location with a particular conference 794 room. This should work for all properties. 796 - Pattern-matching string comparison query (e.g., contains) 798 The pattern-matching query MUST be applied to a string property 799 such as a "name" property. The response MUST include a list of 800 calendar (or component) identifiers and MAY include property 801 values for those items. The CUA MUST be able to request which 802 properties (or the entire component) to retrieve. 804 - Property value comparison query (e.g., greater than, less than) 806 This requirement includes only those properties for which a 807 comparison query is possible. This list of properties MUST 808 include DTSTART, DTEND, DURATION. For example, this allows the 809 CUA to ask for all components that begin later than (greater 810 than) the specified time. 812 This requirement MUST be met in a way which allows the CUA to 813 discover which alarms will trigger in a given period. 815 - Multiple property value comparisons combined using Boolean 816 elements (e.g., logical and, logical or, negatation). 818 The CUA MUST be able to discover which components have durations 819 which occur at least partially in a given range of time, either 820 by retrieving the list of UIDs or by retrieving all of the 821 components properties. This requirement allows the CUA to 822 discover all components during a particular day or other time 823 period. This includes instantaneous and all-day calendar items. 824 This requirement does not state that the components MUST be 825 retrieved in their entirety in the same interaction as the 826 query; the query and the component retrieval can be separate 827 interactions between the CUA and the CS. 829 CAP MUST allow synchronization, meaning at a minimum that the CUA is 830 able to find and retrieve new, modified or deleted entries for a 831 given time period. The CUA MUST be able to find out which entries 833 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 834 16 Expires November 1999 835 have been added, modified or deleted since it last synchronized, in 836 order to operate in disconnected mode. This requirement may be 837 satisfied using the query requirements already defined. 839 4.5.3 Specific Queries 841 These are specific scenarios required by calendaring operations which 842 may require special attention to ensure that they can be done with 843 the querying and lookup functionality of CAP. 845 CAP MUST allow, subject to access control: 847 - The CUA to retrieve the CSID for a calendar specified by giving 848 its hierarchical name, and vice versa. 850 This requirement means that hierarchical calendar names MUST be 851 unique on the CS. 853 Open Issue: This is an open issue. 855 - The CUA to discover conflicts given a list of calendars and a 856 time period 858 This feature is to allow the CUA to schedule a group of 859 attendees for a meeting at a particular time; the CUA MUST be 860 able to find out if those attendees are free at that time. This 861 requirement does not specify whether the discovery is done 862 mainly on the CS or on the CUA. For example, the CUA could ask 863 for the free/busy data for each calendar during the period and 864 then determine conflicts itself, or the CUA could ask the CS 865 which attendees have conflicts during the period. Either 866 approach would satisfy this requirement. 868 - The CUA to discover which calendar components need action. 870 iCalendar entries which need action include scheduled components 871 that have not yet been accepted or declined. The CUA needs to 872 know this list in order to present the items to the user to 873 resolve them. 875 4.5.4 Discovery 877 CAP MUST specify: 879 - How the CUA can query the calendar components which are 880 supported on a named calendar. 882 - How the CUA can query the names of all properties which exist on 883 a given calendar, or the properties which exist on a given 884 component. 886 - How the CUA can query the names of component properties 887 supported by a CS. 889 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 890 17 Expires November 1999 891 - How the CUA can query the time zones supported by the CS 893 4.5.5 Deferred Requirements for Search 895 CAP is not required to specify: 897 - How to roll up free/busy information for a number of calendars 898 (perhaps sub-calendars) into a single free/busy component. 900 - How to fetch all components marked for deletion in a certain 901 range. This could include components somehow marked for deletion 902 but not yet purged from the CS. 904 - How the CUA can determine whether the CS supports multiple 905 reads/writes in the same operation. 907 This would include, for example, the ability to name a number of 908 calendars to add a component to in a single operation 910 4.6 Security 912 CAP MUST specify: 914 - How the CUA authenticates itself to the CS (not the calendar). 916 Authentication to the CS is required for all access to the CS. 917 The CS MUST be able to uniquely identify each user for the 918 purposes of authentication and authorization. 920 - How anonymous access to calendars is specified (if allowed). 922 - How the CUA authenticates to CS using SASL. 924 - How the CUA and the CS negotiate encryption mechanism for a 925 secure connection. 927 - How calendars can be made secure from unwanted access and false 928 entries. 930 - How the CUA and CS can specify denial of service to another 931 calendar user. 933 4.7 Designates and Delegation 935 CAP MUST specify, subject to access control: 937 - How a list of designates is created. 939 - How the CS knows that a user is a valid designate, through 940 authentication or some other mechanism. 942 - How the CUA can delegate to another calendar user. 944 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 945 18 Expires November 1999 946 4.8 Notification (deferred) 948 There are no notification features that are required in CAP. 949 Notification is deemed not to be a requirement, because: 951 - A CUA can poll the CS for new/changed/deleted components, 952 including new ITIP messages. This functionality is needed to 953 support synchronization. 955 - A CUA can handle alarms on components itself. 957 The notification features that were considered but have been deferred 958 include: 960 - Notify the CUA when a change is made to a calendar. 962 - Notify the CUA when an alarm triggers. 964 - Notify the CUA when a calendar component NEEDS-ACTION. 966 - Notify when a CUA attempts to access a calendar, delete, modify, 967 or add a calendar component. 969 4.9 Access Control (deferred) 971 The ability to get and set access control data on calendars and 972 calendar components is useful, but beyond the scope of the initial 973 CAP specification. A CS may apply access control entries to calendars 974 and components, but CAP need not specify how these are to be set and 975 retrieved. Access control entries could be set and retrieved by 976 administrators on the CS through another protocol. Additionally, a CS 977 can enforce the class of each component, by restricting access to 978 "confidential" and "private" components, without any design in CAP to 979 allow this. 981 Access control requirements that were considered but have been 982 deferred include: 984 - CUA query the calendar access rights for the currently 985 authenticated calendar user. 987 - CUA grant/deny designate rights to a given calendar user. 989 - CUA removes OR denies all rights to a given calendar for given 990 calendar users. 992 - CUA grants free/busy view rights on a given calendar to a 993 calendar user. 995 - CUA grants full access rights on a given calendar to a calendar 996 user. 998 - CS performs calendar access rights inheritance on sub-calendars. 1000 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1001 19 Expires November 1999 1002 - CUA grants/denies access rights to individual properties of 1003 individual components. 1005 For example, user A can see subject of event B, or user A can 1006 set time of event B. 1008 - CUA can set operation limits for user A on calendar B. 1010 For example: 1012 - (a) set time limit C on events for user D can schedule on my 1013 calendar, 1015 - (b) set limit number of events by user E, or 1017 - (c) grant limited access on a calendar such that a user F can 1018 only create events during specified hours. 1020 4.10 Resource Groups and Pools (deferred) 1022 A specification for how to handle resource groups and pools is not a 1023 requirement. These kinds of features will be addressed in a separate, 1024 later draft. 1026 A group has a list of members, all of whom should be included in any 1027 scheduled calendar component. For example, a group could contain a 1028 particular conference room and a particular projector, both of which 1029 should be scheduled for a meeting. Or a group could contain a number 1030 of people working together, all of whom should be scheduled for group 1031 meetings. When a group is included as an attendee, the CS MUST 1032 schedule each of the members of the group. 1034 A pool has a list of members, all of which are identical for the 1035 purposes of scheduling, and only one of them should be scheduled. 1036 When a pool is included as an attendee, the CS MUST schedule the 1037 number of them that was requested. For example, a pool could contain 1038 a number of VCRs, any of which can be scheduled for meetings, when 1039 only one VCR is usually needed. 1041 Resource group and pool features that were considered but were 1042 deferred include: 1044 - CUA can create a list of CSIDs which is a group or pool. 1046 - CUA can request to add a component to every calendar for every 1047 CSID in a group 1049 - CUA can send a single schedule request to the CS, where the 1050 attendee list includes a group. The CS then fans out the request. 1051 Fanning out might be achieved by forwarding the request to all 1052 members of a group, or by placing the request on the calendar of 1053 every member of the group. The members of the group may be on 1054 multiple CSs. 1056 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1057 20 Expires November 1999 1058 - CUA can schedule one CSID by scheduling one instance from a 1059 pool. 1061 - Each group/pool itself has properties. 1063 - Access restrictions can be set on a group/pool, to restrict who 1064 can get/set properties and who can schedule the group/pool. 1066 4.11 CAP Non-requirements 1068 CAP is not required to be: 1070 - A client-to-client protocol. 1072 - A server-to-server protocol. 1074 For example, it would not specify how server-to-server updates 1075 of calendaring or scheduling operations are accomplished. 1077 The initial version of CAP is not required to specify: 1079 - How to do a full administration CUA, e.g., add user, delete 1080 user, move user, archive calendar, delete user, change 1081 user/calendar name. 1083 - Inheritance of calendar access rights, property values, etc. 1085 5. Open Issues 1087 Open issues include the following: 1089 - Whether CAP should specify how clients can request their 1090 connections to be kept open, and whether servers can drop 1091 connections at any time. 1093 - Whether calendars can also be referenced by their hierarchical 1094 name. 1096 - Is a particular optional feature (like fan-out, or calendar 1097 access rights) supported? 1099 - Determine what, if any, limitation the CS imposes on unbounded 1100 recurrence rules. 1102 - Whether CAP MUST support delayed operations and what that means, 1103 and how results are returned. 1105 - Whether all sub-calendars of a deleted calendar MUST be deleted. 1107 - Whether the ability to set a policy of turning down requests 1108 that exceed a maximum duration is a requirement. 1110 - Whether expansion of recurrences is required. 1112 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1113 21 Expires November 1999 1114 - Whether or not CAP operations support bounding the latency of 1115 responses to operations. 1117 6. Acknowledgments 1119 The following have provided input in the drafting of this memo: 1121 Lisa Lippert, Surendra Reddy, Richard Shusterman. 1123 7. Bibliography 1125 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 1126 - iCalendar", RFC 2445, November 1998, 1127 http://www.ietf.org/rfc/rfc2445.txt. 1129 [ITIP] "iCalendar Transport-Independent Interoperability Protocol 1130 (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", 1131 RFC 2446, November 1998, http://www.ietf.org/rfc/rfc2446.txt. 1133 [IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), RFC 1134 2447, November 1998, http://www.ietf.org/rfc/rfc2447.txt. 1136 [IRIP] "iCalendar Message-based Interoperability Protocol (iRIP), 1137 Internet-Draft, November 1998, , ftp://ftp.ietf.org/internet- 1138 drafts/draft-ietf-calsch-irip-02.txt. 1140 8. Authors' Address 1142 The following address information is provided in a vCard v2.1, 1143 Electronic Business Card, format. 1145 BEGIN:VCARD 1146 VERSION:3.0 1147 FN:Andre Courtemanche 1148 N:Courtemanche;Andre 1149 ORG:CS&T 1150 ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 1151 3L5;Canada 1152 TEL;TYPE=WORK,MSG:+1-514-733-8500 1153 TEL;TYPE=WORK,FAX:+1-514-733-8788 1154 EMAIL;TYPE=INTERNET:andre@cst.ca 1155 END:VCARD 1157 BEGIN:VCARD 1158 VERSION:3.0 1159 FN:Frank Dawson 1160 N:Dawson;Frank 1161 ORG:Lotus Development Corporation 1162 ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; Raleigh; 1163 NC;27613-3502;USA 1164 TEL;TYPE=WORK,MSG:+1-617-693-8728 1165 TEL;TYPE=WORK,FAX:+1-617-693-5552 1166 EMAIL;TYPE=INTERNET:Frank_Dawson@Lotus.com 1167 URL:http://home.earthlink.net/~fdawson 1169 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1170 22 Expires November 1999 1171 END:VCARD 1173 BEGIN:VCARD 1174 VERSION:3.0 1175 FN:Tony Small 1176 N:Small;Tony 1177 ORG:Microsoft Corporation 1178 ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; Redmond;WA; 1179 98052-6399;USA 1180 TEL;TYPE=WORK,MSG:+1-206-703-2190 1181 TEL;TYPE=WORK,FAX:+1-206-936-7329 1182 EMAIL;TYPE=INTERNET:tonysm@Microsoft.com 1183 END:VCARD 1185 BEGIN:VCARD 1186 VERSION:3.0 1187 FN:Steve Mansour 1188 N:Mansour;Steve 1189 ORG:Netscape Communications Corporation 1190 ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain 1191 View;CA;94043;USA 1192 TEL;TYPE=WORK,MSG:+1-650-937-2378 1193 TEL;TYPE=WORK,FAX:+1-650-937-2103 1194 EMAIL;TYPE=INTERNET:sman@netscape.com 1195 END:VCARD 1197 BEGIN:VCARD 1198 VERSION:3.0 1199 FN:Peter O'Leary 1200 N:O'Leary;Peter 1201 ORG:Amplitude Software Corp. 1202 ADR;TYPE=WORK,POSTAL,PARCEL:;;185 Berry St. Suite 4700; San 1203 Francisco;CA;94107;USA 1204 TEL;TYPE=WORK,MSG:+1-415-659-3511 1205 TEL;TYPE=WORK,FAX:+1-415-659-0006 1206 EMAIL;TYPE=INTERNET:poleary@amplitude.com 1207 END:VCARD 1209 BEGIN:VCARD 1210 VERSION:3.0 1211 FN:Doug Royer 1212 N:Royer;Doug 1213 ORG:Sun Microsystems 1214 ADR;TYPE=WORK,POSTAL,PARCEL:;;901 San Antonio Road, MS MPK17-105; 1215 Palo Alto;CA;94303;USA 1216 TEL;TYPE=WORK,MSG:+1-650-786-7599 1217 EMAIL;TYPE=INTERNET:doug.royer@sun.com 1218 END:VCARD 1220 This work is part of the Internet Engineering Task Force Calendaring 1221 and scheduling Working Group. The chairmen of that working group are: 1223 BEGIN:VCARD 1224 VERSION:3.0 1226 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1227 23 Expires November 1999 1228 FN:Anik Ganguly 1229 N:Ganguly;Anik 1230 ORG:Open Text, Inc. 1231 ADR;TYPE=WORK,POSTAL,PARCEL:;;38777 West Six Mile Road Suite 101; 1232 Livonia;MI;48152;USA 1233 TEL;TYPE=WORK,MSG:+1-734-542-5955 1234 EMAIL;TYPE=INTERNET:ganguly@acm.org 1235 END:VCARD 1237 BEGIN:VCARD 1238 VERSION:3.0 1239 FN:Robert Moskowitz 1240 N:Moskowitz;Robert 1241 EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com 1242 END:VCARD 1244 9. Full Copyright Statement 1246 Copyright (C) The Internet Society (1998). All Rights Reserved. 1248 This document and translations of it may be copied and furnished to 1249 others, and derivative works that comment on or otherwise explain it 1250 or assist in its implementation may be prepared, copied, published 1251 and distributed, in whole or in part, without restriction of any 1252 kind, provided that the above copyright notice and this paragraph are 1253 included on all such copies and derivative works. However, this 1254 document itself may not be modified in any way, such as by removing 1255 the copyright notice or references to the Internet Society or other 1256 Internet organizations, except as needed for the purpose of 1257 developing Internet standards in which case the procedures for 1258 copyrights defined in the Internet Standards process MUST be 1259 followed, or as required to translate it into languages other than 1260 English. 1262 The limited permissions granted above are perpetual and will not be 1263 revoked by the Internet Society or its successors or assigns. 1265 This document and the information contained herein is provided on an 1266 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1267 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1268 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1269 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1270 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1272 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1273 24 Expires November 1999