idnits 2.17.1 draft-ietf-calsch-capreq-02.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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 62 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 38: '...rements that CAP MUST address in order...' RFC 2119 keyword, line 108: '...rements that CAP MUST address in order...' RFC 2119 keyword, line 157: '...example, "events MUST be scheduled in ...' RFC 2119 keyword, line 271: '...AP data elements MUST be based on the ...' RFC 2119 keyword, line 276: '... 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 18, 1998) is 9290 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 1103 looks like a reference -- Missing reference section? 'ITIP' on line 1107 looks like a reference -- Missing reference section? 'IMIP' on line 1111 looks like a reference -- Missing reference section? 'RFC1738' on line 258 looks like a reference -- Missing reference section? 'IRIP' on line 1114 looks like a reference Summary: 9 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 18, 1998 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 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or made obsolete by 21 other documents at any time. It is not appropriate to use Internet- 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 27 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Distribution of this document is unlimited. 33 Abstract 35 The Calendar Access Protocol (CAP) is an Internet protocol for 36 accessing an [ICAL] based calendar store (CS) from a calendar user 37 agent (CUA). The purpose of this document is to set forth a list of 38 requirements that CAP MUST address in order to meet the needs of the 39 calendaring and scheduling community. 41 This document is based on discussions within the Internet Engineering 42 Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. 43 More information about the IETF CALSCH working group activities can 44 be found on the IMC web site at http://www.imc.org, the IETF web site 45 at http://www.ietf.org/html.charters/calsch-charter.html. Refer to 46 the references within this document for further information on how to 47 access these various documents. 49 Distribution of this document is unlimited. Comments and suggestions 50 for improvement should be sent to the authors. 52 Copyright (C) The Internet Society 1998. All Rights Reserved. 54 Change History 56 Version 00 - Initial draft. 58 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 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 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 67 Table of Contents 68 1. Introduction........................................................4 69 2. Terminology.........................................................4 70 3. Relationship To iCalendar, iTIP and iMIP/iRIP.......................7 71 4. Requirements........................................................7 72 4.1 Basic Usage ......................................................7 73 4.2 Infrastructure ...................................................8 74 4.2.1 Connection Models .............................................8 75 4.2.2 Store Location Models .........................................9 76 4.2.3 Calendar Stores ..............................................10 77 4.2.4 Exception Reporting ..........................................11 78 4.3 Operations on a Calendar ........................................11 79 4.3.1 Deferred Requirements for Operations on a Calendar ...........12 80 4.4 Component Management ............................................12 81 4.4.1 Recurrence ...................................................13 82 4.4.2 Calendar and Component Policies ..............................14 83 4.4.3 Deferred Requirements for Component Management ...............14 84 4.5 Lookup, Query and Discovery .....................................15 85 4.5.1 Lookup .......................................................15 86 4.5.2 Query Capabilities ...........................................15 87 4.5.3 Specific Queries .............................................17 88 4.5.4 Discovery ....................................................17 89 4.5.5 Deferred Requirements for Search .............................18 90 4.6 Security ........................................................18 91 4.7 Designates and Delegation .......................................18 92 4.8 Notification (deferred) .........................................19 93 4.9 Access Control (deferred) .......................................19 94 4.10 Resource Groups and Pools (deferred) ...........................20 95 4.11 CAP Non-requirements ...........................................21 96 5. Open Issues........................................................21 97 6. Acknowledgments....................................................22 98 7. Bibliography.......................................................22 99 8. Authors' Address...................................................22 100 9. Full Copyright Statement...........................................24 102 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 103 1. Introduction 105 The Calendar Access Protocol (CAP) is an Internet protocol for 106 accessing an [ICAL] based calendar store (CS) from a calendar user 107 agent (CUA). The purpose of this document is to set forth a list of 108 requirements that CAP MUST address in order to meet the needs of the 109 calendaring and scheduling community. 111 2. Terminology 113 The terminology used in [ICAL], [ITIP] and [IMIP] are also used 114 within this memo. 116 Calendar 117 A collection of logically related objects or entities each of 118 which may be associated with a calendar date and possibly time of 119 day. These entities can include other calendar properties or 120 calendar components. In addition, a calendar might be 121 hierarchically structured and consist of other sub-calendars. The 122 [ICAL] defines calendar properties, calendar components and 123 component properties. A calendar is identified by its unique 124 calendar identifier. 126 Calendar Access Protocol 127 An Internet protocol that allows a CUA to access and operate on a 128 CS. 130 Calendar Access Rights 131 Some method for specifying permitted operational capabilities for 132 a calendar user. 134 Calendar Component 135 An entity within a calendar. Types of calendar components include 136 events, to-dos, journals, alarms, time zones and freebusy data. A 137 calendar component consists of component properties and possibly 138 other sub-components. For example, an event can consist of an 139 alarm component. 141 Calendar Component Properties 142 An attribute of a particular calendar component. Some calendar 143 component properties are applicable to different types of 144 calendar components. For example, DTSTART is applicable to 145 VEVENT, VTODO, VJOURNAL calendar components. Other calendar 146 components are applicable only to an individual type of calendar 147 component. For example, TZURL is only applicable to VTIMEZONE 148 calendar components. 150 Calendar Identifier 151 Also known as "CalID". A globally unique identifier associated 152 with a calendar within a CS. 154 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 155 Calendar Policy 156 An operational restriction on the access or manipulation of a 157 calendar. For example, "events MUST be scheduled in unit 158 intervals of one hour". 160 Calendar Properties 161 An attribute of a calendar. The attibute applies to the calendar, 162 as a whole. For example, CALSCALE specifies the calendar scale 163 (e.g., GREGORIAN) for the whole calendar. 165 Calendar Service 166 An implementation of an application that manages one or more 167 calendars. 169 Calendar Store 170 Also known as "CS". The data model definition for a Calendar 171 Service. 173 Calendar Store Identifier 174 Also known as "CSID". The identifier for an individual calendar 175 store. A CSID consists of the user, password, host and port 176 portions of a "Common Internet Scheme Syntax" part of a URL, as 177 defined by [RFC1738]. 179 Calendar Store Components 180 Components maintained in a Calendar Store that are not part of 181 any calendar. 183 Calendar Store Properties 184 Properties maintained in a Calendar Store that are not part of 185 any calendar. 187 Calendar User 188 The entity that is associated with the credentials presented by 189 the Calendar User Agent to the Calendar Store. 191 Calendar User Agent 192 Also known as "CUA". The CUA is the software client operated by 193 the calendar user. 195 Calendaring and Scheduling System 196 The computer sub-system that provides the services for accessing, 197 manipulating calendars and scheduling calendar components. 199 Connected Mode 200 A mobile computing mode where the CUA is directly connected to 201 the calendar store. 203 Delegate 204 Is a calendar user (sometimes called the delegatee) who has been 205 assigned participation in a scheduled calendar component (e.g., 206 VEVENT) by one of the attendees in the scheduled calendar 207 component (sometimes called the delegator). An example of a 208 delegate is a team member told to go to a particular meeting. 210 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 211 Designate 212 Is a calendar user who is authorized to act on behalf of another 213 calendar user. An example of a designate is an assistant. 215 Disconnected Mode 216 A mobile computing mode where a CUA can be disconnected from a 217 calendar store. When the CUA is disconnected, it is in the 218 disconnected mode. 220 Fan Out 221 The process by which a calendar store forwards scheduling 222 operations to the attendees not associated with the current 223 calendar. 225 Hierarchical Calendars 226 A CS feature where calendars may contain sub-calendars. The top- 227 most calendar in a hierarchy of calendars is called the root 228 calendar. There may be multiple root calendars in a single CS. 229 Within a hierarchy of calendars, all sub-calendars have a 230 calendar with a parent topographical relationship. In addition, 231 sub-calendars may have sub-calendars (child topographical 232 relationship). In addition, the sub-calendar may have one or more 233 calendars with a sibling topographical relationship. 235 High Bandwidth Connection 236 A communications connection supporting high transfer rates; 237 transfer rates commonly found within a LAN. 239 Local Store 240 A store which is on the same hardware as the CUA. 242 Low Bandwidth Connection 243 A communications connection supporting slow transfer rates; 244 transfer rates commonly found in modem technology. 246 Relative Calendar Identifier 247 Also known as "Relative CalID". A relative identifier for an 248 individual calendar in a calendar store. A Relative CalID 249 consists of the portion of the "scheme part" of a Qualified 250 CalID, following the Calendar Store Identifier. This is the same 251 as the "URL path" of the "Common Internet Scheme Syntax" portion 252 of a URL, as defined by [RFC1738]. 254 Qualified Calendar Identifier 255 Also known as "Qualified CalID". A complete Internet identifier 256 for a specific calendar. A Qualified CalID consists of a CAP 257 specific "scheme" and "scheme part" portion of a URL, as defined 258 in [RFC1738]. A Qualified CalID are written only with the graphic 259 printable characters of the US-ASCII coded character set. 261 Remote Store 262 A store which is not on the same hardware as the CUA. 264 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 265 Sub-calendars 266 Calendars that are contained within other calendars in a 267 hierarchical relationship. 269 3. Relationship To iCalendar, iTIP and iMIP/iRIP 271 The CAP data elements MUST be based on the calendar architecture set 272 forth in [ICAL]. More precisely, CAP will define an Internet protocol 273 for accessing a CS that consists of one or more calendars, each 274 consisting of numerous [ICAL] components. The definition of CAP might 275 necessitate adding components, properties, parameters and other 276 elements beyond those defined in [ICAL]. These additions MUST be 277 defined in a manner consistent with and upwards compatible to the 278 data model defined by [ICAL]. 280 Where it makes practical sense, CAP SHOULD make use of the scheduling 281 workflow defined by [ITIP]. 283 CAP will not require that [IMIP] or [IRIP] MUST be used to 284 communicate with other calendar users. 286 4. Requirements 288 4.1 Basic Usage 290 CAP MUST specify: 292 - How to provide a standard protocol to allow a CUA to 293 interoperate with a CS. 295 - Using only CAP, a CUA MUST be able to access and manipulate a 296 calendar. CAP MUST provide the complete, if minimal, functionality 297 that allows a CUA to access a calendar. 299 - How to allow a CUA to be developed independently of a CS and a 300 CS independently of a CUA. 302 - How to allow an organization to have a mixture of CUAs and CSs 303 from different vendors. With CAP, any CUA in the organization MUST 304 be able to interoperate with any CS. 306 - How to allow for a single CUA to access multiple CSs or 307 calendars. 309 For example, a CUA MUST be able to create calendar components on 310 multiple calendars and/or retrieve calendar components from 311 multiple calendars. 313 - How to allow for a rich featured CUA. 315 For example, allow a CUA to be part of a client which offers 316 rich calendaring, scheduling and related functionality, with the 317 possibility of extending from concepts and services offered by 318 CAP, while still using CAP to access a calendar. 320 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 321 - How to extend the base features in CAP. 323 - How to allow for interpersonal applications to be calendar 324 enabled. 326 For example, a chat application MUST be able to offer a calendar 327 button to create an event between the two or more parties. 329 - How to allow for non-interpersonal applications to be calendar 330 enabled. 332 For example, a reservation system MUST be able to retrieve and 333 update calendar components from a calendar. Other examples of 334 non-interpersonal applications include event planning, resource 335 scheduling, and Human Asset Management (HAM). 337 - How to allow for CUAs without local store and with minimal 338 memory. 340 For example, a cell phone MUST be able to act as a CUA. 342 - How to allow for CUAs with local store that can be kept 343 synchronized with the remote store. 345 For example, a robust featured application might act as a CUA 346 and also provide extra functionality using the local store. 348 - How to allow for CUAs over disconnected, low-bandwidth 349 connections. 351 For example, a PDA MUST be able to act as a CUA and interoperate 352 with a CS over a low-bandwidth wireless connection. 354 - How to allow for CUAs over high bandwidth connections. 356 For example, a PC MUST be able to act as a CUA and interoperate 357 with a CS over a high-speed Ethernet connection. 359 4.2 Infrastructure 361 This section defines a set of infrastructure requirements for CAP. 363 4.2.1 Connection Models 365 CAP MUST support a number of CUA-to-CS connection models. In 366 particular, CAP MUST allow connected and disconnected operation. 368 CUAs and CSs often support the "connected model", where clients 369 maintain long-term connections to servers. Because of this, CAP MUST 370 specify how the connection between a CUA and a CS can be maintained. 372 CAP MUST NOT prevent servers from dropping client connections, 373 particularly idle client connections. CAP MUST provide some ways for 374 clients to indicate that they would like to stay connected, or that 376 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 377 they would like to drop the connection after the current 378 request/response. These requirements are open issues. 380 4.2.2 Store Location Models 382 CAP MUST allow CUAs with local stores and CUAs without local stores. 384 SINGLE REMOTE CS 386 CAP MUST support the store location model where a CUA needs to 387 retrieve everything from a single remote CS. In this model, the CUA 388 does not have a local CS. Instead, a single CS resides remotely and 389 is accessed through CAP. The client MUST always establish the CAP 390 connection in order to function. 392 MULTIPLE REMOTE CS 394 CAP MUST support the model where a CUA has no local CS, but needs to 395 retrieve everything from multiple remote CS. In this model, the CUA 396 does not have any local CS. Instead, multiple CSs reside remotely and 397 are accessed through CAP. The client MUST always establish one or 398 more CAP connections in order to function. 400 SINGLE LOCAL, SINGLE REMOTE CS 402 CAP MUST support the model where a CUA can retrieve everything from 403 the local store and periodically synchronize the local store with a 404 single remote CS. When there is no CAP connection, the CUA can still 405 function. When the CAP connection is re-established, the CUA can 406 update the remote CS with information modified on the local CS while 407 it was disconnected. In addition, the CUA can update its single local 408 CS with information that was modified on the remote CS while the CUA 409 was disconnected. 411 SINGLE LOCAL, MULTIPLE REMOTE CS 413 CAP MUST support the model where a CUA can retrieve everything from a 414 local CS and periodically synchronize with multiple remote CS. When 415 the CAP connection is not established, the CUA can still function. 416 When the CUA re-establishes a connection with each remote CS, it can 417 update the remote CS with information modified while disconnected. In 418 addition, the CUA can update the single local CS with information 419 that was modified on remote CS while the CUA was disconnected. 421 MULTIPLE LOCAL, MULTIPLE REMOTE CS 423 CAP MUST support the model where a CUA can retrieve everything from 424 multiple local CS and periodically synchronize them with multiple 425 remote CS. When a CAP connection is not established, the CUA can 426 still function. When the CUA re-establishes a connection with each 427 remote CS, it can update the remote CS with information modified 428 while disconnected. In addition, the CS associated with the CAP 429 connection can update any of the local CS with information that was 431 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 432 modified while it was disconnected from the remote CS. Multiple local 433 and remote CS can be updated in sequence. 435 When remote and local CSs are involved, it MUST be possible to 436 identify conflicts between the local and remote CSs. It is the 437 responsibility of the CUA to resolve conflicts. 439 "Modified information" includes new, changed and deleted components, 440 as well as properties on calendars and components. 442 4.2.3 Calendar Stores 444 The diagram below describes the data objects maintained in a CS. CAP 445 defines how data in the CS is manipulated. The data consists of: 447 - Calendar Store properties, e.g. local time zone 449 - Calendars, e.g. a user's calendar 451 - Calendar properties, e.g. a user name 453 - Calendar components, e.g. an iCAL VEVENT 455 - Component properties, e.g. DTSTART on a VEVENT 457 - Property attributes, e.g. TZID on DTSTART 459 - Access control rights (deferred) 461 A calendar may contain other calendars to form a hierarchy. Every 462 calendar has its own properties. 464 CAP does not define users. CAP does not define any default or implied 465 relationship between a user and a calendar. Users, via a CUA, 466 authenticate themselves to a CS to access information. All access is 467 subject to access control. 469 Editor Note: Insert calendar store diagram here. In the interim 470 refer to http://www.imc.org/ietf-calendar/csmodel.jpg 472 Calendars are always referenced by their CalIDs. Open issue: whether 473 calendars can also be referenced by their hierarchical name. 475 CalIDs are used in all operations 477 Attendees values can be Qualified CalIDs of varying schemes. For 478 example: 480 ATTENDEE[...]:mailto:a@example.com 481 ATTENDEE[...]:irip://cal-1.example.com/b 482 ATTENDEE[...]:cap://calendar.example.com/c 484 Editor Note: The MAILTO URL is illustrating an "iMIP" URL. 486 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 487 CAP MUST provide a way for the CUA to determine whether or not the CS 488 supports optional or varying capabilities. For example: 490 - Is a particular optional feature (like fan out, or calendar 491 access rights) supported? 493 - Determine what, if any, limitation the CS imposes on unbounded 494 recurrence rules. 496 - Provide a way for the CUA to determine what, if any, limitations 497 the CS imposes on date/time values. For example, there may be dates 498 in the past and future beyond which the CS cannot represent. 500 4.2.4 Exception Reporting 502 The granularity of exception report can be at the level of the 503 calendar, the calendar component, component property, or property 504 attribute as appropriate. 506 CAP MUST provide a way to determine the results of delayed 507 operations. Delayed operations arise from the use of other protocols 508 (IMIP, IRIP), which may take a long time to resolve. Delayed 509 operations have a return code and may have associated calendar data. 510 As an example, an ITIP request for free/busy information may result 511 in the delivery of a VFREEBUSY component. A CUA MUST be able to use 512 CAP to retrieve the VFREEBUSY component. If the operation failed, the 513 CUA MUST be able to determine the reply code. It is an open issue 514 whether CAP MUST support delayed operations and what that means, and 515 how results are returned. 517 4.3 Operations on a Calendar 519 A calendar is assumed to reside on a CS. CAP MUST specify: 521 - How a CUA can create a calendar or sub-calendar. 523 For example, sub-calendars might be used to organize calendar 524 information based on criteria defined by the CUA. 526 - How a CUA can rename a calendar or sub-calendar. 528 For example, the CUA may decide to change the name of a calendar 529 after the calendar has been created. 531 - How a CUA can delete a calendar or sub-calendar. 533 When deleting a calendar, all sub-calendars of the calendar MUST 534 be deleted. This is an open issue. 536 - A CUA can delete a calendar regardless of whether or not the 537 calendar has any entities in it. 539 - A CUA can set and retrieve properties of a calendar or sub- 540 calendar on a CS. 542 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 543 This should include the ability to set and retrieve standard and 544 custom properties, the time zone of a calendar, and the 545 operational hours of a calendar. 547 For example, the CUA may want to schedule an event based on the 548 operational hours of a calendar. 550 4.3.1 Deferred Requirements for Operations on a Calendar 552 CAP is not required to specify: 554 - How to copy a calendar on a CS or between CSs. 556 - How a group operations on a set of calendars. 558 - How to undelete a calendar. 560 - Auto processing on scheduled components in a calendar that need 561 action. 563 For example, if someone tries to create a meeting on a calendar 564 for a user who is on vacation, the CS may automatically delegate 565 the meeting to another user. 567 4.4 Component Management 569 CAP MUST specify, subject to access control: 571 - How the CUA can create a component (event/to-do/journal) on a 572 calendar (direct booking) 574 - How the CUA can create a component on another user's calendar 576 This capability permits the CUA to create calendar components on 577 another calendar, other than their own, but does not necessarily 578 give them the capability to read or modify calendar components. 580 - How the CUA can modify a component on a given calendar 582 - How the CUA can delete a component from one or more calendars 584 - The requirement to delete from multiple calendars might be met 585 with separate requests. 587 - How the CUA can modify, add or delete an arbitrary component 588 property within a specified calendar. 590 For example, modify the SUMMARY property on a calendar 591 component. 593 - How the CUA can modify a parameter of a multi-valued component 594 property within a specified calendar. 596 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 597 For example, modify the PARTSTAT parameter on an ATTENDEE 598 property associated with a particular attendee on a calendar 599 component. 601 - How the CUA can add or modify attachment properties on a 602 specified component. 604 The attachments may be large, and the CUA ought not have to 605 resend the entire component. 607 - How the CUA can send an attachment to the CS. 609 The attachment would be appended to a particular component. 611 - How the CUA can remove a specified attachment from the CS and 612 its property from the specified component. 614 - How hierarchical name can be used for all operations. 616 This requirement indicates that any calendaring or scheduling 617 operation performed on a component or calendar by specifying the 618 UID or CSID, MUST also be available by specifying the 619 hierarchical name. The two exceptions are the request for the 620 hierarchical name given the UID or vice versa. 622 Open Issue: This is still open to discussion. 624 CAP MUST also allow the CUA to do synchronization of two calendars to 625 which it has access. 627 4.4.1 Recurrence 629 CAP MUST specify, subject to access control: 631 - How the CUA can retrieve or delete a calendar component based on 632 the UID, and an optional RECURRENCE-ID. 634 For example, retrieve the single instance of a recurring meeting 635 by specifying both the UID for the recurring meeting and the 636 RECURRENCE-ID of the instance. 638 - How the CUA can modify or delete an instance of a recurring 639 component, or all recurrences. 641 - How the CUA can modify all instances of a recurring component 642 that occur before a specified date, or after a particular date. 644 Open issue: whether the following requirements related to expansion 645 of recurrence are deferred. 647 - How the CUA can request the CS to send down components with or 648 without expansion of recurring calendar components. 650 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 651 - CAP MUST permit the CS to refuse this request, so that if the CS 652 normally provides expansions of recurring calendar components, it 653 can refuse the request to not expand. However, the CS MUST 654 terminate the expansion eventually. 656 - How the CUA can find out, and perhaps change, the length of time 657 for which recurring calendar components are expanded. 659 - How the CUA can retrieve, and perhaps set, the period for or 660 number of recurrences expanded on a recurring component. 662 This could be 0, infinity, a specific DTEND, or a consistent 663 length of time from "today" into the future. 665 4.4.2 Calendar and Component Policies 667 CAP MUST specify: 669 - How the CUA tells the CS to prevent conflicts (double booking) 670 on a calendar 672 The scenario is that a calendar could be marked for "allow no 673 conflicts", and the CS would automatically prevent this. This 674 might apply to direct booking or scheduling or both. 676 - How operational hours for a calendar are enforced 678 Each calendar MUST have a property for operational hours, and 679 CAP MUST specify how the CUA tells the CS to enforce those 680 operational hours. This means that the CS prevents components 681 from being added in a manner that violates the operational hours 682 set by the user. CAP MUST specify how policy enforcement can be 683 overridden by the owner of the calendar. CAP MUST specify 684 whether this includes alarms. This might apply to direct booking 685 or scheduling or both. 687 Open issue: Whether the ability to set a policy of turning down 688 requests that exceed a maximum duration (or length of time between 689 DTSTART and DTEND) is a requirement. 691 4.4.3 Deferred Requirements for Component Management 693 CAP is not required to specify: 695 - Undelete and purge deleted calendar entries. 697 - Modify inline attachment to URL; provide URL to fetch. 699 - Merge or aggregate more than one calendar. 701 - Lock access to calendar. 703 - Delayed or asynchronous transactions. 705 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 706 - The CUA requesting a size limit before retrieving components 707 from the CS. The CS might send partial components if the 708 component's size exceeded the limit. CAP would permdit the CS to 709 refuse the request or give its preferred value. 711 - The CS synchronizing 2 calendars. 713 - How the CUA tells the CS to prevent conflicts with respect to an 714 individual component in the calendar. The scenario for this is that 715 a component could be marked for "allow no conflicts", and the CS 716 would automatically prevent a new component from being added in a 717 way which would cause a conflict. This might apply to either direct 718 booking or scheduling or both. 720 - How the CUA can create multiple entries on many CSs. 722 This may occur in one or more operations, perhaps using 723 different calendar protocols (CAP, iRIP, iMIP). 725 4.5 Lookup, Query and Discovery 727 Lookup includes the capability to list things. Querying enables 728 searching and filtering features. Discovery covers requests for 729 information such as what features are supported by the CS. 731 4.5.1 Lookup 733 CAP MUST specify, subject to access control: 735 - How the CUA can list calendars in a single CS, by fetching all 736 the top level CSIDs of the CS. 738 - How the CUA can list all the sub-calendars within a given 739 calendar. 741 - How the CUA can list all component UIDs in a calendar. 743 - How the CUA can retrieve all the free/busy data for a calendar. 745 - How the CUA can retrieve a list of properties for a component or 746 a set of components. 748 For this requirement, the set of components is defined either as 749 all the components in a calendar, or where the set of components 750 is defined by a search query (search query requirements are 751 elaborated in the Query Capabilities section). For example, the 752 CUA could ask for the DTSTART, DTEND and SUMMARY properties for 753 all components with DTSTART later than 9:00 p.m. today. 755 4.5.2 Query Capabilities 757 CAP MUST allow the CUA to retrieve CalIDs, component UIDs or 758 component hierarchical names (open issue) from a given calendar, 759 using queries which specify: 761 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 762 - How the CUA can retrieve data from multiple calendars. 764 This requirement allows the CUA to display multiple calendars to 765 the user. This requirement does not constrain this functionality 766 to a single request as it may be done in multiple requests. 768 - How the CUA to retrieve any named property for a calendar or 769 component. 771 For example, the CUA can retrieve the SUMMARY property for a 772 given component. 774 - Property value equivalence query (e.g., equal to) 776 For example, such as matching the organizer with a specified 777 user, or matching the location with a particular conference 778 room. This should work for all properties. 780 - Pattern-matching string comparison query (e.g., contains) 782 The pattern-matching query MUST be applied to a string property 783 such as a "name" property. The response MUST include a list of 784 calendar (or component) identifiers and MAY include property 785 values for those items. The CUA MUST be able to request which 786 properties (or the entire component) to retrieve. 788 - Property value comparison query (e.g., greater than, less than) 790 This requirement includes only those properties for which a 791 comparison query is possible. This list of properties MUST 792 include DTSTART, DTEND, DURATION. For example, this allows the 793 CUA to ask for all components that begin later than (greater 794 than) the specified time. 796 This requirement MUST be met in a way which allows the CUA to 797 discover which alarms will trigger in a given period. 799 - Multiple property value comparisons combined using Boolean 800 elements (e.g., logical and, logical or, negatation). 802 The CUA MUST be able to discover which components have durations 803 which occur at least partially in a given range of time, either 804 by retrieving the list of UIDs or by retrieving all of the 805 components properties. This requirement allows the CUA to 806 discover all components during a particular day or other time 807 period. This includes instantaneous and all-day calendar items. 808 This requirement does not state that the components MUST be 809 retrieved in their entirety in the same interaction as the 810 query; the query and the component retrieval can be separate 811 interactions between the CUA and the CS. 813 CAP MUST allow synchronization, meaning at a minimum that the CUA is 814 able to find and retrieve new, modified or deleted entries for a 815 given time period. The CUA MUST be able to find out which entries 817 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 818 have been added, modified or deleted since it last synchronized, in 819 order to operate in disconnected mode. This requirement may be 820 satisfied using the query requirements already defined. 822 4.5.3 Specific Queries 824 These are specific scenarios required by calendaring operations which 825 may require special attention to ensure that they can be done with 826 the querying and lookup functionality of CAP. 828 CAP MUST allow, subject to access control: 830 - The CUA to retrieve the CSID for a calendar specified by giving 831 its hierarchical name, and vice versa. 833 This requirement means that hierarchical calendar names MUST be 834 unique on the CS. 836 Open Issue: This is an open issue. 838 - The CUA to discover conflicts given a list of calendars and a 839 time period 841 This feature is to allow the CUA to schedule a group of 842 attendees for a meeting at a particular time; the CUA MUST be 843 able to find out if those attendees are free at that time. This 844 requirement does not specify whether the discovery is done 845 mainly on the CS or on the CUA. For example, the CUA could ask 846 for the free/busy data for each calendar during the period and 847 then determine conflicts itself, or the CUA could ask the CS 848 which attendees have conflicts during the period. Either 849 approach would satisfy this requirement. 851 - The CUA to discover which calendar components need action. 853 iCalendar entries which need action include scheduled components 854 that have not yet been accepted or declined. The CUA needs to 855 know this list in order to present the items to the user to 856 resolve them. 858 4.5.4 Discovery 860 CAP MUST specify: 862 - How the CUA can query the calendar components which are 863 supported on a named calendar. 865 - How the CUA can query the names of all properties which exist on 866 a given calendar, or the properties which exist on a given 867 component. 869 - How the CUA can query the names of component properties 870 supported by a CS. 872 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 873 - How the CUA can query the time zones supported by the CS 875 4.5.5 Deferred Requirements for Search 877 CAP is not required to specify: 879 - How to roll up free/busy information for a number of calendars 880 (perhaps sub-calendars) into a single free/busy component. 882 - How to fetch all components marked for deletion in a certain 883 range. This could include components somehow marked for deletion 884 but not yet purged from the CS. 886 - How the CUA can determine whether the CS supports multiple 887 reads/writes in the same operation. 889 This would include, for example, the ability to name a number of 890 calendars to add a component to in a single operation 892 4.6 Security 894 CAP MUST specify: 896 - How the CUA authenticates itself to the CS (not the calendar). 898 Authentication to the CS is required for all access to the CS. 899 The CS MUST be able to uniquely identify each user for the 900 purposes of authentication and authorization. 902 - How anonymous access to calendars is specified (if allowed). 904 - How the CUA authenticates to CS using SASL. 906 - How the CUA and the CS negotiate encryption mechanism for a 907 secure connection. 909 - How calendars can be made secure from unwanted access and false 910 entries. 912 - How the CUA and CS can specify denial of service to another 913 calendar user. 915 4.7 Designates and Delegation 917 CAP MUST specify, subject to access control: 919 - How a list of designates is created. 921 - How the CS knows that a user is a valid designate, through 922 authentication or some other mechanism. 924 - How the CUA can delegate to another calendar user. 926 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 927 4.8 Notification (deferred) 929 There are no notification features that are required in CAP. 930 Notification is deemed not to be a requirement, because: 932 - A CUA can poll the CS for new/changed/deleted components, 933 including new ITIP messages. This functionality is needed to 934 support synchronization. 936 - A CUA can handle alarms on components itself. 938 The notification features that were considered but have been deferred 939 include: 941 - Notify the CUA when a change is made to a calendar. 943 - Notify the CUA when an alarm triggers. 945 - Notify the CUA when a calendar component NEEDS-ACTION. 947 - Notify when a CUA attempts to access a calendar, delete, modify, 948 or add a calendar component. 950 4.9 Access Control (deferred) 952 The ability to get and set access control data on calendars and 953 calendar components is useful, but beyond the scope of the initial 954 CAP specification. A CS may apply access control entries to calendars 955 and components, but CAP need not specify how these are to be set and 956 retrieved. Access control entries could be set and retrieved by 957 administrators on the CS through another protocol. Additionally, a CS 958 can enforce the class of each component, by restricting access to 959 "confidential" and "private" components, without any design in CAP to 960 allow this. 962 Access control requirements that were considered but have been 963 deferred include: 965 - CUA query the calendar access rights for the currently 966 authenticated calendar user. 968 - CUA grant/deny designate rights to a given calendar user. 970 - CUA removes OR denies all rights to a given calendar for given 971 calendar users. 973 - CUA grants free/busy view rights on a given calendar to a 974 calendar user. 976 - CUA grants full access rights on a given calendar to a calendar 977 user. 979 - CS performs calendar access rights inheritance on sub-calendars. 981 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 982 - CUA grants/denies access rights to individual properties of 983 individual components. 985 For example, user A can see subject of event B, or user A can 986 set time of event B. 988 - CUA can set operation limits for user A on calendar B. 990 For example: 992 - (a) set time limit C on events for user D can schedule on my 993 calendar, 995 - (b) set limit number of events by user E, or 997 - (c) grant limited access on a calendar such that a user F can 998 only create events during specified hours. 1000 4.10 Resource Groups and Pools (deferred) 1002 A specification for how to handle resource groups and pools is not a 1003 requirement. These kinds of features will be addressed in a separate, 1004 later draft. 1006 A group has a list of members, all of whom should be included in any 1007 scheduled calendar component. For example, a group could contain a 1008 particular conference room and a particular projector, both of which 1009 should be scheduled for a meeting. Or a group could contain a number 1010 of people working together, all of whom should be scheduled for group 1011 meetings. When a group is included as an attendee, the CS MUST 1012 schedule each of the members of the group. 1014 A pool has a list of members, all of which are identical for the 1015 purposes of scheduling, and only one of them should be scheduled. 1016 When a pool is included as an attendee, the CS MUST schedule the 1017 number of them that was requested. For example, a pool could contain 1018 a number of VCRs, any of which can be scheduled for meetings, when 1019 only one VCR is usually needed. 1021 Resource group and pool features that were considered but were 1022 deferred include: 1024 - CUA can create a list of CSIDs which is a group or pool. 1026 - CUA can request to add a component to every calendar for every 1027 CSID in a group 1029 - CUA can send a single schedule request to the CS, where the 1030 attendee list includes a group. The CS then fans out the request. 1031 Fanning out might be achieved by forwarding the request to all 1032 members of a group, or by placing the request on the calendar of 1033 every member of the group. The members of the group may be on 1034 multiple CSs. 1036 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1037 - CUA can schedule one CSID by scheduling one instance from a 1038 pool. 1040 - Each group/pool itself has properties. 1042 - Access restrictions can be set on a group/pool, to restrict who 1043 can get/set properties and who can schedule the group/pool. 1045 4.11 CAP Non-requirements 1047 CAP is not required to be: 1049 - A client-to-client protocol. 1051 - A server-to-server protocol. 1053 For example, it would not specify how server-to-server updates 1054 of calendaring or scheduling operations are accomplished. 1056 The initial version of CAP is not required to specify: 1058 - How to do a full administration CUA, e.g., add user, delete 1059 user, move user, archive calendar, delete user, change 1060 user/calendar name. 1062 - Inheritance of calendar access rights, property values, etc. 1064 5. Open Issues 1066 Open issues include the following: 1068 - Whether CAP should specify how clients can request their 1069 connections to be kept open, and whether servers can drop 1070 connections at any time. 1072 - Whether calendars can also be referenced by their hierarchical 1073 name. 1075 - Is a particular optional feature (like fan-out, or calendar 1076 access rights) supported? 1078 - Determine what, if any, limitation the CS imposes on unbounded 1079 recurrence rules. 1081 - Whether CAP MUST support delayed operations and what that means, 1082 and how results are returned. 1084 - Whether all sub-calendars of a deleted calendar MUST be deleted. 1086 - Whether the ability to set a policy of turning down requests 1087 that exceed a maximum duration is a requirement. 1089 - Whether expansion of recurrences is required. 1091 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1092 - Whether or not CAP operations support bounding the latency of 1093 responses to operations. 1095 6. Acknowledgments 1097 The following have provided input in the drafting of this memo: 1099 Lisa Lippert, Surendra Reddy, Richard Shusterman. 1101 7. Bibliography 1103 [ICAL] "Internet Calendaring and Scheduling Core Object Specification 1104 - iCalendar", RFC 2445, November 1998, 1105 http://www.ietf.org/rfc/rfc2445.txt. 1107 [ITIP] "iCalendar Transport-Independent Interoperability Protocol 1108 (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", 1109 RFC 2446, November 1998, http://www.ietf.org/rfc/rfc2446.txt. 1111 [IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), RFC 1112 2447, November 1998, http://www.ietf.org/rfc/rfc2447.txt. 1114 [IRIP] "iCalendar Message-based Interoperability Protocol (iRIP), 1115 Internet-Draft, November 1998, , ftp://ftp.ietf.org/internet- 1116 drafts/draft-ietf-calsch-irip-02.txt. 1118 8. Authors' Address 1120 The following address information is provided in a vCard v2.1, 1121 Electronic Business Card, format. 1123 BEGIN:VCARD 1124 VERSION:3.0 1125 FN:Andre Courtemanche 1126 N:Courtemanche;Andre 1127 ORG:CS&T 1128 ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 1129 3L5;Canada 1130 TEL;TYPE=WORK,MSG:+1-514-733-8500 1131 TEL;TYPE=WORK,FAX:+1-514-733-8788 1132 EMAIL;TYPE=INTERNET:andre@cst.ca 1133 END:VCARD 1135 BEGIN:VCARD 1136 VERSION:3.0 1137 FN:Frank Dawson 1138 N:Dawson;Frank 1139 ORG:Lotus Development Corporation 1140 ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; Raleigh; 1141 NC;27613-3502;USA 1142 TEL;TYPE=WORK,MSG:+1-617-693-8728 1143 TEL;TYPE=WORK,FAX:+1-617-693-5552 1144 EMAIL;TYPE=INTERNET:Frank_Dawson@Lotus.com 1145 URL:http://home.earthlink.net/~fdawson 1147 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1148 END:VCARD 1150 BEGIN:VCARD 1151 VERSION:3.0 1152 FN:Tony Small 1153 N:Small;Tony 1154 ORG:Microsoft Corporation 1155 ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; Redmond;WA; 1156 98052-6399;USA 1157 TEL;TYPE=WORK,MSG:+1-206-703-2190 1158 TEL;TYPE=WORK,FAX:+1-206-936-7329 1159 EMAIL;TYPE=INTERNET:tonysm@Microsoft.com 1160 END:VCARD 1162 BEGIN:VCARD 1163 VERSION:3.0 1164 FN:Steve Mansour 1165 N:Mansour;Steve 1166 ORG:Netscape Communications Corporation 1167 ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain 1168 View;CA;94043;USA 1169 TEL;TYPE=WORK,MSG:+1-650-937-2378 1170 TEL;TYPE=WORK,FAX:+1-650-937-2103 1171 EMAIL;TYPE=INTERNET:sman@netscape.com 1172 END:VCARD 1174 BEGIN:VCARD 1175 VERSION:3.0 1176 FN:Peter O'Leary 1177 N:O'Leary;Peter 1178 ORG:Amplitude Software Corp. 1179 ADR;TYPE=WORK,POSTAL,PARCEL:;;185 Berry St. Suite 4700; San 1180 Francisco;CA;94107;USA 1181 TEL;TYPE=WORK,MSG:+1-415-659-3511 1182 TEL;TYPE=WORK,FAX:+1-415-659-0006 1183 EMAIL;TYPE=INTERNET:poleary@amplitude.com 1184 END:VCARD 1186 BEGIN:VCARD 1187 VERSION:3.0 1188 FN:Doug Royer 1189 N:Royer;Doug 1190 ORG:Sun Microsystems 1191 ADR;TYPE=WORK,POSTAL,PARCEL:;;901 San Antonio Road, MS MPK17-105; 1192 Palo Alto;CA;94303;USA 1193 TEL;TYPE=WORK,MSG:+1-650-786-7599 1194 EMAIL;TYPE=INTERNET:doug.royer@sun.com 1195 END:VCARD 1197 This work is part of the Internet Engineering Task Force Calendaring 1198 and scheduling Working Group. The chairmen of that working group are: 1200 BEGIN:VCARD 1201 VERSION:3.0 1203 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small 1204 FN:Anik Ganguly 1205 N:Ganguly;Anik 1206 ORG:Open Text, Inc. 1207 ADR;TYPE=WORK,POSTAL,PARCEL:;;38777 West Six Mile Road Suite 101; 1208 Livonia;MI;48152;USA 1209 TEL;TYPE=WORK,MSG:+1-734-542-5955 1210 EMAIL;TYPE=INTERNET:ganguly@acm.org 1211 END:VCARD 1213 BEGIN:VCARD 1214 VERSION:3.0 1215 FN:Robert Moskowitz 1216 N:Moskowitz;Robert 1217 EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com 1218 END:VCARD 1220 9. Full Copyright Statement 1222 Copyright (C) The Internet Society (1998). All Rights Reserved. 1224 This document and translations of it may be copied and furnished to 1225 others, and derivative works that comment on or otherwise explain it 1226 or assist in its implementation may be prepared, copied, published 1227 and distributed, in whole or in part, without restriction of any 1228 kind, provided that the above copyright notice and this paragraph are 1229 included on all such copies and derivative works. However, this 1230 document itself may not be modified in any way, such as by removing 1231 the copyright notice or references to the Internet Society or other 1232 Internet organizations, except as needed for the purpose of 1233 developing Internet standards in which case the procedures for 1234 copyrights defined in the Internet Standards process MUST be 1235 followed, or as required to translate it into languages other than 1236 English. 1238 The limited permissions granted above are perpetual and will not be 1239 revoked by the Internet Society or its successors or assigns. 1241 This document and the information contained herein is provided on an 1242 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1243 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1244 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1245 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1246 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1248 Courtemanche,Dawson,Mansour,O'Leary,Royer,Small