idnits 2.17.1 draft-ietf-calsch-cap-06.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 77 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There is 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 293: '...example, "events MUST be scheduled in ...' RFC 2119 keyword, line 400: '...flict, the Realm SHOULD be postfixed w...' RFC 2119 keyword, line 442: '... MUST never be an e-mail address ...' RFC 2119 keyword, line 587: '...the subject name MUST be an empty sequ...' RFC 2119 keyword, line 588: '...ectAltName extension MUST be critical....' (129 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 444 has weird spacing: '...ists of a Rea...' == Line 445 has weird spacing: '... domain name ...' == Line 446 has weird spacing: '...form it looks...' == Line 472 has weird spacing: '...used to move ...' == Line 2822 has weird spacing: '...et with brave...' == (6 more instances...) -- 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 20, 2001) is 8183 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? '1' on line 55 looks like a reference -- Missing reference section? 'BEEP' on line 4539 looks like a reference -- Missing reference section? 'RFC2119' on line 4560 looks like a reference -- Missing reference section? 'GUIDE' on line 221 looks like a reference -- Missing reference section? 'URL' on line 4564 looks like a reference -- Missing reference section? 'MIME' on line 4545 looks like a reference -- Missing reference section? 'RFC 2459' on line 605 looks like a reference -- Missing reference section? 'BEEPTCP' on line 4542 looks like a reference -- Missing reference section? 'RFC 3087' on line 4549 looks like a reference -- Missing reference section? 'RFC 2392' on line 4552 looks like a reference -- Missing reference section? 'SQL' on line 4579 looks like a reference -- Missing reference section? 'IANA-PROP' on line 1921 looks like a reference -- Missing reference section? 'TLS' on line 4558 looks like a reference -- Missing reference section? 'SASL' on line 4562 looks like a reference -- Missing reference section? 'SQLCOM' on line 4582 looks like a reference -- Missing reference section? 'UNICODE' on line 4586 looks like a reference -- Missing reference section? 'US-ASCII' on line 4592 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Mansour 3 Internet-Draft AOL/Netscape 4 Expires: May 21, 2002 D. Royer 5 INET-Consulting LLC 6 G. Babics 7 Steltor 8 P. Hill 9 Massachusetts Institute of 10 Technology 11 November 20, 2001 13 Calendar Access Protocol (CAP) 14 draft-ietf-calsch-cap-06 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 21, 2002. 39 Copyright Notice 41 Copyright (C) The Internet Society (2001). All Rights Reserved. 43 Abstract 45 The Calendar Access Protocol (CAP) is an Internet protocol that 46 permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) 47 to access an [iCAL] based Calendar Store (CS). This memo defines the 48 CAP specification. 50 The CAP definition is based on requirements identified by the 51 Internet Engineering Task Force (IETF) Calendaring and Scheduling 52 (CALSCH) Working Group. More information about the IETF CALSCH 53 Working Group activities can be found on the IMC web site at 54 http://www.imc.org/ietf-calendar and at the IETF web site at 55 http://www.ietf.org/html.charters/calsch-charter.html[1]. Refer to 56 the references within this memo for further information on how to 57 access these various documents. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1 Formatting Conventions . . . . . . . . . . . . . . . . . 5 63 1.2 Related Documents . . . . . . . . . . . . . . . . . . . 6 64 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . 6 65 2. CAP Design . . . . . . . . . . . . . . . . . . . . . . . 12 66 2.1 System Model . . . . . . . . . . . . . . . . . . . . . . 12 67 2.2 Calendar Store Object Model . . . . . . . . . . . . . . 12 68 2.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 13 69 2.4 Security Model . . . . . . . . . . . . . . . . . . . . . 14 70 2.4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 14 71 2.4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . . . 14 72 2.4.1.2 Anonymous Users and Authentication . . . . . . . . . . . 16 73 2.4.1.3 User Groups . . . . . . . . . . . . . . . . . . . . . . 16 74 2.4.2 Access Rights - Summary . . . . . . . . . . . . . . . . 16 75 2.4.2.1 Calendar Access Right (VCAR) . . . . . . . . . . . . . . 17 76 2.4.2.2 Decreed VCARs . . . . . . . . . . . . . . . . . . . . . 17 77 2.4.3 Inheritance . . . . . . . . . . . . . . . . . . . . . . 18 78 2.4.4 CAP Session Identity . . . . . . . . . . . . . . . . . . 18 79 2.5 Roles . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 2.6 Calendar Addresses . . . . . . . . . . . . . . . . . . . 19 81 2.7 Extensions to iCalendar . . . . . . . . . . . . . . . . 20 82 2.8 Relationship of RFC 2446 (ITIP) to CAP . . . . . . . . . 20 83 3. Protocol Framework . . . . . . . . . . . . . . . . . . . 22 84 3.1 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 22 85 3.2 Use of XML, MIME and iCalendar . . . . . . . . . . . . . 22 86 3.3 Bounded Latency . . . . . . . . . . . . . . . . . . . . 23 87 4. Formal Command Syntax . . . . . . . . . . . . . . . . . 26 88 4.1 Searching and Filtering . . . . . . . . . . . . . . . . 26 89 4.1.1 Grammar For Search Mechanism . . . . . . . . . . . . . . 26 90 4.1.2 SQL-MIN notes . . . . . . . . . . . . . . . . . . . . . 27 91 4.1.3 Querying Experminental Properties . . . . . . . . . . . 28 92 4.1.4 Example, Query by UID . . . . . . . . . . . . . . . . . 28 93 4.1.5 Query by Date-Time range . . . . . . . . . . . . . . . . 29 94 4.1.6 Query for all Non-Booked Entries . . . . . . . . . . . . 29 95 4.1.7 Query with Subset of Properties by Date/Time . . . . . . 29 96 4.1.8 Components With Alarms In A Range . . . . . . . . . . . 30 97 5. Access Rights . . . . . . . . . . . . . . . . . . . . . 31 98 5.1 VCAR Inheritance . . . . . . . . . . . . . . . . . . . . 31 99 5.2 Access Control and NOCONFLICT . . . . . . . . . . . . . 31 100 6. Commands and Responses . . . . . . . . . . . . . . . . . 32 101 6.1 Session Commands . . . . . . . . . . . . . . . . . . . . 32 102 6.1.1 "generate-uid" Command . . . . . . . . . . . . . . . . . 32 103 6.1.2 "get-capability" Command . . . . . . . . . . . . . . . . 33 104 6.1.3 "identify" Command . . . . . . . . . . . . . . . . . . . 35 105 6.1.4 "noop" Command . . . . . . . . . . . . . . . . . . . . . 35 106 6.2 Calendaring and Scheduling Commands . . . . . . . . . . 36 107 6.2.1 Restriction Tables . . . . . . . . . . . . . . . . . . . 36 108 6.2.2 Common Attributes . . . . . . . . . . . . . . . . . . . 37 109 6.2.2.1 "id" Attribute . . . . . . . . . . . . . . . . . . . . . 37 110 6.2.3 Common Elements . . . . . . . . . . . . . . . . . . . . 37 111 6.2.3.1 "data" Element . . . . . . . . . . . . . . . . . . . . . 37 112 6.2.3.2 "select" Element . . . . . . . . . . . . . . . . . . . . 37 113 6.2.3.3 "source" Element . . . . . . . . . . . . . . . . . . . . 39 114 6.2.3.4 "target" Element . . . . . . . . . . . . . . . . . . . . 39 115 6.2.4 Calendaring Commands . . . . . . . . . . . . . . . . . . 40 116 6.2.4.1 "create" Command . . . . . . . . . . . . . . . . . . . . 40 117 6.2.4.2 "delete" Command . . . . . . . . . . . . . . . . . . . . 50 118 6.2.4.3 "modify" Command . . . . . . . . . . . . . . . . . . . . 53 119 6.2.4.4 "move" Command . . . . . . . . . . . . . . . . . . . . . 59 120 6.2.4.5 "search" Command . . . . . . . . . . . . . . . . . . . . 62 121 6.3 Scheduling Commands . . . . . . . . . . . . . . . . . . 72 122 6.3.1 "schedule" Command . . . . . . . . . . . . . . . . . . . 72 123 6.3.2 Processing Scheduling Components . . . . . . . . . . . . 74 124 6.3.3 iTIP Examples . . . . . . . . . . . . . . . . . . . . . 76 125 6.3.3.1 Sending and Receiving an iTIP request . . . . . . . . . 76 126 6.3.3.2 Handling an iTIP refresh . . . . . . . . . . . . . . . . 81 127 6.3.3.3 Sending and accepting an iTIP counter . . . . . . . . . 83 128 6.3.3.4 Declining an iTIP counter . . . . . . . . . . . . . . . 86 129 7. Response Codes . . . . . . . . . . . . . . . . . . . . . 89 130 8. BEEP Profile Registration . . . . . . . . . . . . . . . 91 131 9. CAP DTD . . . . . . . . . . . . . . . . . . . . . . . . 92 132 10. Implementation Issues . . . . . . . . . . . . . . . . . 95 133 11. Properties . . . . . . . . . . . . . . . . . . . . . . . 96 134 11.1 Calendar Store Properties . . . . . . . . . . . . . . . 96 135 11.2 Calendar Properties . . . . . . . . . . . . . . . . . . 97 136 12. CAP Item Registration . . . . . . . . . . . . . . . . . 100 137 12.1 Registration of New and Modified CAP Entities . . . . . 100 138 12.2 Registration of New Entities . . . . . . . . . . . . . . 100 139 12.2.1 Define the Item . . . . . . . . . . . . . . . . . . . . 100 140 12.2.2 Post the item definition . . . . . . . . . . . . . . . . 101 141 12.2.3 Allow a comment period . . . . . . . . . . . . . . . . . 101 142 12.2.4 Submit the proposal for approval . . . . . . . . . . . . 101 143 12.3 Property Change Control . . . . . . . . . . . . . . . . 102 144 13. IANA Considerations . . . . . . . . . . . . . . . . . . 103 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . 103 147 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . 105 148 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . 106 149 Full Copyright Statement . . . . . . . . . . . . . . . . 108 151 1. Introduction 153 This document specifies how a Calendar User Agent (CUA) interacts 154 with a Calendar Store (CS) to manage calendar information. In 155 particular, it specifies how to query, create, modify, and delete 156 iCalendar components (e.g., events, to-dos, or daily journal 157 entries). It further specifies how to search for available busy time 158 information. 160 CAP is specified as a BEEP "profile". As such many aspects of the 161 protocol (e.g., authentication and privacy) are provided within the 162 BEEP core [BEEP]. The protocol data units leverage the standard 163 iCalendar format [iCAL] to convey calendar related information. 165 1.1 Formatting Conventions 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 Calendaring and scheduling roles are referred to in quoted-strings of 172 text with the first character of each word in upper case. For 173 example, "Organizer" refers to a role of a "Calendar User" (CU) 174 within the protocol defined by this memo. Calendar components 175 defined by [iCAL] are referred to with capitalized, quoted-strings of 176 text. All calendar components start with the letter "V". For 177 example, "VEVENT" refers to the event calendar component, "VTODO" 178 refers to the to-do calendar component and "VJOURNAL" refers to the 179 daily journal calendar component. 181 Scheduling methods defined by [iTIP], are referred to with 182 capitalized, quoted-strings of text. For example, "REPLY" refers to 183 the method for replying to a "REQUEST". 185 Calendar commands are referred by lower-case, quotes-strings of text, 186 followed by the word "command". For example, "create" command refers 187 to the command for creating a calendar entry, "search" command refers 188 to the command for reading calendar components. 190 Properties defined by this memo are referred to with capitalized, 191 quoted-strings of text, followed by the word "property". For 192 example, "ATTENDEE" property refers to the iCalendar property used to 193 convey the calendar address of a "Calendar User". Property 194 parameters defined by this memo are referred to with capitalized, 195 quoted-strings of text, followed by the word "parameter". For 196 example, "PARTSTAT" parameter refers to the iCalendar property 197 parameter used to specify the participation status of an attendee. 198 Enumerated values defined by this memo are referred to with 199 capitalized text, either alone or followed by the word "value". 201 In tables, the quoted-string text is specified without quotes in 202 order to minimize the table length. 204 1.2 Related Documents 206 Implementers will need to be familiar with several other memos that, 207 along with this one, describe the Internet calendaring and scheduling 208 standards. These documents are: 210 [iCAL] (RFC2445) which specifies the objects, data types, properties 211 and property parameters used in the protocols, along with the methods 212 for representing and encoding them, 214 [iTIP] (RFC2446) which specifies an interoperability protocol for 215 scheduling between different implementations. The related documents 216 are: 218 [iMIP] (RFC2447) which specifies an Internet email binding for 219 [iTIP]. 221 [GUIDE] (draft/rfc...) which is a guide to implementers and describes 222 the elements of a calendaring system, how they interact with each 223 other, how they interact with end users, and how the standards and 224 protocols are used. 226 This memo does not attempt to repeat the specification of concepts 227 and definitions from these other memos. Where possible, references 228 are made to the memo that provides for the specification of these 229 concepts and definitions. 231 1.3 Definitions 233 Booked 235 An entry in a calendar has one of two conceptual states. It is 236 scheduled or it is booked. A scheduled entry has been stored in 237 the calendar store but has not been acted on by a calendar user 238 (CU) or calendar user agent (CUA). A scheduled entry contains a 239 METHOD property set to an [iTIP] method. A booked entry is a 240 component does not have a METHOD property. 242 Calendar 244 A collection of logically related objects or entities each of 245 which may be associated with a calendar date and possibly time of 246 day. These entities can include other calendar properties or 247 calendar components. In addition, a calendar might be 248 hierarchically related to other sub-calendars. A calendar is 249 identified by its unique calendar identifier. The [iCAL] defines 250 calendar properties, calendar components and component properties 251 that make up the content of a calendar. 253 Calendar Access Protocol (CAP) 255 The standard Internet protocol that permits a Calendar User Agent 256 to access and manipulate calendars residing on a Calendar Store. 258 Calendar Access Rights (CAR) 260 The mechanism for specifying the CAP operations ("ACTION") that a 261 particular calendar user ("UPN") are granted or denied permission 262 to perform on a given calendar object ("OBJECT"). The calendar 263 access rights are specified with the "VCAR" calendar components 264 within a CS and calendar. 266 Calendar Component 268 An object within a calendar or a calendar store (CS). Some types 269 of calendar components include calendars, events, to-dos, 270 journals, alarms, time zones and freebusy data. A calendar 271 component consists of component properties and possibly other sub- 272 components. For example, an event may contain an alarm component. 274 Calendar Component Properties 276 An attribute of a particular calendar component. Some calendar 277 component properties are applicable to different types of calendar 278 components. For example, DTSTART is applicable to VEVENT, VTODO, 279 VJOURNAL calendar components. Other calendar components are 280 applicable only to an individual type of calendar component. For 281 example, TZURL is only applicable to VTIMEZONE calendar 282 components. 284 Calendar Identifier (CalID) 286 A globally unique identifier associated with a calendar. 287 Calendars reside within a CS. See Qualified Calendar Identifier 288 and Relative Calendar Identifier. 290 Calendar Policy 292 A CAP operational restriction on the access or manipulation of a 293 calendar. For example, "events MUST be scheduled in unit 294 intervals of one hour". 296 Calendar Property 298 An attribute of a calendar (VAGENDA). The attribute applies to 299 the calendar, as a whole. For example, CALSCALE specifies the 300 calendar scale (e.g., GREGORIAN) for the whole calendar. 302 Calendar Service 304 An implementation of a Calendar Store that manages one or more 305 calendars. 307 Calendar Store (CS) 309 The data and service model definition for a Calendar Service. 311 Calendar Store Identifier (CSID) 313 The globally unique identifier for an individual CS. A CSID 314 consists of the host and port portions of a "Common Internet 315 Scheme Syntax" part of a URL, as defined by [URL]. 317 Calendar Store Components 319 Components maintained in a CS specify a grouping of calendar 320 store-wide information. 322 Calendar Store Properties 324 Properties maintained in a Calendar Store calendar store-wide 325 information. 327 Calendar User (CU) 329 An entity (often biological) that uses a calendaring system. 331 Calendar User Agent (CUA) 333 The CUA is the client application that a CU utilizes to access and 334 manipulate a calendar. 336 CAP Session 338 An open communication channel between a CUA and a Calendar 339 Service. 341 Delegate 343 A calendar user (sometimes called the delegatee) who has been 344 assigned participation in a scheduled calendar component (e.g., 345 VEVENT) by one of the attendees in the scheduled calendar 346 component (sometimes called the delegator). An example of a 347 delegate is a team member told to go to a particular meeting. 349 Designate 351 A calendar user who is authorized to act on behalf of another 352 calendar user. An example of a designate is an assistant. 354 Fan Out 356 The calendaring and scheduling process by which a calendar 357 operation on one calendar is also performed on every other 358 calendar specified in the operation. 360 Hierarchical Calendars 362 A CS feature where a calendar has a hierarchical relationship with 363 another calendar in the CS. The top-most calendars in the 364 hierarchical relationship have the CS as their parent. There may 365 be multiple top-most calendars in a given CS. Within a given 366 hierarchical relationship, all sub-calendars have a calendar with 367 a "parent" relationship. In addition, sub-calendars may have a 368 relationship with another calendar that has a "child" 369 relationship. The hierarchical calendar feature is not a storage 370 relationship of the calendars within the CS. Instead it is a 371 feature that relates access control rights to calendar content 372 between different calendars in the CS. The hierarchical 373 relationship of a calendar is specified in the "PARENT" and 374 "CHILDREN" calendar properties. 376 Overlapped Booking 378 A policy which indicates whether or not OPAQUE events can overlap 379 one another. When the policy is applied to a calendar it 380 indicates whether or not the time span of any entry (VEVENT, 381 VTODO, ...) in the calendar can overlap the time span of any other 382 entry in the same calendar. When applied to an individual entry, 383 it indicates whether or not any other entry's time span can 384 overlap that individual entry. 386 Owner 388 One or more CUs or UGs that have "OWNER" calendar access rights 389 for a calendar. The owner is specified in the "OWNER" calendar 390 property. 392 Qualified Calendar Identifier (Qualified CalID) 394 A CalID where both the and are present. 396 Realm 398 A collection of calendar user accounts, identified by a string. 399 The name of the Realm is only used in UPNs. In order to avoid 400 namespace conflict, the Realm SHOULD be postfixed with an 401 appropriate DNS domain name. (e.g., the foobar Realm could be 402 called foobar.example.com). 404 Relative Calendar Identifier (Relative CalID) 406 An identifier for an individual calendar in a calendar store. It 407 is unique within a calendar store. It is recommended to be 408 globally unique. A Relative CalID consists of the portion of the 409 "scheme part" of a Qualified CalID following the Calendar Store 410 Identifier. This is the same as the "URL path" of the "Common 411 Internet Scheme Syntax" portion of a URL, as defined by [URL]. 413 Session Identity 415 A UPN associated with a CAP session. A session gains an identity 416 after successful authentication. The identity is used in 417 combination with CAR to determine access to data in the CS. 419 Sub-calendars 421 Calendars that have a "child" hierarchical relationship with 422 another calendar, its "parent". 424 User Group (UG) 426 A collection of Calendar Users and/or User Groups. These groups 427 are expanded by the CS and may reside either locally or in an 428 external database or directory. The group membership may be fixed 429 or dynamic over time. 431 Username 433 A name which denotes a Calendar User within a Realm. This is part 434 of a UPN. 436 User Principal Name (UPN) 438 A unique identifier that denotes a CU or a group of CU. A UPN is 439 a RFC 822 compliant email address, with exceptions listed below, 440 and in most cases it is deliverable to the CU. In some cases it 441 is identical to the CU's well known email address. A CU's UPN 442 MUST never be an e-mail address that is deliverable to a different 443 person as there is no requirement that a person's UPN must be his 444 e-mail address. It consists of a Realm in the form of a valid, 445 and unique, DNS domain name and a unique Username. In it's 446 simplest form it looks like "user@example.com". 448 In certain cases a UPN will not be RFC 822 compliant. When 449 anonymous authentication is used, or anonymous authorization is 450 being defined, the special UPN "@" will be used. When 451 authentication must be used, but unique identity must be obscured, 452 a UPN of the form @DNS-domain-name may be used. For example, 453 "@example.com". Usage of these special cases is further discussed 454 in the authentication and authorization sections of this document. 456 2. CAP Design 458 2.1 System Model 460 The system model describes the high level components of a calendar 461 system and how they interact with each other. 463 CAP is used by a "Calendar User Agent" (CUA) to send commands to and 464 receive responses from a "Calendar Service". 466 The CUA prepares a [MIME] encapsulated command, sends it to the CS, 467 and receives a [MIME] encapsulated response. The calendaring related 468 information within these messages are represented by iCalendar 469 objects. 471 There are two distinct protocols in operation to accomplish this 472 exchange. [BEEP] is used to move these encapsulations between a CUA 473 and a CS. The CAP profile defines the content and semantics of the 474 messages sent between the CUA and the Calendar Service. 476 2.2 Calendar Store Object Model 478 The conceptual model for a calendar store is shown below. The 479 calendar store contains VCARs, VQUERYs, VTIMEZONEs, VAGENDAs and 480 calendar store properties. 482 Calendars (VAGENDAs) contain VEVENTs, VTODOs, VJOURNALs, VCARs, 483 VTIMEZONEs, VQUERYs and calendar properties. Calendars may also 484 contain other calendars (VAGENDAs). 486 Calendar Store 487 | 488 +-- VCARs 489 +-- VQUERYs 490 +-- VTIMEZONEs 491 +-- VAGENDA 492 | | 493 | +--VEVENTs 494 | | | 495 | | +--VALARMs 496 | +--VTODOs 497 | | | 498 | | +--VALARMs 499 | +--VJOURNALs 500 | +--VCARs 501 | +--VTIMEZONEs 502 | +--VQUERYs 503 | +--VAGENDAs 504 | | | 505 | | +--VEVENTs 506 | | | | 507 | | | +--VALARMs 508 | | +--VTODOs 509 | | | | 510 | | | +--VALARMs 511 | | +--VJOURNALs 512 | | +--VCARs 513 | | +--VTIMEZONEs 514 | | +--VQUERYs 515 | | +--VFREEBUSY 516 | | +--VAGENDAs 517 | | | | 518 | | | ... 520 Calendars within a Calendar Store are identified by their Relative 521 CALID. 523 In this model, VSCHEDULE is a set of scheduling messages that have 524 not yet been applied to the calendar. Components in VSCHEDULE are 525 discussed in more detail below. 527 2.3 Protocol Model 529 The commands listed below are used to manipulate the data on the 530 calendar store. Their usage and semantics are defined in Section 6. 532 CAP Commands 533 ----------------------------------------------------------- 534 Command Description 535 ----------------------------------------------------------- 536 create Create a new calendar component. 537 delete Delete calendar components. 538 generate-uid Generate one or more unique ids. 539 get-capability Query the capabilities of the CS. 540 identify Set a new identity for calendar access. 541 modify Modify calendar components. 542 move Move calendar components to another container. 543 noop Do nothing. 544 schedule Add an [iTIP] object to the VSCHEDULE set. 545 search Search for calendar components. 546 ----------------------------------------------------------- 548 2.4 Security Model 550 2.4.1 Calendar User and UPNs 552 A Calendar User (CU) is an entity that can be authenticated. It is 553 represented in CAP as a UPN, which is the subject of access rights. 554 The UPN representation is independent of the authentication mechanism 555 used during a particular CUA/CS interaction. This is because UPNs 556 are used within VCARs. If the UPN were dependent on the 557 authentication mechanism, a VCAR could not be consistently evaluated. 558 A CU may use one mechanism while using one CUA but the same CU may 559 use a different authentication mechanism when using a different CUA, 560 or while connecting from a different location. 562 The user may also have multiple UPNs for various purposes. 564 Note that the immutability of the user's UPN may be achieved by using 565 SASL's authorization identity feature. (The transmitted 566 authorization identity may be different than the identity in the 567 client's authentication credentials.) [SASL, section 3]. This also 568 permits a CU to authenticate using their own credentials, yet request 569 the access privileges of the identity for which they are proxying 570 SASL. Also, the form of authentication identity supplied by a 571 service like TLS may not correspond to the UPNs used to express a 572 server's access rights, requiring a server specific mapping to be 573 done. The method by which a server determines a UPN, based on the 574 authentication credentials supplied by a client, is implementation 575 specific. 577 2.4.1.1 UPNs and Certificates 579 When using X.509 certificates for purposes of CAP authentication, the 580 UPN should appear in the certificate. Unfortunately there is no 581 single correct guideline for which field should contain the UPN. 583 From RFC-2459, section 4.1.2.6 (Subject): 585 If subject naming information is present only in the subjectAlt- 586 Name extension (e.g., a key bound only to an email address or 587 URI), then the subject name MUST be an empty sequence and the 588 subjectAltName extension MUST be critical. 590 Implementations of this specification MAY use these comparison 591 rules to process unfamiliar attribute types (i.e., for name 592 chaining). This allows implementations to process certificates 593 with unfamiliar attributes in the subject name. 595 In addition, legacy implementations exist where an RFC 822 name is 596 embedded in the subject distinguished name as an EmailAddress 597 attribute. The attribute value for EmailAddress is of type 598 IA5String to permit inclusion of the character '@', which is not 599 part of the PrintableString character set. EmailAddress attribute 600 values are not case sensitive (e.g., "fanfeedback@redsox.com" is 601 the same as "FANFEEDBACK@REDSOX.COM"). 603 Conforming implementations generating new certificates with 604 electronic mail addresses MUST use the rfc822Name in the subject 605 alternative name field (see sec. 4.2.1.7 of [RFC 2459]) to 606 describe such identities. Simultaneous inclusion of the 607 EmailAddress attribute in the subject distinguished name to 608 support legacy implementations is deprecated but permitted. 610 Since no single method of including the UPN in the certificate will 611 work in all cases, CAP implementations MUST support the ability to 612 configure what the mapping will be by the CS administrator. 613 Implementations MAY support multiple mapping definitions, for 614 example, the UPN may be found in either the subject alternative name 615 field, or the UPN may be embedded in the subject distinguished name 616 as an EmailAddress attribute. 618 Note: If a CS or CUA is validating data received via iMIP, if the 619 "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe 620 Random User:MAILTO:juser@example.com" then the email address should 621 be checked against the UPN, and the CN should also be checked. This 622 is so the "ATTENDEE" property cannot be changed to something 623 misleading like "ATTENDEE;CN=Joe Rictus 624 User:MAILTO:juser@example.com" and have it pass validation. This 625 validation will also defeat other attempts at confusion. 627 2.4.1.2 Anonymous Users and Authentication 629 Anonymous access is often desirable. For example an organization may 630 publish calendar information that does not require any access control 631 for viewing or login. Conversely, a user may wish to view 632 unrestricted calendar information without revealing their identity. 634 2.4.1.3 User Groups 636 A User Group is used to represent a collection of CUs or other UGs 637 that can be referenced in VCARs. A UG is represented in CAP as a 638 UPN. The CUA cannot distinguish between a UPN that represents a CU 639 or a UG. 641 UGs are expanded as necessary by the CS. The CS MAY expand a UG 642 (including nested UGs) to obtain a list of unique CUs. Duplicate 643 UPNs are filtered during expansion. 645 The CS should not preserve UG expansions across operations. A UG may 646 reference a static list of members, or it may represent a dynamic 647 list. Each operation SHOULD generate its own expansion in order to 648 recognize changes to UG membership. 650 CAP does not define commands or methods for managing UGs. 652 2.4.2 Access Rights - Summary 654 Access rights are used to grant or deny access to a calendar for a 655 CU. CAP defines a new component type called a Calendar Access Right 656 (VCAR). Specifically, a VCAR grants, or denies, UPNs the right to 657 read and write components, properties, and parameters on calendars 658 within a CS. 660 The VCAR model does not put any restriction on the sequence in which 661 the object and access rights are created. That is, an event 662 associated with a particular VCAR might be created before or after 663 the actual VCAR is defined. In addition, the VCAR and VEVENT 664 definition might be created in the same iCalendar object and passed 665 together in a single command. 667 All rights MUST be denied unless specifically granted; individual 668 VCARs MUST be specifically granted to an authenticated CU. 670 The access for a particular UPN is the union of all grants for that 671 UPN minus the union of its denies. 673 2.4.2.1 Calendar Access Right (VCAR) 675 Access rights within CAP are specified with the "VCAR" calendar 676 component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" 677 component properties. 679 Properties within an iCalendar object are unordered. This also is 680 the case for the "GRANT", "DENY" and "CARID" properties. Likewise, 681 there is no implied ordering required for components of a "RIGHTS" 682 value type other than that specified by the ABNF. [EDITOR'S NOTE, 683 this requires a lot of review. We think that this paragraph may be 684 incorrect.] 686 For details on the VCAR syntax please see section 688 2.4.2.2 Decreed VCARs 690 A CS MAY choose to implement and allow persistent immutable VCARs, 691 that are configured by the CS administrator, which apply to all 692 calendars on the server. 694 When a user attempts to modify or override a decreed VCAR an error 695 will be returned, indicating that the user has insufficient 696 authorization to perform the operation. 698 The CAP protocol does not define the semantics used to initially 699 create a decreed VCAR. This administrative task is outside the scope 700 of the CAP protocol. 702 For example an implementation or a CS administrator may wish to 703 define a VCAR that will always allow the calendar owners to have full 704 access to their own calendars. The GRANT property allows the OWNERs 705 all (OBJECT=*) access to their own calendar objects. The DENY 706 property disallows anyone (UPN=*) from being able to delete or modify 707 this VCAR. 709 BEGIN:VCAR 710 CARID:Users Default Access 711 GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* 712 DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; 713 VALUE="Users Default Access" 714 ;OBJECT=METHOD,VALUE=DELETE,MODIFY 715 END:VCAR 717 Decreed VCARs MUST be readable by the calendar owner in standard VCAR 718 format. 720 2.4.3 Inheritance 722 Calendars inherit VCARs from their parent calendar. Calendars whose 723 parent is the Calendar Store inherit VCARs from the Calendar Store. 725 VCARs specified in a calendar or a sub-calendar override all 726 inherited VCARs. 728 2.4.4 CAP Session Identity 730 A BEEP session has an associated set of authentication credentials, 731 from which is derived a UPN. This UPN is the identity of the CAP 732 session, and is used to determine access rights for the session. 734 The CUA may change the identity of a CAP session by calling the 735 "identify" command. The Calendar Service only permits the operation 736 if the session's authentication credentials are good for the 737 requested identity. The method of checking this permission is 738 implementation dependent, but may be thought of as a mapping from 739 authentication credentials to UPNs. The "identify" command allows a 740 single set of authentication credentials to choose from multiple 741 identities, and allows multiple sets of authentication credentials to 742 assume the same identity. 744 For anonymous access the identity of the session is "@", a UPN with a 745 null Username and null Realm. A UPN with a null Username, but non- 746 null Realm, such as "@foo.com" may be used to mean any identity from 747 that Realm, which is useful to grant access rights to all users in a 748 given Realm. A UPN with a non-null Username and null Realm, such as 749 "bob@" could be a security risk and MUST NOT be used. 751 Since the UPN includes Realm information it may be used to govern 752 calendar store access rights across Realms. However, governing 753 access rights across Realms is only useful if login access is 754 available. This could be done through a trusted server relationship 755 or a temporary account. 757 The "identify" command provides for a weak group implementation. By 758 allowing multiple sets of authentication credentials belonging to 759 different users to identify as the same UPN, that UPN essentially 760 identifies a group of people, and may be used for group calendar 761 ownership, or the granting of access rights to a group. 763 2.5 Roles 765 CAP defines methods for managing [iCAL] objects in a Calendar Store 766 and exchanging [iCAL] objects for the purposes of group calendaring 767 and scheduling between "Calendar Users" (CUs) or "User Groups" (UGs). 769 There are two distinct roles taken on by CUs in CAP. The CU who 770 creates an initial event or to-do and invites other CUs as attendees 771 takes on the role of "Organizer". The CUs asked to participate in 772 the event or to-do take on the role of "Attendee". Note that "role" 773 is also a descriptive parameter to the "ATTENDEE" property. Its use 774 is to convey descriptive context to an "Attendee" such as "chair", 775 "REQ-PARTICIPANT" or "NON-PARTICIPANT" and has nothing to do with the 776 scheduling workflow. 778 2.6 Calendar Addresses 780 Calendar addresses are URIs that are modeled after URLs [URL]. CAP 781 uses the following forms of URI. 783 [[]://[:]/] 785 where: 787 is "cap", the protocol described in this memo. 789 is the Calendar Store ID. It is the network address of the 790 computer on which the CAP server is running. 792 is optional. The port must be present in the URL if the 793 CAP server does not listen on the default port number. 795 is an identifier that uniquely identifies the 796 calendar on a particular calendar store. There is no implied 797 structure in a Relative CALID. It is an arbitrary string of 798 printable 7 bit ASCII characters. It may refer to the calendar of 799 a user or of a resource such as a conference room. It MUST be 800 unique within the calendar store. It is recommended that the 801 Relative CALID be globally unique. 803 If the and are present the calendar address is said 804 to be "qualified". Senders are required to supply the 805 portion of the address. A qualified calendar address 806 is required when the of the target calendar address differs 807 from that of the CAP server receiving the command. 809 Examples of CAP URIs: 811 cap://calendar.example.com/user1 812 ://calendar.example.com/user1 813 user1 814 cap://calendar.example.com/conferenceRoomA 815 cap://calendar.example.com/89798-098-zytytasd 817 For a user currently authenticated to a CAP server on 818 calendar.example.com, the first three addresses refer to the same 819 calendar. 821 2.7 Extensions to iCalendar 823 In mapping the calendar query feature, and access rights onto the 824 iCalendar format, several extended iCalendar properties and 825 components are defined by this memo. 827 The search operation makes use of a new component, called VQUERY. 828 The component consists of a set of new properties: QUERY, EXPAND and 829 QUERYNAME, that define a search filter. VQUERY is used by the 830 following CAP commands: "search", "move", "modify" and "delete". 832 Access rights are specified in the new iCalendar VCAR component. 834 Calendar are specified by the new VAGENDA component. 836 2.8 Relationship of RFC 2446 (ITIP) to CAP 838 [iTIP] describes scheduling methods which result in indirect 839 manipulation of calendar components. In CAP, the "schedule" command 840 is used to submit scheduling requests. Other CAP commands such as 841 "create", "delete", "modify" and "move" provide direct manipulation 842 of calendar components. In the CAP calendar store model, scheduling 843 messages are conceptually kept separate from other calendar 844 components. This is modeled with the VSCHEDULE set. Note that this 845 is a conceptual model, the actual storage details are left to 846 implementations. 848 When scheduling is used, the METHOD is saved along with components. 849 A scheduled component becomes a booked component when its METHOD 850 property is removed. For example, a component whose METHOD is 851 "REQUEST" is scheduled. The component becomes booked when the METHOD 852 is removed. 854 Several scheduled entries can be in the CS for the same UID. They 855 are consolidated when booked, or they are removed from the CS. 857 For example, if you were on vacation, you could have a REQUEST to 858 attend a meeting and several updates to that meeting. Your CUA would 859 have to "search" them out of the CS using CAP, process them, 860 determine what the final state of the object from a possible 861 combination of user input and programmed logic. Then the CUA would 862 instruct the CS to "create" a new booked entry or "modify" an 863 existing entry. Finally, the CUA can do a "delete" of all of these 864 now old scheduling requests in the CS. See [iTIP] for details on 865 resolving multiple [iTIP] scheduling entries. 867 3. Protocol Framework 869 CAP uses the BEEP application protocol kernel mapped onto TCP (refer 870 to [BEEP] and [BEEPTCP] for more information). The default port that 871 the Calendar Service listens for connections on is port 5229. 873 3.1 BEEP Exchange Styles 875 [BEEP] defines three styles of message exchange: 877 MSG/ANS,ANS,...,NUL: for one-to-many exchanges. 879 MSG/RPY: for one-to-one exchanges. 881 MSG/ERR: for requests the cannot be processed due to an error. 883 A CAP request, targeted at more than one containers, MUST use a one- 884 to-many exchange, with a distinct answer associated with each target. 885 CAP request targeted at a single container MAY use a one-to-one 886 exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when 887 an error condition prevents the execution of the request on all the 888 targeted calendars. 890 3.2 Use of XML, MIME and iCalendar 892 Each BEEP payload exchanged via CAP consists of an XML document and 893 possibly an arbitrary MIME content. The XML document defines the 894 action to be performed. When needed, the calendaring related data is 895 included in a related MIME part containing an iCalendar object. 897 If only an XML document is sent in the BEEP payload, then the mapping 898 to a BEEP payload is straight-forward, e.g., 900 C: MSG 1 2 . 432 62 901 C: Content-Type: application/beep+xml 902 C: 903 C: 904 C: END 906 Otherwise, arbitrary MIME content is included in the BEEP payload by 907 using a "multipart/related" (see [RFC 3087]), identified using a 908 "cid" URL (see [RFC 2392]), and the XML control document occurs as 909 the starting body part, e.g., 911 C: MSG 1 3 . 1023 951 912 C: Content-Type: multipart/related; boundary="boundary-asdf123"; 913 C: start="<1@cal.example.com>"; 914 C: type="application/beep+xml" 915 C: 916 C: --boundary-asdf123 917 C: Content-Type: application/beep+xml 918 C: Content-ID: <1@cal.example.com> 919 C: 920 C: 921 C: 922 C: 923 C: 924 C: 925 C: 926 C: --boundary-asdf123 927 C: Content-Type: text/calendar 928 C: Content-ID: 2@cal.example.com 929 C: 930 C: BEGIN:VCALENDAR 931 C: METHOD:REQUEST 932 C: BEGIN:VEVENT 933 C: UID:abcd12345 934 C: ORGAGNIZER:cap://cal.example.com/mary-relcalid 935 C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/mary-relcalid 936 C: ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/john-relcalid 937 C: ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/bob-relcalid 938 C: DTSTART:20010920T180000Z 939 C: DTEND:20010920T190000Z 940 C: SUMMARY:Mary invites John and Robert 941 C: END:VEVENT 942 C: END:VCALENDAR 943 C: --boundary-asdf123-- 944 C: END 946 The MIME content-type "application/beep+xml" is defined in Section 947 6.4 of [BEEP]. 949 3.3 Bounded Latency 951 A CUA can associate a maximum latency time to a command with the 952 "max-time" element. If the CS is unable to complete the request in 953 the specified amount of time, then the server sends a "timeout" 954 request to which the CUA MUST respond with a "abort" or "continue" 955 reply. 957 Upon receiving an "abort" reply, the CS MUST terminate the command in 958 progress and return a request-status code 2.0.3. When receiving a 959 "continue" reply the server resumes its work in progress. Note that 960 a new latency time MAY be included in a "continue" reply. 962 The timeout element takes two arguments "latency" and "action". The 963 "latency" argument MUST be set to the maximum latency time in 964 seconds. The "action" argument accepts the following values: "ask" 965 and "abort". If the maximum latency time is exceeded and the 966 "action" argument is set to "ask", then CS MUST send a "timeout" 967 message to inform the CUA, otherwise if the argument "action" is set 968 to "abort" the CS can directly terminate the request and return a 969 request-status code 2.0.3. 971 Example: 973 In this example bill@cal.example.com attempts to read a calendar but 974 the latency time he supplies is not sufficient for the server to 975 complete the command. 977 C: MSG 1 4 . 2043 680 978 C: Content-Type: multipart/related; boundary="boundary-zxy123"; 979 C: start="1@cal.example.com"; 980 C: type="application/beep+xml" 981 C: 982 C: --boundary-zxy123 983 C: Content-Type: application/beep+xml 984 C: Content-ID: 1@cal.example.com 985 C: 986 C: 987 C: 988 C: 992 C: 993 C: --boundary-zxy123 994 C: Content-Type: text/calendar 995 C: Content-ID: 2@cal.example.com 996 C: 997 C: BEGIN:VCALENDAR 998 C: BEGIN:VQUERY 999 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT 1000 C: WHERE DTEND >= '19990714T080000Z' AND 1001 C: DTSTART <= '19990715T080000Z' 1002 C: END:VQUERY 1003 C: END:VCALENDAR 1004 C: --boundary-zxy123-- 1005 C: END 1006 # After 3 seconds 1007 S: MSG 1 2 . 102 64 1008 S: Content-Type: application/beep+xml 1009 S: 1010 S: 1011 S: END 1013 If Bill wants to continue and give the server more time he would 1014 issue a "continue" reply: 1016 C: RPY 1 2 . 166 113 1017 C: Content-Type: application/beep+xml 1018 C: 1019 C: 1020 C: 1021 C: 1022 C: END 1024 If Bill wants to abort the command and not wait any further he would 1025 issue an "abort" reply: 1027 C: RPY 1 2 . 166 62 1028 C: Content-Type: application/beep+xml 1029 C: 1030 C: 1031 C: END 1032 S: RPY 1 4 . 2723 114 1033 S: 1034 S: 1035 S: 1036 S: Request Aborted by the CUA. 1037 S: 1038 S: 1039 S: END 1041 4. Formal Command Syntax 1043 4.1 Searching and Filtering 1045 This section describes CAP's selecting and filtering entities within 1046 a calendar store. It is based on the Standard Query Language (SQL) 1047 defined in [SQL]. 1049 4.1.1 Grammar For Search Mechanism 1051 search = "BEGIN:VQUERY" CRLF 1052 [expand] querycomp 1053 "END:VQUERY" CRLF 1055 expand = "EXPAND" ":" ( "TRUE" / "FALSE") CRLF 1056 # the default is EXPAND:FALSE 1058 comp-name = "VEVENT" / "VTODO" / "VJOURNAL" 1059 / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VAGENDA" 1060 / "VCAR" / iana-name / x-name 1062 querycomp = ( query ) / ( queryname query ) / queryname 1064 queryname = "QUERYNAME:" text 1066 query = "QUERY:" ( query-min / query-92 ) 1067 # 1068 # NOTE: query-min MUST be implemented in CSs. 1069 # 1070 # query-92 is ONLY used if CAPABILITY returns SQL-92 1071 # as the QUERYLEVEL value or if QUERYLEVEL is not 1072 # specified. 1073 # 1075 query-min = capselect-min 1077 capselect-min = "SELECT" capmin-cols "FROM" capmin-comps 1078 "WHERE" capmin-cmp 1080 capmin-col = # Any property name found in any of the 1081 components. 1083 capmin-cols = ( capmin-col / capmin-col "," 1084 capmin-cols ) 1086 capmin-comps = ( comp-name / comp-name "," 1087 compmin-comps ) 1089 capmin-cmp = ( colname capmin-cmp-rhs 1090 / colname capmin-cmp-rhs 1091 capmin-logical capmin-cmp ) 1093 capmin-cmp-rhs = ( capmin-oper colvalue 1094 / "IS" ["NOT"] "NULL" ) 1096 colname = ( # Any valid component property name. 1097 / "*" ) 1099 cmpmin-oper = ( " = " / " != " / " < " / " > " / " <= " 1100 / " >= " ) 1102 capmin-logical = ( " AND " / " OR " ) 1104 query-92 = capselect-92 capfrom-92 capwhere-92 1105 caporderby-92 1107 capselect-92 = # Any valid [SQL] string that goes into 1108 a SELECT clause. 1110 capfrom-92 = # Like capmin-comps except embedded spaces 1111 # are allowed between commas - per [SQL]. 1113 capwhere-92 = # Any valid [SQL] string that goes into a 1114 # WHERE clause. 1116 caporderby-92 = # Any valid [SQL] string that goes into a 1117 # ORDERBY clause. 1119 4.1.2 SQL-MIN notes 1121 (1) No inlined spaces are allowed if not in the grammar above. 1123 (2) Note that cmpmin-oper and capmin-logical elements are 1124 surrounded by exactly one space. 1126 Use 'VEVENT,VTODO', not 'VEVENT, VTODO' 1127 Use 'DTSTART <= 20000605T131313Z', not 1128 'DTSTART <= 20000605T131313Z'. 1129 Use ' AND ' and ' OR ', not 'AND' and not 'OR'. 1131 (3) There is no ORDERBY. Sorting will take place in the order the 1132 columns are supplied in the command. 1134 (4) The CS MUST sort at least the first column. The CS MAY sort 1135 additional columns. 1137 (5) If EXPAND=FALSE and if colname is "*" sorting will be by the 1138 DTSTART value ascending. If EXPAND=TRUE and if colname is "*" 1139 sorting will be by the RECURRENCE-ID value ascending. 1141 If colname is "*" and capmin-coms is VALARM only then sorting will 1142 be by TRIGGER time in UTC ascending. 1144 (6) SQL-MIN MUST be implemented. 1146 4.1.3 Querying Experminental Properties 1148 4.1.4 Example, Query by UID 1150 The following example would match the entire content of the component 1151 with the UID property equal to "uid123" and not expand any multiple 1152 instances of the component. If the CUA does not know if "uid123" was 1153 a VEVENT, VTODO, VJOURNAL, or any other component, then all 1154 components that the CUA supports MUST be supplied on the QUERY 1155 property. This example assumes the CUA only supports VTODO and 1156 VEVENT. 1158 If the results were empty it could also mean that "uid123" was a 1159 property in a component other than a VTODO or VEVENT. 1161 BEGIN:VQUERY 1162 QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123' 1163 END:VQUERY 1165 The following example would match the entire content of the component 1166 with the UID property equal to "uid123" and would expand any 1167 instances of the component after applying any recurrence rules. This 1168 query could select multiple instances of components each with the 1169 same UID. Each instance would have a unique RECURRENCE-ID of the 1170 expanded component. 1172 BEGIN:VQUERY 1173 EXPAND:TRUE 1174 QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123' 1175 END:VQUERY 1177 4.1.5 Query by Date-Time range 1179 This query selects the entire content of every booked VEVENT that has 1180 an instance greater than or equal to July 1st, 2000 00:00:00 UTC and 1181 less than or equal to July 31st, 2000 23:59:59 UTC 1183 BEGIN:VQUERY 1184 EXPAND:TRUE 1185 QUERY:SELECT * FROM VEVENT 1186 WHERE RECURRENCE-ID >= '20000801T000000Z' 1187 AND RECURRENCE-ID <= '20000831T235959Z' 1188 AND METHOD = 'CREATE' 1189 END:VQUERY 1191 4.1.6 Query for all Non-Booked Entries 1193 The following example selects the entire content of all scheduling 1194 VEVENTS in the CS. The default for EXPAND is FALSE, so the 1195 recurrence rules will not be expanded. 1197 BEGIN:VQUERY 1198 QUERY:SELECT * FROM VEVENT,VTODO WHERE METHOD IS NOT NULL 1199 END:VQUERY 1201 The following example fetches the UIDs of all non-booked VEVENTs and 1202 VTODOs. 1204 BEGIN:VQUERY 1205 QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD IS NOT NULL 1206 END:VQUERY 1208 4.1.7 Query with Subset of Properties by Date/Time 1210 In this example only the named properties will be selected and all 1211 booked and non-booked components will be selected that have a DTSTART 1212 from February 1st to February 10th 2000. 1214 BEGIN:VQUERY 1215 QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT 1216 WHERE DTSTART >= '20000201T000000Z' 1217 AND DTSTART <= '20000210T235959Z' 1218 END:VQUERY 1220 4.1.8 Components With Alarms In A Range 1222 This example fetches all components with an alarm that triggers 1223 within the specified time range. In this case only the UID, SUMMARY, 1224 and DESCRIPTION will be selected for all booked VEVENTS that have an 1225 alarm between the two date-times. 1227 BEGIN:VQUERY 1228 EXPAND:TRUE 1229 QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT 1230 WHERE VALARM.TRIGGER >= '20000101T030405Z' 1231 AND VALARM.TRIGGER <= '20001231T235959Z' 1232 AND METHOD = 'CREATE' 1233 END:VQUERY 1235 5. Access Rights 1237 Access rights within CAP are specified with the "VCAR" calendar 1238 component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" 1239 component properties. 1241 Properties within a VCAR must be evaluated in the order provided. 1243 5.1 VCAR Inheritance 1245 Calendar access rights specified in a calendar store are inherited as 1246 default calendar access rights for any calendar in the parent 1247 calendar store. Likewise, any calendar access rights specified in a 1248 root calendar are inherited as default calendar access rights for any 1249 sub-calendar to the root calendar. Furthermore, calendar access 1250 rights specified in a sub-calendar are inherited as default calendar 1251 access rights for any calendars that are hierarchically below the 1252 sub-calendar. 1254 Calendar access rights specified in a calendar override any default 1255 calendar access rights. Calendar access rights specified within a 1256 sub-calendar override any default calendar access rights. 1258 5.2 Access Control and NOCONFLICT 1260 The TRANSP property can take on values (TRANSPARENT-NOCONFLICT, 1261 OPAQUE-NOCONFLICT) that prohibit other events from overlapping it. 1262 This setting overrides access. The ALLOW-CONFLICT Calendar or 1263 component setting may also prevent overlap, returning an error code 1264 "6.3" 1266 6. Commands and Responses 1268 CAP commands and responses are described in this section. 1270 As mentioned in Section 3.2, CAP commands are defined by XML 1271 documents. The syntax of the commands is defined in Section 9, this 1272 section describes their semantic. 1274 The attributes of a command are described in the "Attributes:" 1275 section in the command descriptions below. Similarly the "Elements:" 1276 section describes the elements that compose the command. The 1277 "Response:" section, identifies the responses that may be returned by 1278 the server. 1280 In the examples below, lines preceded with "S:" refer to the server 1281 and lines preceded with "C:" refer to the client. Lines in which the 1282 first non-whitespace character is a "#" are editorial comments and 1283 are not part of the protocol. 1285 6.1 Session Commands 1287 6.1.1 "generate-uid" Command 1289 Attributes: 1291 num: Number of UIDs to generate (1 if omitted). 1293 Response: 1295 "uid-list" 1297 The "generate-uid" command returns one or more unique identifiers 1298 which MUST be unique on the server's calendar store. It is 1299 recommended that the return values be globally unique ids. 1301 Example: 1303 C: MSG 1 5 . 2837 60 1304 C: Content-Type: application/beep+xml 1305 C: 1306 C: 1307 C: END 1308 S: RPY 1 5 . 2897 328 1309 S: Content-Type: application/beep+xml 1310 S: 1311 S: 1312 S: 20011121T120000Z-12340@cal.example.com 1313 S: 20011121T120000Z-12341@cal.example.com 1314 S: 20011121T120000Z-12342@cal.example.com 1315 S: 20011121T120000Z-12343@cal.example.com 1316 S: 20011121T120000Z-12344@cal.example.com 1317 S: 1318 S: END 1320 6.1.2 "get-capability" Command 1322 Attributes: 1324 None 1326 Elements: 1328 None 1330 Response: 1332 "capability" 1334 The "get-capability" command returns information about the Calendar 1335 Service given the current state of the connection with the client. 1336 The values returned may differ depending on current user identify and 1337 the security level of the connection. 1339 Client implementations SHOULD NOT require any capability element 1340 beyond those defined in this specification, and MAY ignore any non- 1341 standard, experimental capability elements. Non-standard 1342 experimental capability elements MUST be prefixed with the text "x-". 1343 The prefix SHOULD also include a vendor identifier. For example, "x- 1344 foo-barcapability", for the non-standard "barcapability" capability 1345 of the vendor "foo". It may return different results depending on 1346 the UPN. 1348 Capability Occurs Description 1349 ------------------------------------------------------- 1350 cap 1 Container for CAP related elements. 1351 version 1+ Version(s) of CAP, MUST include at 1352 least "1.0". 1354 query-level 1+ Indicates level of SQL support. 1355 SQL-MIN or SQL-92. MUST include at 1356 least SQL-MIN. 1357 car 1+ Indicates level of CAR support. 1358 CAR-MIN or CAR-FULL-1. CAR-MIN MUST 1359 be present. 1361 date 0 or 1 1362 max 0 or 1 The datetime value in UTC beyond 1363 which the server cannot accept. If 1364 not specified the default is 1365 99991231T235959Z. 1366 min 0 or 1 The datetime value prior to which 1367 the server cannot accept. If not 1368 specified the default is 1369 00000101T000000Z. 1371 icalendar 1 Container for CAP related elements. 1372 version 1+ Version(s) of iCalendar that is (are) supported. 1373 max-component-size 1374 0 or 1 A positive integer value that specifies 1375 the size of the largest iCalendar object that 1376 the server will accept in bytes. Objects 1377 larger than this will be rejected. 1378 The absence of this attribute indicates 1379 no limit. 1381 itip 1 Container for iTIP related elements. 1382 version 1+ Version(s) of ITIP, MUST include at least 1383 "1.0". 1385 Example: 1387 C: MSG 1 6 . 3225 57 1388 C: Content-Type: application/beep+xml 1389 C: 1390 C: 1391 C: END 1392 S: RPY 1 6 . 3282 423 1393 S: Content-Type: application/beep+xml 1394 S: 1395 S: 1396 S: 1397 S: 1398 S: 2.1 1399 S: 65536 1400 S: 1401 S: 1402 S: 1.0 1403 S: 1404 S: 1405 S: 1.0 1406 S: CAR-MIN 1407 S: SQL-MIN 1408 S: 1409 S: 00000101T000000Z 1410 S: 99991231T235959Z 1411 S: 1412 S: 1413 S: 1414 S: END 1416 6.1.3 "identify" Command 1418 Attribute: 1420 upn: The UPN of the new identify to assume. 1422 Element: 1424 None 1426 Response: 1428 "result" with one of the following request-status codes: 1430 2.0 Successful. 1432 6.4 Identity not permitted. 1434 The "identify" command allows the CUA to set a new identity to be 1435 used for calendar access. 1437 The CS determines through an internal mechanism if the credentials 1438 supplied at authentication permit the assumption of the selected 1439 identity. If they do, the session assumes the new identity, 1440 otherwise a security error is returned. 1442 6.1.4 "noop" Command 1444 Arguments: 1446 None 1448 Element: 1450 None 1452 Response: 1454 "result" with the following request-status code: 1456 2.0 successful 1458 This command does nothing. It can be sent to the server periodically 1459 to request that the CS does not time out the session. 1461 [EDITORS NOTE: should an unauthenticated and unidentified client be 1462 able to issue this command?] 1464 [EDITORS NOTE: in view of the integration with BEEP should "noop" be 1465 removed?] 1467 Example: 1469 C: MSG 1 7 . 3705 47 1470 C: Content-Type: application/beep+xml 1471 C: 1472 C: 1473 C: END 1474 S: RPY 1 7 . 3752 91 1475 S: Content-Type: application/beep+xml 1476 S: 1477 S: 1478 S: 1479 S: 1480 S: END 1482 6.2 Calendaring and Scheduling Commands 1484 6.2.1 Restriction Tables 1486 Calendaring data are sent encapsulated in iCalendar objects (see 1487 Section 6.2.3.1). The restriction tables listed in the commands 1488 below describe the composition of the iCalendar data for these 1489 commands and replies. 1491 The presence column uses the following values to assert whether a 1492 property is required, is optional and the number of times it may 1493 appear in the iCalendar object. A comment may be provided to further 1494 clarify the presence criteria. 1496 The table below defines the values for the presence column. 1498 Presence 1499 Value Description 1500 -------------------------------------------------------------- 1501 1 One instance MUST be present 1502 1+ At least one instance MUST be present 1503 0 Instances of this property MUST NOT be present 1504 0+ Multiple instances MAY be present 1505 0 or 1 Up to 1 instance of this property MAY be present 1506 -------------------------------------------------------------- 1508 While the tables list every component and property, their purpose is 1509 not to define the meaning of the component or property. 1511 6.2.2 Common Attributes 1513 6.2.2.1 "id" Attribute 1515 The "id" attribute is an optional identifier for the command. When 1516 specified, the CS will include this attribute in all the related 1517 messages it returns to the client. 1519 The "id" attribute is mainly useful for the "timeout" message (see 1520 Section 3.3). The CAP server imposes no restriction on the value. 1521 If uniqueness is required, then it is the responsibility of the CUA 1522 to generate unique values. 1524 6.2.3 Common Elements 1526 6.2.3.1 "data" Element 1528 The role of the "data" element is to join an iCalendar document to an 1529 XML document forming a CAP command or response. The "data" element 1530 is composed of a single attribute ("content") that MUST be set to a 1531 "cid" URL that refers to an iCalendar document. See Section 3.2 for 1532 more information. 1534 Depending of the context, the content of the referred iCalendar 1535 object is subject to restrictions. See Section 6.2.1 for more 1536 details. 1538 6.2.3.2 "select" Element 1540 Many calendaring commands can target several components stored on the 1541 CS (e.g., "search", "delete", "modify" and "move"). The "select" 1542 element is used to identify the targeted components. 1544 The "select" element is composed of the following: 1546 A "data" element that MUST refer to a VQUERY component. 1548 One or more "source" elements that identify the containers to 1549 consider. 1551 Restriction Table for the "data" element: 1553 Component/Property Presence Comment 1554 ------------------- -------- --------------------------- 1555 VCALENDAR 1 1556 . VERSION 1 MUST be 2.1 1557 . [IANA-PROP] 0+ any IANA registered 1558 property 1560 . VQUERY 1 1561 . . EXPAND 0 or 1 1562 . . QUERYNAME 0 or 1 MUST be present if QUERY is absent. 1563 . . QUERY 0 or 1 MUST be present if QUERYNAME is absent. 1564 . . [IANA-PROP] 0+ any IANA registered 1565 property 1567 . VTIMEZONE 0+ MUST be present if any 1568 date/time refers 1569 to a timezone 1570 . . DAYLIGHT 0+ MUST be one or more of 1571 either STANDARD 1572 or DAYLIGHT 1573 . . . . COMMENT 0 or 1 1574 . . . . DTSTART 1 1575 . . . . RDATE 0+ if present RRULE MUST NOT 1576 be present 1577 . . . . RRULE 0+ if present RDATE MUST NOT 1579 be present 1580 . . . . TZNAME 0 or 1 1581 . . . . TZOFFSET 1 1582 . . . . TZOFFSETFROM 1 1583 . . . . TZOFFSETTO 1 1584 . . . . X-PROPERTY 0+ 1585 . . . . [IANA-PROP] 0+ any IANA registered 1586 property 1587 . . LAST-MODIFIED 0 or 1 1588 . . STANDARD 0+ 1589 . . . . COMMENT 0 or 1 1590 . . . . DTSTART 1 1591 . . . . RDATE 0+ if present RRULE MUST NOT 1592 be present 1593 . . . . RRULE 0+ if present RDATE MUST NOT 1594 be present 1595 . . . . TZNAME 0 or 1 1596 . . . . TZOFFSETFROM 1 1597 . . . . TZOFFSETTO 1 1598 . . . . X-PROPERTY 0+ 1599 . . . . [IANA-PROP] 0+ any IANA registered 1600 property 1601 . . TZID 1 1602 . . TZURL 0 or 1 1603 . . X-PROPERTY 0+ 1604 . . [IANA-PROP] 0+ any IANA registered 1606 6.2.3.3 "source" Element 1608 The "source" element is used to specify container(s) that will be 1609 examined during the execution of a CAP command. The "source" element 1610 is similar to the "target" element (see Section 6.2.3.4, but can 1611 refer to several containers (e.g., a calendar hierarchy or all the 1612 calendar owned by a given CU). 1614 Attributes: 1616 csid: when specified MUST point to a CSID. When omitted the CSID 1617 of the current server is assumed. 1619 relcalid: when specified MUST point to a RELCALID. The value is 1620 relative the value of the "csid" attribute. 1622 depth: specifies the maximal depth of the calendar hierarchy to 1623 explore. When omitted the value "0" is assumed. The accepted 1624 values are positives integers and "*". 1626 owner: if present MUST be set to a UPN. When specified only the 1627 VAGENDA owned by the given UPN are considered. 1629 6.2.3.4 "target" Element 1631 The "target" element is used to specify a container targeted by a CAP 1632 command (e.g., the destination of a "create" command). A "target" 1633 element MAY refer to a VAGENGA or the top level container of a 1634 Calendar Store. 1636 Attributes: 1638 csid: when specified MUST point to a CSID. When omitted the CSID 1639 of the current server is assumed. 1641 relcalid: when specified MUST point to a RELCALID. The value is 1642 relative the value of the "csid" attribute. 1644 6.2.4 Calendaring Commands 1646 Calendaring commands allow a CUA to directly manipulate a calendar. 1648 Calendar access rights can be granted for the more generalized access 1649 provided by the calendar commands. 1651 6.2.4.1 "create" Command 1653 Attributes: 1655 "id" (see Section 6.2.2.1). 1657 Elements: 1659 "max-time": See Section 3.3. 1661 "target": Each "target" element points to a container where the 1662 new component will be created. 1664 "data": MUST point to an iCalendar object defining the 1665 component(s) to create. See the restriction table given below. 1667 Response: 1669 One "result" message per "target" element MUST be returned (see 1670 Section 3.1). 1672 One of the following "request-status" codes MUST be returned: 1674 2.0 - successfully created the component or calendar 1676 6.1 - Container not found 1678 6.3 - Bad args 1680 The "data" element of each "result" message is subject to the 1681 result restriction table defined below. 1683 The "create" command is used to create one or more iCalendar objects. 1684 The "target" elements specify the containers where the component(s) 1685 will be created. 1687 Restriction table for the "data" element of the "create" command: 1689 Component/Property Presence Comment 1690 ------------------- -------- ----------------------------- 1691 VCALENDAR 1 1692 . VERSION 1 MUST be 2.1 1693 . [IANA-PROP] 0+ any IANA registered 1694 property 1696 . VAGENDA 0+ 1697 . . CALMASTER 0 or 1 1698 . . NAME 0 or 1 1699 . . OWNER 1+ 1700 . . RELCALID 1 1701 . . TZID 0 or 1 1702 . . [IANA-PROP] 0+ any IANA registered 1703 property 1705 . VCAR 0+ 1706 . . CARID 0 or 1 1707 . . DENY 0+ Note, there must be at 1708 least one GRANT or DENY 1709 within the VCAR. 1710 . . GRANT 0+ Note, there must be at 1711 least one GRANT or DENY 1712 within the VCAR. 1713 . . [IANA-PROP] 0+ any IANA registered 1714 property 1716 . VQUERY 0+ 1717 . . EXPAND 0 or 1 1718 . . QUERYNAME 1 1719 . . QUERY 1 1720 . . [IANA-PROP] 0+ any IANA registered 1721 property 1723 . VEVENT 0+ 1724 . . ATTENDEE 0+ 1725 . . SEQUENCE 0 or 1 MUST be present if value is 1726 greater than 0, 1727 MAY be present if 0 1728 . . SUMMARY 1 Can be null 1729 . . UID 1 1731 . . ATTACH 0+ 1732 . . CATEGORIES 0 or 1 1733 . . CLASS 0 or 1 1734 . . COMMENT 0 or 1 1735 . . CONTACT 0+ 1736 . . CREATED 0 or 1 1737 . . DESCRIPTION 0 or 1 Can be null 1738 . . DTEND 0 or 1 if present DURATION MUST 1739 NOT be present 1741 . . DTSTAMP 1 1742 . . DTSTART 1 1743 . . DURATION 0 or 1 if present DTEND MUST NOT 1744 be present 1745 . . EXDATE 0+ 1746 . . EXRULE 0+ 1747 . . GEO 0 or 1 1748 . . LAST-MODIFIED 0 or 1 1749 . . LOCATION 0 or 1 1750 . . ORGANIZER 1 1751 . . PRIORITY 0 or 1 1752 . . RDATE 0+ 1753 . . RECURRENCE-ID 0 or 1 only if referring to an 1754 instance of a recurring 1755 calendar component. 1756 Otherwise it MUST NOT be 1757 present. 1758 . . RELATED-TO 0+ 1759 . . REQUEST-STATUS 0+ 1760 . . RESOURCES 0 or 1 This property MAY contain a 1761 list of values 1762 . . RRULE 0+ 1763 . . STATUS 0 or 1 1764 . . TRANSP 0 or 1 1765 . . URL 0 or 1 1766 . . X-PROPERTY 0+ 1767 . . [IANA-PROP] 0+ any IANA registered 1768 property 1770 . . VALARM 0+ 1771 . . . ACTION 1 1772 . . . ALARMID 1 1773 . . . ATTACH 0+ 1774 . . . DESCRIPTION 0 or 1 1775 . . . DURATION 0 or 1 if present REPEAT MUST be 1776 present 1777 . . . REPEAT 0 or 1 if present DURATION MUST be 1778 present 1779 . . . SUMMARY 0 or 1 1780 . . . TRIGGER 1 1781 . . . X-PROPERTY 0+ 1782 . . . [IANA-PROP] 0+ any IANA registered property 1784 . VTODO 0+ 1785 . . ATTENDEE 0+ 1786 . . SEQUENCE 0 or 1 MUST be present if value is 1787 greater than 0, MAY be 1788 present if 0 1789 . . SUMMARY 1 Can be null. 1790 . . UID 1 1792 . . ATTACH 0+ 1793 . . CATEGORIES 0 or 1 This property may contain a 1794 list of values 1795 . . CLASS 0 or 1 1796 . . COMMENT 0 or 1 1797 . . CONTACT 0+ 1798 . . CREATED 0 or 1 1799 . . DESCRIPTION 0 or 1 Can be null 1800 . . DTSTAMP 1 1801 . . DTSTART 1 1802 . . DUE 0 or 1 If present DURATION MUST NOT 1803 be present 1804 . . DURATION 0 or 1 If present DUE MUST NOT be 1805 present 1806 . . EXDATE 0+ 1807 . . EXRULE 0+ 1808 . . GEO 0 or 1 1809 . . LAST-MODIFIED 0 or 1 1810 . . LOCATION 0 or 1 1811 . . ORGANIZER 1 1812 . . PRIORITY 1 1813 . . PERCENT-COMPLETE 0 or 1 1814 . . RDATE 0+ 1815 . . RECURRENCE-ID 0 or 1 MUST only if referring to an 1816 instance of a recurring 1817 calendar component. 1818 Otherwise it MUST NOT be 1819 present. 1820 . . RELATED-TO 0+ 1821 . . REQUEST-STATUS 0 1822 . . RESOURCES 0 or 1 This property may contain a 1823 list of values 1824 . . RRULE 0+ 1825 . . STATUS 0 or 1 MAY be one of COMPLETED, 1826 NEEDS-ACTION, 1827 IN-PROCESS, CANCELLED 1828 . . URL 0 or 1 1830 . . X-PROPERTY 0+ 1831 . . [IANA-PROP] 0+ any IANA registered property 1833 . . VALARM 0+ 1834 . . . ACTION 1 1835 . . . ALARMID 1 1836 . . . ATTACH 0+ 1837 . . . DESCRIPTION 0 or 1 1838 . . . DURATION 0 or 1 if present REPEAT MUST be 1839 present 1840 . . . REPEAT 0 or 1 if present DURATION MUST be 1841 present 1842 . . . SUMMARY 0 or 1 1843 . . . TRIGGER 1 1844 . . . X-PROPERTY 0+ 1845 . . . [IANA-PROP] 0+ any IANA registered property 1847 . VJOURNAL 0+ 1848 . . ATTENDEE 0 1849 . . DESCRIPTION 1 Can be null. 1850 . . DTSTAMP 1 1851 . . DTSTART 1 1852 . . ORGANIZER 1 1853 . . UID 1 1855 . . ATTACH 0+ 1856 . . CATEGORIES 0 or 1 This property MAY contain a list 1857 of values 1858 . . CLASS 0 or 1 1859 . . COMMENT 0 or 1 1860 . . CONTACT 0+ 1861 . . CREATED 0 or 1 1862 . . EXDATE 0+ 1863 . . EXRULE 0+ 1864 . . LAST-MODIFIED 0 or 1 1865 . . RDATE 0+ 1866 . . RECURRENCE-ID 0 or 1 MUST only if referring to 1867 an instance of a recurring 1868 calendar component. 1869 Otherwise it MUST NOT be 1870 present. 1871 . . RELATED-TO 0+ 1872 . . REQUEST-STATUS 0+ 1873 . . RRULE 0+ 1874 . . SEQUENCE 0 or 1 MUST be present if 1875 non-zero. MAY be 1876 present if zero. 1877 . . STATUS 0 or 1 1878 . . SUMMARY 0 or 1 Can be null 1879 . . URL 0 or 1 1880 . . X-PROPERTY 0+ 1881 . . [IANA-PROP] 0+ any IANA registered 1882 property 1884 . VFREEBUSY 0 1886 . VTIMEZONE 0+ MUST be present if any 1887 date/time refers to a 1888 timezone 1889 . . DAYLIGHT 0+ MUST be one or more of 1890 either STANDARD or 1891 DAYLIGHT 1892 . . . . COMMENT 0 or 1 1893 . . . . DTSTART 1 1894 . . . . RDATE 0+ if present RRULE MUST NOT 1895 be present 1896 . . . . RRULE 0+ if present RDATE MUST NOT 1897 be present 1898 . . . . TZNAME 0 or 1 1899 . . . . TZOFFSET 1 1900 . . . . TZOFFSETFROM 1 1901 . . . . TZOFFSETTO 1 1902 . . . . X-PROPERTY 0+ 1903 . . . . [IANA-PROP] 0+ any IANA registered 1904 property 1905 . . LAST-MODIFIED 0 or 1 1906 . . STANDARD 0+ 1907 . . . . COMMENT 0 or 1 1908 . . . . DTSTART 1 1909 . . . . RDATE 0+ if present RRULE MUST NOT 1910 be present 1911 . . . . RRULE 0+ if present RDATE MUST NOT 1912 be present 1913 . . . . TZNAME 0 or 1 1914 . . . . TZOFFSETFROM 1 1915 . . . . TZOFFSETTO 1 1916 . . . . X-PROPERTY 0+ 1917 . . . . [IANA-PROP] 0+ any IANA registered property 1918 . . TZID 1 1919 . . TZURL 0 or 1 1920 . . X-PROPERTY 0+ 1921 . . [IANA-PROP] 0+ any IANA registered property 1923 Restriction Table for the "data" element of the "result" response: 1925 Component/Property Presence Comment 1926 ------------------- -------- ------------------------------- 1928 VCALENDAR 1+ 1929 . VERSION 1 MUST be 2.1 1931 . VAGENDA 0+ 1932 . . RELCALID 1 1933 . . REQUEST-STATUS 1+ 1935 . VCAR 0+ 1936 . . CARID 1 1937 . . REQUEST-STATUS 1+ 1939 . VEVENT 0+ 1940 . . UID 1 The UID for which this 1941 REQUEST-STATUS applies 1942 . . REQUEST-STATUS 1+ 1943 . . RECURRENCE-ID 0 or 1 MUST be specified only if instance of 1944 a recurring component was created. 1945 . . VALARM 0 if VEVENT was successfully 1946 saved 1947 1+ if there were errors saving 1948 alarms 1949 . . . ALARMID 1 1950 . . . REQUEST-STATUS 1+ 1952 . VFREEBUSY 0 1954 . VJOURNAL 0+ 1955 . . UID 1 The UID for which this 1956 REQUEST-STATUS applies 1957 . . RECURRENCE-ID 0 or 1 MUST be specified only if instance of 1958 a recurring component was created. 1959 . . REQUEST-STATUS 1+ 1961 . VQUERY 0+ 1962 . . REQUEST-STATUS 1+ 1964 . VTODO 0+ 1965 . . UID 1 The UID for which this 1966 REQUEST-STATUS applies 1967 . . RECURRENCE-ID 0 or 1 MUST be specified only if instance of 1968 a recurring component was created. 1969 . . REQUEST-STATUS 1+ 1970 . . VALARM 0 if VTODO was successfully 1971 saved 1972 1+ if there were errors saving 1973 alarms 1974 . . . ALARMID 1 1975 . . . REQUEST-STATUS 1+ 1977 Example: 1979 In the following example, two new top level VAGENDAs are created. 1981 Note that the CSID of the server is cal.example.com. 1983 C: MSG 1 8 . 3843 778 1984 C: Content-Type: multipart/related; boundary="boundary-foo321"; 1985 C: start="1@cal.example.com"; 1986 C: type="application/beep+xml" 1987 C: 1988 C: --boundary-foo321 1989 C: Content-Type: application/beep+xml 1990 C: Content-ID: 1@cal.example.com 1991 C: 1992 C: 1993 C: 1994 C: 1995 C: 1996 C: --boundary-foo321 1997 C: Content-Type: text/calendar 1998 C: Content-ID: 2@cal.example.com 1999 C: 2000 C: BEGIN:VCALENDAR 2001 C: VERSION:2.1 2002 C: BEGIN:VAGENDA 2003 C: RELCALID:relcalz1 2004 C: NAME;LANGUAGE=EN-us:Bill's Soccer Team 2005 C: OWNER:bill 2006 C: CALMASTER:mailto:bill@example.com 2007 C: TZID:US_PST 2008 C: END:VAGENDA 2009 C: BEGIN:VAGENDA 2010 C: RELCALID:relcalz2 2011 C: NAME;LANGUAGE=EN-us:Mary's personal calendar 2012 C: OWNER:mary 2013 C: CALMASTER:mailto:mary@example.com 2014 C: TZID:US_PST 2015 C: END:VAGENDA 2016 C: END:VCALENDAR 2017 C: --boundary-foo321-- 2018 C: END 2019 S: RPY 1 8 . 4621 647 2020 S: Content-Type: multipart/related; boundary="boundary-bar321"; 2021 S: start="1@cal.example.com"; 2022 S: type="application/beep+xml" 2023 S: 2024 S: --boundary-bar321 2025 S: Content-Type: application/beep+xml 2026 S: Content-ID: 1@cal.example.com 2027 S: 2028 S: 2029 S: 2030 S: 2031 S: 2032 S: 2033 S: --boundary-bar321 2034 S: Content-Type:text/calendar; 2035 S: Content-ID: 2@cal.example.com 2036 S: 2037 S: BEGIN:VCALENDAR 2038 S: VERSION:2.1 2039 S: BEGIN:VAGENDA 2040 S: RELCALID:relcalz1 2041 S: REQUEST-STATUS:2.0 2042 S: END:VAGENDA 2043 S: BEGIN:VAGENDA 2044 S: RELCALID:relcalz2 2045 S: REQUEST-STATUS:2.0 2046 S: END:VAGENDA 2047 S: END:VCALENDAR 2048 S: --boundary-bar321-- 2049 S: END 2051 Example to create a new component in multiple containers. 2053 C: MSG 1 9 . 5268 622 2054 C: Content-Type: multipart/related; boundary="boundary-kshgd"; 2055 C: start="1@cal.example.com"; 2056 C: type="application/beep+xml" 2057 C: 2058 C: --boundary-kshgd 2059 C: Content-Type: application/beep+xml 2060 C: Content-ID: 1@cal.example.com 2061 C: 2062 C: 2063 C: 2064 C: 2065 C: 2066 C: 2067 C: --boundary-kshgd 2068 C: Content-Type: text/calendar 2069 C: Content-ID: 2@cal.example.com 2070 C: 2071 C: BEGIN:VCALENDAR 2072 C: VERSION:2.1 2073 C: BEGIN:VEVENT 2074 C: DTSTART:99990307T180000Z 2075 C: UID:abcd12345 2076 C: DTEND:99990307T190000Z 2077 C: SUMMARY:Important Meeting 2078 C: END:VEVENT 2079 C: END:VCALENDAR 2080 C: --boundary-kshgd-- 2081 C: END 2082 S: ANS 1 9 . 58901 563 0 2083 S: Content-Type: multipart/related; boundary="boundary-eqrga"; 2084 S: start="1@cal.example.com"; 2085 S: type="application/beep+xml" 2086 S: 2087 S: --boundary-eqrga 2088 S: Content-Type: application/beep+xml 2089 S: Content-ID: 1@cal.example.com 2090 S: 2091 S: 2092 S: 2093 S: 2094 S: 2095 S: 2096 S: --boundary-eqrga 2097 S: Content-Type: text/calendar 2098 S: Content-ID: 2@cal.example.com 2099 S: 2100 S: BEGIN:VCALENDAR 2101 S: VERSION:2.1 2102 S: BEGIN:VEVENT 2103 S: UID:abcd12345 2104 S: REQUEST-STATUS:2.9 2105 S: END:VEVENT 2106 S: END:VCALENDAR 2107 S: --boundary-eqrga-- 2108 S: END 2109 S: ANS 1 9 . 6453 563 1 2110 S: Content-Type: multipart/related; boundary="boundary-982hf"; 2111 S: start="1@cal.example.com"; 2112 S: type="application/beep+xml" 2113 S: 2114 S: --boundary-982hf 2115 S: Content-Type: application/beep+xml 2116 S: Content-ID: 1@cal.example.com 2117 S: 2118 S: 2119 S: 2120 S: 2121 S: 2122 S: 2123 S: --boundary-982hf 2124 S: Content-Type: text/calendar 2125 S: Content-ID: 2@cal.example.com 2126 S: 2127 S: BEGIN:VCALENDAR 2128 S: VERSION:2.1 2129 S: BEGIN:VEVENT 2130 S: UID:abcd12345 2131 S: REQUEST-STATUS:6.0 2132 S: END:VEVENT 2133 S: END:VCALENDAR 2134 S: --boundary-982hf-- 2135 S: END 2136 S: NUL 1 9 . 7016 0 2137 S: END 2139 As described in Section 3.1, the CS sends one response per "target" 2140 element present in the "create" command. 2142 6.2.4.2 "delete" Command 2144 Attributes: 2146 "id" (see Section 6.2.2.1). 2148 Elements: 2150 "max-time": See Section 3.3. 2152 "select": specifies the compoments to delete (see Section 2153 6.2.3.2). 2155 Response: 2157 One "result" message per "source" in the "select" element (see 2158 Section 3.1). 2160 One of the following "request-status" codes MUST be returned: 2162 2.0 - successfully created the component or calendar 2164 6.1 - Container not found 2166 6.3 - Bad args 2168 The "data" element of each "result" message is subject to the 2169 result restriction table define below. 2171 The "delete" command is used to delete a calendar or component. The 2172 "select" element specifies the container(s) to delete. 2174 Restriction Table for the "data" element of the "result" response(s). 2176 Component/Property Presence Comment 2177 ------------------- -------- ----------------------------- 2179 VCALENDAR 1+ 2181 . VERSION 1 MUST be 2.1 2183 . VAGENDA Only if VAGENDAS were 2184 deleted 2185 . RELCALID 1 2186 . REQUEST-STATUS 1 2188 . VCAR 0+ Only if VCAR components were 2189 deleted 2190 . . CARID 1 2191 . . REQUEST-STATUS 1 2193 . VEVENT 0+ Only if VEVENT components 2194 were deleted 2195 . . UID 1 2196 . . REQUEST-STATUS 0 or 1 Omitted if an embedded VALARM was 2197 the target of the deletion. 2198 . . VALARM 0+ Only if VALARM components 2199 were deleted 2200 . . . ALARMID 1 2201 . . . REQUEST-STATUS 1 2203 . VFREEBUSY 0 2204 . . UID 1 2205 . . DTSTAMP 1 2206 . . REQUEST-STATUS 1 2208 . VJOURNAL 0+ Only if VJOURNAL components 2209 were deleted 2210 . . UID 1 2211 . . REQUEST-STATUS 1 2213 . VQUERY 0+ Only if VQUERY components 2214 were deleted 2215 . UID 1 2216 . REQUEST-STATUS 1 2218 . VTIMEZONE 0+ Only if VTIMEZONE components 2219 . . TZID were deleted 2220 . . REQUEST-STATUS 1 2221 . VTODO 0+ Only if VTODO components were 2222 deleted 2223 . . UID 1 2224 . . REQUEST-STATUS 0 or 1 Omitted if an embedded VALARM was 2225 the target of the deletion. 2227 . . VALARM 0+ Only if VALARM components 2228 were deleted 2229 . . . ALARMID 1 2230 . . . REQUEST-STATUS 1 2232 ---------------------------------------------------------- 2234 [EDITORS NOTE: Issues: 2236 - Can one use DELETE to remove all VALARMs and VTIMEZONEs that 2237 match a certain search criteria and that belong to all components, 2238 event though VALARMs and VTIMEZONEs never exist as independent 2239 components? Or should one use MODIFY? If they can be deleted, do 2240 we return the REQUEST-STATUS of their deletion in a VEVENT or 2241 separately? 2243 Example to delete a VEVENT with UID 'abcd12345' from any of the 2244 calendar owned by the CU with the UPN="user@cal.example.com": 2246 C: MSG 1 10 . 7016 558 2247 C: Content-Type: multipart/related; boundary="boundary-gsdmx3"; 2248 C: start="1@cal.example.com"; 2249 C: type="application/beep+xml" 2250 C: 2251 C: --boundary-gsdmx3 2252 C: Content-Type: application/beep+xml 2253 C: Content-ID: 1@cal.example.com 2254 C: 2255 C: 2256 C: 2260 C: 2261 C: --boundary-gsdmx3 2262 C: Content-Type: text/calendar 2263 C: Content-ID: 2@cal.example.com 2264 C: 2265 C: BEGIN:VQUERY 2266 C: QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' 2267 C: END:VQUERY 2268 C: --boundary-gsdmx3-- 2269 C: END 2270 S: RPY 1 10 . 7574 587 2271 S: Content-Type: multipart/related; boundary="boundary-oifc3j"; 2272 S: start="1@cal.example.com"; 2273 S: type="application/beep+xml" 2274 S: 2275 S: --boundary-oifc3j 2276 S: Content-Type: application/beep+xml 2277 S: Content-ID: 1@cal.example.com 2278 S: 2279 S: 2280 S: 2281 S: 2282 S: 2283 S: 2284 S: --boundary-oifc3j 2285 S: Content-Type: text/calendar 2286 S: Content-ID: 2@cal.example.com 2287 S: 2288 S: BEGIN:VCALENDAR 2289 S: VERSION:2.1 2290 S: BEGIN:VEVENT 2291 S: UID:abcd12345 2292 S: REQUEST-STATUS: 2.0 2293 S: END:VEVENT 2294 S: END:VCALENDAR 2295 S: --boundary-oifc3j-- 2296 S: END 2298 6.2.4.3 "modify" Command 2300 Attributes: 2302 "id" (see Section 6.2.2.1). 2304 Elements: 2306 "max-time": See Section 3.3. 2308 "select": identifies the component(s) to modify. 2310 "add": adds properties to the selected component(s). 2312 "remove": removes properties from the selected component(s). 2314 "update": updates the content of the selected component(s). 2316 Response: 2318 One "result" message per "source" in the "select" is returned (see 2319 Section 3.1). 2321 One of the following "request-status" codes MUST be returned: 2323 2.0 - successfully created the component or calendar 2325 6.1 - Container not found 2327 6.3 - Bad args 2329 The "data" element of each "result" message is subject to the 2330 restriction table defined below. 2332 The "modify" command is used to modify existing components. The 2333 "select" element specifies the components to modify. The "add", 2334 "remove" and "update" elements define the operations to perform. 2336 The "add" element is used to add properties or nested components to 2337 the selected components. The "add" element is composed of a "data" 2338 element that contains a component with the properties to add. For 2339 example to add an inline attachment to a VEVENT the following 2340 iCalendar object could be: 2342 BEGIN:VCALENDAR 2343 BEGIN:VEVENT 2344 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: 2345 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U 2346 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE 2347 <...remainder of "BASE64" encoded binary data...> 2348 END:VEVENT 2349 END:VCALENDAR 2351 The "remove" element is used to remove properties from the selected 2352 components. The "data" element contains an iCalendar with the 2353 properties to delete. When the "ignore-value" attribute is set to 2354 true, all the properties specified in the "data" element are removed 2355 even if the values do not match the current state of the component. 2356 This is useful to remove potentially large properties efficiently 2357 (e.g., "ATTACH"). 2359 The "update" element is used to update or add the properties referred 2360 to by the "data" element. If the "remove-missing" attribute is set 2361 to true, then all the elements not present in the "data" element 2362 document will be removed from the selected components. 2364 When more than one operations is specified, the modifications MUST 2365 must respect the following order: "remove" followed by "update" 2366 followed by "add". The modifications MUST only be applied if the 2367 resulting component respects the restriction table of the "create" 2368 command. 2370 Restriction Table for "data" element of the "result" response: 2372 Component/Property Presence Comment 2373 ------------------- -------- ------------------------------- 2375 VCALENDAR 1+ 2376 . VERSION 1 MUST be 2.1 2378 . VAGENDA 0+ 2379 . . RELCALID 1 2380 . . REQUEST-STATUS 1+ 2382 . VCAR 0+ 2383 . . CARID 1 2384 . . REQUEST-STATUS 1+ 2386 . VEVENT 0+ 2387 . . UID 1 2388 . . RECURRENCE-ID 0 or 1 MUST be specified only if instance of 2389 a recurring component was modified. 2390 . . REQUEST-STATUS 1+ 2392 . . VALARM 0 if VEVENT was successfully 2393 saved 2394 1+ if there were errors saving 2395 alarms 2396 . . . REQUEST-STATUS 1+ 2398 . VFREEBUSY 0 2400 . VJOURNAL 0+ 2401 . . UID 1 2402 . . RECURRENCE-ID 0 or 1 MUST be specified only if instance of 2403 a recurring component was modified. 2404 . . REQUEST-STATUS 1+ 2406 . VQUERY 0+ 2407 . . REQUEST-STATUS 1+ 2409 . VTODO 0+ 2410 . . UID 1 2411 . . RECURRENCE-ID 0 or 1 MUST be specified only if instance of 2412 a recurring component was modified. 2413 . . REQUEST-STATUS 1+ 2414 . . VALARM 0 if VTODO was successfully 2415 saved 2416 1+ if there were errors saving 2417 alarms 2418 . . . REQUEST-STATUS 1+ 2420 In the example below, the start and end time of the event with UID 2421 abcd12345 is changed and the LOCATION property is removed. 2423 C: MSG 1 11 . 8161 1144 2424 C: Content-Type: multipart/related; boundary="boundary-324dav"; 2425 C: start="1@cal.example.com"; 2426 C: type="application/beep+xml" 2427 C: 2428 C: --boundary-324dav 2429 C: Content-Type: application/beep+xml 2430 C: Content-ID: 1@cal.cal.example.com 2431 C: 2432 C: 2433 C: 2437 C: 2438 C: 2439 C: 2440 C: 2441 C: 2442 C: 2443 C: 2444 C: --boundary-324dav 2445 C: Content-Type: text/calendar 2446 C: Content-ID: query@cal.example.com 2447 C: 2448 C: BEGIN:VCALENDAR 2449 C: BEGIN:VQUERY 2450 C: QUERY: SELECT * FROM VEVENT WHERE UID='abcd12345' 2451 C: END:VQUERY 2452 C: END:VCALENDAR 2453 C: --boundary-324dav 2454 C: Content-Type: text/calendar 2455 C: Content-ID: remove@cal.example.com 2456 C: 2457 C: BEGIN:VCALENDAR 2458 C: BEGIN:VEVENT 2459 C: LOCATION: 2461 C: END:VEVENT 2462 C: END:VCALENDAR 2463 C: --boundary-324dav 2464 C: Content-Type: text/calendar 2465 C: Content-ID: update@cal.example.com 2466 C: 2467 C: BEGIN:VCALENDAR 2468 C: BEGIN:VEVENT 2469 C: DTSTART:19990421T160000Z 2470 C: DTEND:19990421T163000Z 2471 C: END:VEVENT 2472 C: END:VCALENDAR 2473 C: --boundary-324dav-- 2474 C: END 2475 S: RPY 1 11 . 9305 570 2476 S: Content-Type: multipart/related; boundary="boundary-tvx2"; 2477 S: start="command@cal.example.com"; 2478 S: type="application/beep+xml" 2479 S: 2480 S: --boundary-tvx2 2481 S: Content-Type: application/beep+xml 2482 S: Content-ID: command@cal.example.com 2483 S: 2484 S: 2485 S: 2486 S: 2487 S: 2488 S: 2489 S: --boundary-tvx2 2490 S: Content-Type: text/calendar 2491 S: Content-ID: 2@cal.example.com 2492 S: 2493 S: BEGIN:VCALENDAR 2494 S: BEGIN:VEVENT 2495 S: UID:abcd12345 2496 S: REQUEST-STATUS: 2.0 2497 S: END:VEVENT 2498 S: END:VCALENDAR 2499 S: --boundary-tvx2-- 2500 S: END 2502 In this example, all instances of "Building 6" are replaced by "New 2503 office lobby" in VEVENTs: 2505 C: MSG 1 12 . 9875 870 2506 C: Content-Type: multipart/related; boundary="boundary-trew2"; 2507 C: start="1@cal.example.com"; 2508 C: type="application/beep+xml" 2509 C: 2510 C: --boundary-trew2 2511 C: Content-Type: application/beep+xml 2512 C: Content-ID: 1@cal.example.com 2513 C: 2514 C: 2515 C: 2519 C: 2520 C: 2521 C: 2522 C: 2523 C: --boundary-trew2 2524 C: Content-Type: text/calendar 2525 C: Content-ID: query@cal.example.com 2526 C: 2527 C: BEGIN:VCALENDAR 2528 C: BEGIN:VQUERY 2529 C: QUERY: SELECT * FROM VEVENT WHERE LOCATION='Building 6' 2530 C: END:VQUERY 2531 C: END:VCALENDAR 2532 C: --boundary-trew2 2533 C: Content-Type: text/calendar 2534 C: Content-ID: update@cal.example.com 2535 C: 2536 C: BEGIN:VCALENDAR 2537 C: BEGIN:VEVENT 2538 C: LOCATION:New office lobby 2539 C: END:VEVENT 2540 C: END:VCALENDAR 2541 C: --boundary-trew2-- 2542 C: END 2543 S: RPY 1 12 . 10745 578 2544 S: Content-Type: multipart/related; boundary="boundary-poiu51"; 2545 S: start="command@cal.example.com"; 2546 S: type="application/beep+xml" 2547 S: 2548 S: --boundary-poiu51 2549 S: Content-Type: application/beep+xml 2550 S: Content-ID: command@cal.example.com 2551 S: 2552 S: 2553 S: 2554 S: 2555 S: 2556 S: 2557 S: --boundary-poiu51 2558 S: Content-Type: text/calendar 2559 S: Content-ID: 2@cal.example.com 2560 S: 2561 S: BEGIN:VCALENDAR 2562 S: BEGIN:VEVENT 2563 S: UID:abcd12345 2564 S: REQUEST-STATUS: 2.0 2565 S: END:VEVENT 2566 S: END:VCALENDAR 2567 S: --boundary-poiu51-- 2568 S: END 2570 6.2.4.4 "move" Command 2572 Attributes: 2574 "id" (see Section 6.2.2.1). 2576 Elements: 2578 "max-time": See Section 3.3. 2580 "target": The "target" element points to the container where the 2581 components are to be relocated. 2583 "select": identifies the component(s) to move. 2585 Response: 2587 One "result" message for each "source" in the "select" element is 2588 returned (see Section 3.1). 2590 One of the following "request-status" codes MUST be returned: 2592 2.0 - successfully created the component or calendar 2594 6.1 - Container not found 2596 6.3 - Bad args 2598 The "data" element of each "result" message is subject to the 2599 result restriction table defined below. 2601 The "move" command is used to move components within the CS's 2602 hierarchy of calendars. When moving VAGENDA, the CS MUST ensure that 2603 VCARs are still valid after the move, and the CS MUST update the 2604 PARENT and CHILDREN properties of the new and old parent containers. 2606 Restriction Table for "data" element of the "result" response: 2608 Component/Property Presence Comment 2609 ------------------- -------- ------------------------------- 2611 VCALENDAR 1+ 2612 . VERSION 1 MUST be 2.1 2614 . VAGENDA 0+ 2615 . . RELCALID 1 2616 . . REQUEST-STATUS 1+ 2618 . VCAR 0+ 2619 . . CARID 1 2620 . . REQUEST-STATUS 1+ 2622 . VEVENT 0+ 2623 . . UID 1 2624 . . REQUEST-STATUS 1+ 2626 . . VALARM 0 if VEVENT was successfully 2627 saved 2628 1+ if there were errors saving 2629 alarms 2630 . . . ALARMID 1 2631 . . . REQUEST-STATUS 1+ 2633 . VFREEBUSY 0 2635 . VJOURNAL 0+ 2636 . . UID 1 2637 . . REQUEST-STATUS 1+ 2639 . VQUERY 0+ 2640 . . REQUEST-STATUS 1+ 2642 . VTODO 0+ 2643 . . UID 1 2644 . . REQUEST-STATUS 1+ 2645 . . VALARM 0 if VTODO was successfully 2646 saved 2647 1+ if there were errors saving 2648 alarms 2649 . . . ALARMID 1 2650 . . . REQUEST-STATUS 1+ 2651 --------------------------------------------------------- 2653 [EDITORS NOTE: Issues: 2655 1) Should one be able to move a calendar owned by person X into a 2656 calendar owned by person Y. (Can these such rights be specified 2657 in VCARs?) 2659 Example: moving the VAGENDA Nellis to Area-51 2661 C: MSG 1 12 . 11323 613 2662 C: Content-Type: multipart/related; boundary="boundary-kljr"; 2663 C: start="1@cal.example.com"; 2664 C: type="application/beep+xml" 2665 C: 2666 C: --boundary-kljr 2667 C: Content-Type: application/beep+xml 2668 C: Content-ID: 1@cal.example.com 2669 C: 2670 C: 2671 C: 2675 C: 2676 C: 2677 C: --boundary-kljr 2678 C: Content-Type: text/calendar 2679 C: Content-ID: query@cal.example.com 2680 C: 2681 C: BEGIN:VCALENDAR 2682 C: BEGIN:VQUERY 2683 C: QUERY: SELECT * FROM VAGENDA WHERE RELCALID='Nellis' 2684 C: END:VQUERY 2685 C: END:VCALENDAR 2686 C: --boundary-kljr-- 2687 C: END 2688 S: RPY 1 2 . 11936 571 2689 S: Content-Type: multipart/related; boundary="boundary-mnbvd"; 2690 S: start="reply@cal.example.com"; 2691 S: type="application/beep+xml" 2692 S: 2693 S: --boundary-mnbvd 2694 S: Content-Type: application/beep+xml 2695 S: Content-ID: reply@cal.example.com 2696 S: 2697 S: 2698 S: 2699 S: 2700 S: 2701 S: 2702 S: --boundary-mnbvd 2703 S: Content-Type: text/calendar 2704 S: Content-ID: 2@cal.example.com 2705 S: 2706 S: BEGIN:VCALENDAR 2707 S: BEGIN:VAGENDA 2708 S: RELCALID:Nellis 2709 S: REQUEST-STATUS: 2.0 2710 S: END:VAGENDA 2711 S: END:VCALENDAR 2712 S: --boundary-mnbvd-- 2713 S: END 2715 6.2.4.5 "search" Command 2717 Attributes: 2719 "id" (see Section 6.2.2.1). 2721 Elements: 2723 "max-time": See Section 3.3. 2725 "select": identifies the components to return. 2727 "max-results": maximum number of components to return per source 2728 (if omited unlimited). 2730 "max-size": maximum size in bytes, of the iCalendar object to 2731 return. 2733 Response: 2735 A "result" message per "source" in the "select" element is 2736 returned (see Section 3.1). 2738 One of the following "request-status" codes MUST be returned: 2740 2.0 - successfully created the component or calendar 2742 6.1 - Container not found 2744 6.3 - Bad args 2746 The "data" element of each "result" message points to an iCalendar 2747 object composed of all the selected components. Only "REQUEST- 2748 STATUS" and the properties mentioned in the "SELECT" clause of the 2749 QUERY are included in the components. 2751 Searching for Events 2753 In the example below events on March 10,1999 between 080000Z and 2754 190000Z are read. In this case only 4 properties for each event are 2755 returned. Two calendars are specified. Only booked (vs scheduled) 2756 entries are to be returned. The first result returns two VEVENTs 2757 that match in that "source", the second result returns only one 2758 VEVENT for the second "source". 2760 C: MSG 1 13 . 12507 704 2761 C: Content-Type: multipart/related; boundary="boundary-5329"; 2762 C: start="1@cal.example.com"; 2763 C: type="application/beep+xml" 2764 C: 2765 C: --boundary-5329 2766 C: Content-Type: application/beep+xml 2767 C: Content-ID: 1@cal.example.com 2768 C: 2769 C: 2770 C: 2775 C: 2776 C: --boundary-5329 2777 C: Content-Type: text/calendar 2778 C: Content-ID: query@cal.example.com 2779 C: 2780 C: BEGIN:VCALENDAR 2781 C: BEGIN:VQUERY 2782 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID 2783 C: FROM VEVENT 2784 C: WHERE DTEND >= '19990310T080000Z' 2785 C: AND DTSTART <= '19990310T190000Z' 2786 C: AND METHOD IS NULL 2787 C: END:VQUERY 2788 C: END:VCALENDAR 2789 C: --boundary-5329-- 2790 C: END 2791 S: ANS 1 13 . 13211 803 0 2792 S: Content-Type: multipart/related; boundary="boundary-f4fw2"; 2793 S: start="answer@cal.example.com"; 2794 S: type="application/beep+xml" 2795 S: 2796 S: --boundary-f4fw2 2797 S: Content-Type: application/beep+xml 2798 S: Content-ID: answer@cal.example.com 2799 S: 2800 S: 2801 S: 2802 S: 2803 S: 2804 S: 2805 S: --boundary-f4fw2 2806 S: Content-Type: text/calendar 2807 S: Content-ID: 2@cal.example.com 2808 S: 2809 S: BEGIN:VCALENDAR 2810 S: VERSION:2.1 2811 S: BEGIN:VEVENT 2812 S: DTSTART:19990310T090000Z 2813 S: DTEND:19990310T100000Z 2814 S: UID:abcxyz12345 2815 S: SUMMARY:Meet with Sir Elton 2816 S: REQUEST-STATUS:2.0 2817 S: END:VEVENT 2818 S: BEGIN:VEVENT 2819 S: DTSTART:19990310T130000Z 2820 S: DTEND:19990310T133000Z 2821 S: UID:abcxyz8999 2822 S: SUMMARY:Meet with brave Sir Robin 2823 S: REQUEST-STATUS:2.0 2824 S: END:VEVENT 2825 S: END:VCALENDAR 2826 S: --boundary-f4fw2-- 2827 S: END 2828 S: ANS 1 13 . 14014 664 1 2829 S: Content-Type: multipart/related; boundary="boundary-r432"; 2830 S: start="answer@cal.example.com"; 2831 S: type="application/beep+xml" 2832 S: 2833 S: --boundary-r432 2834 S: Content-Type: application/beep+xml 2835 S: Content-ID: answer@cal.example.com 2836 S: 2837 S: 2838 S: 2839 S: 2840 S: 2841 S: 2842 S: --boundary-r432 2843 S: Content-Type: text/calendar 2844 S: Content-ID: 2@cal.example.com 2845 S: 2846 S: BEGIN:VCALENDAR 2847 S: VERSION:2.1 2848 S: BEGIN:VEVENT 2849 S: REQUEST-STATUS:2.0 2850 S: DTSTART:19990310T140000Z 2851 S: DTEND:19990310T150000Z 2852 S: UID:123456asdf 2853 S: SUMMARY:Summer Budget 2854 S: REQUEST-STATUS:2.0 2855 S: END:VEVENT 2856 S: END:VCALENDAR 2857 S: --boundary-r432-- 2858 S: END 2859 S: NUL 1 13 . 14678 0 2860 S: END 2862 The return values are subject to VCAR filtering. That is, if the 2863 request contains properties to which the UPN does not have access, 2864 those properties will not appear in the return values. If the UPN 2865 has access to at least one property of the component, but has been 2866 denied access to all properties called out in the request, the 2867 response will contain a single REQUEST-STATUS property indicating the 2868 error. That is, the VEVENT components will be the following: 2870 [EDITORS NOTE: Should the one(s) that the UPN has access to - be 2871 returned?] 2873 S: ANS 1 13 . 14014 548 0 2874 S: Content-Type: multipart/related; boundary="boundary-fmei3"; 2875 S: start="command@cal.example.com"; 2876 S: type="application/beep+xml" 2877 S: 2878 S: --boundary-fmei3 2879 S: Content-Type: application/beep+xml 2880 S: Content-ID: command@cal.example.com 2881 S: 2882 S: 2883 S: 2884 S: 2885 S: 2886 S: 2887 S: --boundary-fmei3 2888 S: Content-Type: text/calendar 2889 S: Content-ID: 2@cal.example.com 2890 S: 2891 S: BEGIN:VCALENDAR 2892 S: VERSION:2.1 2893 S: BEGIN:VEVENT 2894 S: REQUEST-STATUS:4.1 2895 S: END:VEVENT 2896 S: END:VCALENDAR 2897 S: --boundary-fmei3-- 2898 S: END 2900 If the UPN has no access to any events at all, the response will 2901 simply be an empty data set. The response looks the same if there 2902 are particular events to which the CU has been denied access. 2904 S: ANS 1 13 . 14014 502 0 2905 S: Content-Type: multipart/related; boundary="boundary-ewrvc"; 2906 S: start="command@cal.example.com"; 2907 S: type="application/beep+xml" 2908 S: 2909 S: --boundary-ewrvc 2910 S: Content-Type: application/beep+xml 2911 S: Content-ID: command@cal.example.com 2912 S: 2913 S: 2914 S: 2915 S: 2916 S: 2917 S: 2918 S: --boundary-ewrvc 2919 S: Content-Type: text/calendar 2920 S: Content-ID: 2@cal.example.com 2921 S: 2922 S: BEGIN:VCALENDAR 2923 S: VERSION:2.1 2924 S: END:VCALENDAR 2925 S: --boundary-ewrvc-- 2926 S: END 2928 Find alarms within a range of time for booked VEVENTs. 2930 C: MSG 1 15 . 14678 747 2931 C: Content-Type: multipart/related; boundary="boundary-weoiu"; 2932 C: start="1@cal.example.com"; 2933 C: type="application/beep+xml" 2934 C: 2935 C: --boundary-weoiu 2936 C: Content-Type: application/beep+xml 2937 C: Content-ID: 1@cal.example.com 2938 C: 2939 C: 2940 C: 2945 C: 2946 C: --boundary-weoiu 2947 C: Content-Type: text/calendar 2948 C: Content-ID: query@cal.example.com 2949 C: 2950 C: BEGIN:VCALENDAR 2951 C: BEGIN:VQUERY 2952 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID,VALARM.* 2953 C: FROM VEVENT,VTODO 2954 C: WHERE VALARM.TRIGGER >= '19990310T080000Z' 2955 C: AND VALARM.TRIGGER <= '19990310T190000Z' 2956 C: AND METHOD IS NULL 2957 C: END:VQUERY 2958 C: END:VCALENDAR 2959 C: --boundary-weoiu-- 2960 C: END 2961 S: ANS 1 15 . 15426 511 0 2962 S: Content-Type: multipart/related; boundary="boundary-kjhs"; 2963 S: start="command@cal.example.com"; 2964 S: type="application/beep+xml" 2965 S: 2966 S: --boundary-kjhs 2967 S: Content-Type: application/beep+xml 2968 S: Content-ID: command@cal.example.com 2969 S: 2970 S: 2971 S: 2972 S: 2973 S: 2974 S: 2975 S: --boundary-kjhs 2976 S: Content-Type: text/calendar 2977 S: Content-ID: 2@cal.example.com 2978 S: 2979 S: BEGIN:VCALENDAR 2980 S: VERSION:2.1 2981 S: END:VCALENDAR 2982 S: --boundary-kjhs-- 2983 S: END 2984 S: ANS 1 2 . 15937 734 1 2985 S: Content-Type: multipart/related; boundary="boundary-435fe"; 2986 S: start="command@cal.example.com"; 2987 S: type="application/beep+xml" 2988 S: 2989 S: --boundary-435fe 2990 S: Content-Type: application/beep+xml 2991 S: Content-ID: command@cal.example.com 2992 S: 2993 S: 2994 S: 2995 S: 2996 S: 2997 S: 2998 S: --boundary-435fe 2999 S: Content-Type: text/calendar 3000 S: Content-ID: 2@cal.example.com 3001 S: 3002 S: BEGIN:VCALENDAR 3003 S: VERSION:2.1 3004 S: BEGIN:VEVENT 3005 S: DTSTART:19990310T130000Z 3006 S: DTEND:19990310T133000Z 3007 S: UID:abcxyz8999 3008 S: SUMMARY:Meet with brave Sir Robin 3009 S: BEGIN:VALARM 3010 S: TRIGGER:19990310T132500Z 3011 S: SUMMARY:Almost time... 3012 S: ACTION:DISPLAY 3013 S: END:VALARM 3014 S: END:VEVENT 3015 S: END:VCALENDAR 3016 S: --boundary-435fe-- 3017 S: END 3018 S: NUL 1 15 . 16671 0 3019 S: END 3021 In this example bill@example.com reads a day's worth of events from 3022 cap://cal.example.com/opaqueid99. 3024 C: MSG 1 16 . 16671 668 3025 C: Content-Type: multipart/related; boundary="boundary-vnj43"; 3026 C: start="1@cal.example.com"; 3027 C: type="application/beep+xml" 3028 C: 3029 C: --boundary-vnj43 3030 C: Content-Type: application/beep+xml 3031 C: Content-ID: 1@cal.example.com 3032 C: 3033 C: 3034 C: 3038 C: 3039 C: --boundary-vnj43 3040 C: Content-Type: text/calendar 3041 C: Content-ID: query@cal.example.com 3042 C: 3043 C: BEGIN:VCALENDAR 3044 C: VERSION:2.1 3045 C: BEGIN:VQUERY 3046 C: QUERY:SELECT DTSTART,DTEND,SUMMARY, UID FROM VEVENT 3047 C: WHERE DTEND >= '19990714T080000Z' 3048 C: AND DTSTART <= '19990715T080000Z' 3049 C: END:VQUERY 3050 C: END:VCALENDAR 3051 C: --boundary-vnj43-- 3052 C: END 3053 S: RPY 1 16 . 17359 751 3054 S: Content-Type: multipart/related; boundary="boundary-rfew"; 3055 S: start="command@cal.example.com"; 3056 S: type="application/beep+xml" 3057 S: 3058 S: --boundary-rfew 3059 S: Content-Type: application/beep+xml 3060 S: Content-ID: command@cal.example.com 3061 S: 3062 S: 3063 S: 3064 S: 3065 S: 3066 S: 3067 S: --boundary-rfew 3068 S: Content-Type: text/calendar 3069 S: Content-ID: 2@cal.example.com 3070 S: 3071 S: BEGIN:VCALENDAR 3072 S: VERSION:2.1 3073 S: BEGIN:VEVENT 3074 S: DTSTART:19990714T200000Z 3075 S: DTEND:19990714T210000Z 3076 S: UID:000444888929922 3077 S: SUMMARY:Blah blah 3078 S: END:VEVENT 3079 S: BEGIN:VEVENT 3080 S: UID:0034848098038888989443 3081 S: SUMMARY:meeting 3082 S: DTEND:19990714T233000Z 3083 S: DTSTART:19990714T223000Z 3084 S: END:VEVENT 3085 S: END:VCALENDAR 3086 S: --boundary-rfew-- 3087 S: END 3089 In this example bill@example.com reads a day's worth of events from 3090 cap://cal.example.com/opaqueid101 and 3091 cap://cal.example.com/opaqueid103 3093 C: MSG 1 17 . 18110 694 3094 C: Content-Type: multipart/related; boundary="boundary=wtu"; 3095 C: start="1@cal.example.com"; 3096 C: type="application/beep+xml" 3097 C: 3098 C: --boundary=wtu 3099 C: Content-Type: application/beep+xml 3100 C: Content-ID: 1@cal.example.com 3101 C: 3102 C: 3103 C: 3108 C: 3109 C: --boundary=wtu 3110 C: Content-Type: text/calendar 3111 C: Content-ID: query@cal.example.com 3112 C: 3113 C: BEGIN:VCALENDAR 3114 C: VERSION:2.1 3115 C: BEGIN:VQUERY 3116 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT 3117 C: WHERE DTEND >= 19990714T080000Z AND 3118 C: DTSTART <= 19990715T080000Z 3119 C: END:VQUERY 3120 C: END:VCALENDAR 3121 C: --boundary=wtu-- 3122 C: END 3124 S: ANS 1 17 . 18804 717 0 3125 S: Content-Type: multipart/related; boundary="boundary-09436"; 3126 S: start="command@cal.example.com"; 3127 S: type="application/beep+xml" 3128 S: 3129 S: --boundary-09436 3130 S: Content-Type: application/beep+xml 3131 S: Content-ID: command@cal.example.com 3132 S: 3133 S: 3134 S: 3135 S: 3136 # this response code means that the transport successfully 3137 # delivered the data. 3138 S: 3139 S: 3140 S: --boundary-09436 3141 S: Content-Type: text/calendar 3142 S: Content-ID: 2@cal.example.com 3143 S: 3144 S: BEGIN:VCALENDAR 3145 S: VERSION:2.1 3146 S: BEGIN:VEVENT 3147 S: UID:0034848098038888989443 3148 S: SUMMARY:meeting 3149 S: DTEND:19990714T233000Z 3150 S: DTSTART:19990714T223000Z 3151 S: END:VEVENT 3152 S: END:VCALENDAR 3153 S: --boundary-09436-- 3154 S: END 3156 S: ANS 1 18 . 19521 216 1 3157 S: Content-Type: application/beep+xml 3158 S: 3159 S: 3160 S: 3161 S: Access Denied 3162 S: 3163 S: 3164 S: END 3166 S: NUL 1 18 . 19737 0 3167 S: END 3169 Stored VQUERY can be used by specifying the property QUERYNAME 3170 instead of QUERY. 3172 Example: 3174 BEGIN:VQUERY 3175 QUERYNAME:StoredVQuery-1 3176 END:VQUERY 3178 This match all calendar store properties. This MUST NOT return any 3179 VAGENDAs. 3181 BEGIN:VCALENDAR 3182 VERSION:2.1 3183 BEGIN:VQUERY 3184 QUERY:SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com' 3185 END:VQUERY 3186 END:VCALENDAR 3188 This will match all properties of the VAGENDA relcal4. This MUST NOT 3189 return any components. 3191 BEGIN:VCALENDAR 3192 VERSION:2.1 3193 BEGIN:VQUERY 3194 QUERY:SELECT * FROM VAGENDA WHERE RELCALID='relcal4' 3195 END:VQUERY 3196 END:VCALENDAR 3198 This will fetch all stored VQUERYs. 3200 BEGIN:VCALENDAR 3201 VERSION:2.1 3202 BEGIN:VQUERY 3203 QUERY:SELECT * FROM VQUERY WHERE QUERYNAME IS NOT NULL 3204 END:VQUERY 3205 END:VCALENDAR 3207 6.3 Scheduling Commands 3209 Scheduling commands allow a CU to indirectly manipulate a calendar by 3210 asking another CU to perform an operation on their calendar. For 3211 example, CU-A can request CU-B to add a meeting to their calendar; in 3212 effect inviting CU-B to the meeting. 3214 Calendar access rights can be granted for scheduling commands without 3215 granting rights for more generalized access with the calendar 3216 commands. 3218 [EDITORS NOTE: This section needs to be completed by adding the 3219 restriction tables for each of these iTIP methods. The basis for the 3220 text is to be taken from [iTIP].] 3222 6.3.1 "schedule" Command 3224 Attributes: 3226 "id" (see Section 6.2.2.1). 3228 Elements: 3230 "max-time": See Section 3.3. 3232 "target": Each "target" element points to a container where the 3233 sceduled element will be created. 3235 "data": MUST point to a valid iTip iCalendar object. Refer to 3236 [iTIP] for the definition of the accepted METHOD and restriction 3237 tables. 3239 Response: 3241 One "result" message per "target" element MUST be returned (see 3242 Section 3.1). 3244 One of the following "request-status" codes MUST be returned: 3246 2.0 - Success 3248 6.1 - Container not found 3250 6.3 - Bad args 3252 Additionnal request-status code MAY be returned as described on 3253 [iTIP]. 3255 The "data" element of each "result" message is subject to the 3256 result restriction table defined below. 3258 The "schedule" command insert a new scheduled component into the 3259 VSCHEDULE set of the container(s) referred to by the "target" 3260 element(s). 3262 A Calendar Service MUST accept iCalendar object with the following 3263 METHODs as described in [iTIP]: 3265 ----------------------------------------------------------- 3266 Command Description 3267 ----------------------------------------------------------- 3268 PUBLISH Publish a calendar entry to one or more 3269 calendars. 3270 REQUEST Schedule a calendar entry with one or more 3271 calendars. 3272 REPLY Response to a scheduling request. 3273 ADD Add one or more instances to an existing 3274 calendar entry. 3275 CANCEL Cancel one or more instances to an existing 3276 calendar entry. 3277 REFRESH A request for the latest version of a 3278 calendar entry. 3279 COUNTER A request for a change (a counter-proposal) 3280 to a calendar entry. 3281 DECLINECOUNTER Decline a counter proposal. 3282 ----------------------------------------------------------- 3284 6.3.2 Processing Scheduling Components 3286 A CU might be invited to a meeting. If the CU had been invited by 3287 CAP, the entry in the CU calendar will be scheduled, but not booked. 3288 So a CUA will need to look for scheduled entries in the calendar and 3289 present them to the CU or automatically decide if the invitation is 3290 to be accepted or processed. 3292 Example: 3294 The little league coach places the teams entire schedule into your 3295 calendar. Lets say that every game and practice is on a Friday night 3296 and your calendar now has this iTIP scheduling data: 3298 BEGIN:VCALENDAR 3299 VERSION:2.0 3300 METHOD:PUBLISH 3301 BEGIN:VEVENT 3302 DTSTAMP;TZID=US/Pacific:20000229T180000 3303 DTSTART;TZID=US/Pacific:20000303T180000 3304 ORGANIZER:coach@little.league.com 3305 SUMMARY:Schedule of games and practice 3306 UID:1-coach@little.league.com 3307 SEQUENCE:0 3308 DESCRIPTION:Please have your child at the field 3309 and ready to play by 6pm. 3310 RRULE:FREQ=WEEKLY;COUNT=10 3311 END:VEVENT 3312 END:VCALENDAR 3314 At this point the above VEVENT is not booked in your calendar; it is 3315 simply scheduled. A CUA would fetch this and all other scheduled 3316 VEVENTs from your calendar with: 3318 C: MSG 1 19 . 19737 582 3319 C: Content-Type: multipart/related; boundary="boundary-rtij41"; 3320 C: start="1@cal.example.com"; 3321 C: type="application/beep+xml" 3322 C: 3323 C: --boundary-rtij41 3324 C: Content-Type: application/beep+xml 3325 C: Content-ID: 1@cal.example.com 3326 C: 3327 C: 3328 C: 3332 C: 3333 C: --boundary-rtij41 3334 C: Content-Type: text/calendar 3335 C: Content-ID: query@cal.example.com 3336 C: 3337 C: BEGIN:VCALENDAR 3338 C: BEGIN:VQUERY 3339 C: QUERY:SELECT * WHERE FROM VEVENT METHOD IS NOT NULL 3340 C: END:VQUERY 3341 C: END:VCALENDAR 3342 C: --boundary-rtij41-- 3343 C: END 3345 The CUA and CU could determine which scheduling entries were to 3346 remain on the calendar. Each scheduling component could be deleted 3347 or updated with the "modify" command to remove the iTip METHOD. 3349 In some cases the CUA could automatically do the work and inform the 3350 CU. An example of this is CANCEL. If configured to process 3351 METHOD:CANCEL it could execute the "delete" command to delete the 3352 component and inform the CU that the booked component had been 3353 canceled. 3355 The CUA MUST process the scheduled components in the order sent. 3356 Some optimization could be done by the CUA. One example is if a 3357 PUBLISH and later a CANCEL for the same component with the same 3358 SEQUENCE number were scheduled, but not booked. The CUA might never 3359 inform the CU and treat it as if the PUBLISH had never been received 3360 by doing a "delete" command on both entries. 3362 It is important to note that scheduled components do not show up in 3363 busy time as BUSY. Only when they are booked does the TRANSP:OPAQUE 3364 property take effect. A CS implementation MAY mark the time as 3365 TENTATIVE. This is an implementation and administrative choice. 3367 The CS MAY automatically process some iTIP request. For example a CS 3368 MAY automatically send out REFRESH replies via iMIP or CAP, then 3369 delete the REFRESH entry. But only if there are no other pending 3370 scheduled entries for this calendar that may affect what REFRESH 3371 would send back. If the CS is not able to reply to the REFRESH 3372 request then it is left in the scheduling set until the CUA and CU 3373 processes the set. At the point where there are no outstanding 3374 scheduled command that would effect the reply results, the CS may 3375 then automatically send the reply to the REFRESH request. 3377 6.3.3 iTIP Examples 3379 The following examples describe scenarios for the handling of 3380 incoming iTIP data. An appropriate sort-order for the handling of 3381 incoming iTIP is by UID, Recurrence-id, sequence, dtstamp. This 3382 processing may be optimized, for instance, REFRESHs could be 3383 processed last. 3385 As an update to [iTIP], data with the "COUNTER" method should be 3386 processed even if the Sequence number is stale. 3388 6.3.3.1 Sending and Receiving an iTIP request 3390 In this example A invites B and C to a meeting, B accepts the meeting 3391 and C rejects it. The calendars for A, B and C are relcal1, relcal2 3392 and relcal3 respectively, and are all on the same server, 3393 "cal.example.com". A lot of these described actions are performed by 3394 the CUAs and not the users themselves, the CUAs are called A-c, B-c 3395 and C-c respectively. 3397 A wishes to create a meeting with B and C, so A-c uses CAP to send 3398 the following iTIP request to relcal2 and relcal3, while logged in to 3399 "cal.example.com". 3401 C: MSG 1 20 . 22254 874 3402 C: Content-Type: multipart/related; boundary="boundary-rewf4"; 3403 C: start="1@cal.example.com; 3404 C: type="application/beep+xml" 3405 C: 3406 C: --boundary-rewf4 3407 C: Content-Type: application/beep+xml 3408 C: Content-ID: 1@cal.example.com 3409 C: 3410 C: 3411 C: 3412 C: 3413 C: 3416 C: 3417 C: --boundary-rewf4 3418 C: Content-Type: text/calendar 3419 C: Content-ID: request@cal.example.com 3420 C: 3421 C: BEGIN:VCALENDAR 3422 C: VERSION:2.1 3423 C: METHOD:REQUEST 3424 C: BEGIN:VEVENT 3425 C: UID:abcd12345 3426 C: DTSTART:19990307T180000Z 3427 C: DTEND:19990307T190000Z 3428 C: ORGANIZER:cap://cal.example.com/relcal1 3429 C: ATTENDEE;RSVP=TRUE; 3430 C: PARTSTAT=NEEDS-ACTION:cap://cal.example.com/relcal2 3431 C: ATTENDEE;RSVP=TRUE; 3432 C: PARTSTAT=NEEDS-ACTION:cap://cal.example.com/relcal3 3433 C: SUMMARY:Important Meeting 3434 C: END:VEVENT 3435 C: END:VCALENDAR 3436 C: --boundary-rewf4-- 3437 C: END 3439 An incoming event (indicated by the value of the "METHOD" property) 3440 then appears in relcal2 and relcal3, with the following data: 3442 BEGIN:VEVENT 3443 METHOD:REQUEST 3444 UID:abcd12345 3445 DTSTART:19990307T180000Z 3446 DTEND:19990307T190000Z 3447 ORGANIZER:cap://cal.example.com/relcal1 3448 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.example.c 3449 om/relcal2 3450 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.example.c 3451 om/relcal3 3452 SUMMARY:Important Meeting 3453 END:VEVENT 3455 B-c and C-c must search for such incoming events, they do so using 3456 the following CAP search: 3458 C: MSG 1 21 . 24655 631 3459 C: Content-Type: multipart/related; boundary="boundary-ytem"; 3460 C: start="1@cal.example.com"; 3461 C: type="application/beep+xml" 3462 C: 3463 C: --boundary-ytem 3464 C: Content-Type: application/beep+xml 3465 C: Content-ID: 1@cal.example.com; 3466 C: 3467 C: 3468 C: 3469 C: 3474 C: 3475 C: --boundary-ytem 3476 C: Content-Type: text/calendar 3477 C: Content-ID: 2@cal.example.com 3478 C: 3479 C: BEGIN:VCALENDAR 3480 C: VERSION:2.1 3481 C: BEGIN:VQUERY 3482 C: QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST'; 3483 C: END:VQUERY 3484 C: END:VCALENDAR 3485 C: --boundary-ytem-- 3486 C: END 3488 In response to this search they get the above event. B-c and C-c 3489 must then open the VEVENT, find the UID and determine if there is 3490 already an event on their calendar with that UID. To do this they 3491 use the following search: 3493 C: MSG 1 22 . 26087 654 3494 C: Content-Type: multipart/related; boundary="boundary-rtylk"; 3495 C: start="1@cal.example.com"; 3496 C: type="application/beep+xml" 3497 C: 3498 C: --boundary-rtylk 3499 C: Content-Type: application/beep+xml 3500 C: Content-ID: 1@cal.example.com; 3501 C: 3502 C: 3503 C: 3504 C: 3509 C: 3510 C: --boundary-rtylk 3511 C: Content-Type: text/calendar 3512 C: Content-ID: 2@cal.example.com 3513 C: 3514 C: BEGIN:VCALENDAR 3515 C: VERSION:2.1 3516 C: BEGIN:VQUERY 3517 C: QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' AND 3518 C: METHOD IS NULL 3519 C: END:VQUERY 3520 C: END:VCALENDAR 3521 C: --boundary-rtylk-- 3522 C: END 3524 We assume that the event is not already in their relcal2 or relcal3. 3526 B-c prompts B who decides to accept the meeting request, and B-c 3527 creates a copy of the event in relcal2, with the "PARTSTAT" parameter 3528 set to ACCEPTED. B-c also sends this copy to the Organizer at 3529 relcal1 as an iTIP REPLY, preserving the CMDID: 3531 C: MSG 1 23 . 26741 697 3532 C: Content-Type: multipart/related; boundary="boundary-1943"; 3533 C: start="1@cal.example.com"; 3534 C: type="application/beep+xml" 3535 C: 3536 C: --boundary-1943 3537 C: Content-Type: application/beep+xml 3538 C: Content-ID: 1@cal.example.com; 3539 C: 3540 C: 3541 C: 3542 C: 3543 C: 3544 C: --boundary-1943 3545 C: Content-Type: text/calendar 3546 C: Content-ID: 2@cal.example.com 3547 C: 3548 C: BEGIN:VCALENDAR 3549 C: VERSION:2.1 3550 C: METHOD:REPLY 3551 C: BEGIN:VEVENT 3552 C: UID:abcd12345 3553 C: DTSTART:19990307T180000Z 3554 C: DTEND:19990307T190000Z 3555 C: ORGANIZER:cap://cal.example.com/relcal1 3556 C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2 3557 C: SUMMARY:Important Meeting 3558 C: END:VEVENT 3559 C: END:VCALENDAR 3560 C: --boundary-1943-- 3561 C: END 3563 C, on the other hand, decides to decline the meeting, and C-c sends a 3564 reply to the Organizer to that effect, as follows: 3566 C: MSG 1 24 . 27438 705 3567 C: Content-Type: multipart/related; boundary="boundary-oiudfc"; 3568 C: start="1@cal.example.com"; 3569 C: type="application/beep+xml" 3570 C: 3571 C: --boundary-oiudfc 3572 C: Content-Type: application/beep+xml 3573 C: Content-ID: 1@cal.example.com; 3574 C: 3575 C: 3576 C: 3577 C: 3578 C: 3579 C: --boundary-oiudfc 3580 C: Content-Type: text/calendar 3581 C: Content-ID: 2@cal.example.com 3582 C: 3583 C: BEGIN:VCALENDAR 3584 C: VERSION:2.1 3585 C: METHOD:REPLY 3586 C: BEGIN:VEVENT 3587 C: UID:abcd12345 3588 C: DTSTART:19990307T180000Z 3589 C: DTEND:19990307T190000Z 3590 C: ORGANIZER:cap://cal.example.com/relcal1 3591 C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3 3592 C: SUMMARY:Important Meeting 3593 C: END:VEVENT 3594 C: END:VCALENDAR 3595 C: --boundary-oiudfc-- 3596 C: END 3598 It is preferable that C-c stores the event in relcal3 even though it 3599 has been declined. Storing the event in relcal3 allows subsequent 3600 iTIP messages to be interpreted correctly. The "PARTSTAT" parameter 3601 indicates that the event was refused. 3603 After receiving the replies from relcal2 and relcal3, A-c updates the 3604 version of the event in relcal1 to indicate the new participation 3605 status: 3607 C: MSG 1 25 . 29450 934 3608 C: Content-Type: multipart/related; boundary="boundary-wer3"; 3609 C: start="1@cal.example.com"; 3610 C: type="application/beep+xml" 3611 C: 3612 C: --boundary-wer3 3613 C: Content-Type: application/beep+xml 3614 C: Content-ID: 1@cal.cal.example.com 3615 C: 3616 C: 3617 C: 3621 C: 3622 C: 3623 C: 3624 C: 3625 C: --boundary-wer3 3626 C: Content-Type: text/calendar 3627 C: Content-ID: query@cal.example.com 3628 C: 3629 C: BEGIN:VCALENDAR 3630 C: BEGIN:VQUERY 3631 C: QUERY: SELECT * FROM VEVENT WHERE UID='abcd12345' 3632 C: END:VQUERY 3633 C: END:VCALENDAR 3634 C: --boundary-wer3 3635 C: Content-Type: text/calendar 3636 C: Content-ID: update@cal.example.com 3637 C: 3638 C: BEGIN:VCALENDAR 3639 C: BEGIN:VEVENT 3640 C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2 3641 C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3 3642 C: END:VEVENT 3643 C: END:VCALENDAR 3644 C: --boundary-wer3-- 3645 C: END 3647 A-c then sends a new iTIP request to relcal2 only, indicating the 3648 updated information. 3650 6.3.3.2 Handling an iTIP refresh 3652 A little bit later, C is thinking about accepting the event in the 3653 previous example, but first wants to check the current state of the 3654 event. To find the current state C-c uses the iTIP "REFRESH" method, 3655 sending the following to relcal1: 3657 C: MSG 1 26 . 31005 649 3658 C: Content-Type: multipart/related; boundary="boundary-fsdk3"; 3659 C: start="1@cal.example.com"; 3660 C: type="application/beep+xml" 3661 C: 3662 C: --boundary-fsdk3 3663 C: Content-Type: application/beep+xml 3664 C: Content-ID: 1@cal.example.com 3665 C: 3666 C: 3667 C: 3668 C: 3669 C: 3670 C: --boundary-fsdk3 3671 C: Content-Type: text/calendar 3672 C: Content-ID: refresh@cal.example.com 3673 C: 3674 C: BEGIN:VCALENDAR 3675 C: VERSION:2.1 3676 C: METHOD:REFRESH 3677 C: BEGIN:VEVENT 3678 C: UID:abcd12345 3679 C: ORGANIZER:cap://cal.example.com/relcal1 3680 C: ATTENDEE:cap://cal.example.com/relcal3 3681 C: DTSTAMP:19990306T202333Z 3682 C: END:VEVENT 3683 C: END:VCALENDAR 3684 C: --boundary-fsdk3-- 3685 C: END 3687 A-c finds the refresh as an incoming iTIP, and searches for the 3688 corresponding event. Having found the event (with no changes since 3689 the last example) A-c then verifies that relcal3 is in fact an 3690 attendee of the event and is thus allowed to request a refresh. (In 3691 the case of a published event things are more complicated.) A-c 3692 packages the event as an iTIP request and sends it to relcal3: 3694 C: MSG 1 27 . 32541 856 3695 C: Content-Type: multipart/related; boundary="boundary-trekvg"; 3696 C: start="1@cal.example.com"; 3697 C: type="application/beep+xml" 3698 C: 3699 C: --boundary-trekvg 3700 C: Content-Type: application/beep+xml 3701 C: Content-ID: 1@cal.example.com 3702 C: 3703 C: 3704 C: 3705 C: 3706 C: 3707 C: --boundary-trekvg 3708 C: Content-Type: text/calendar 3709 C: Content-ID: request@cal.example.com 3710 C: 3711 C: BEGIN:VCALENDAR 3712 C: VERSION:2.1 3713 C: METHOD:REQUEST 3714 C: TARGET:cap://cal.example.com/relcal3 3715 C: BEGIN:VEVENT 3716 C: UID:abcd12345 3717 C: DTSTART:19990307T180000Z 3718 C: DTEND:19990307T190000Z 3719 C: ORGANIZER:cap://cal.example.com/relcal1 3720 C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2 3721 C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3 3722 C: SUMMARY:Important Meeting 3723 C: SEQUENCE:0 3724 C: DTSTAMP:19990306T204333Z 3725 C: END:VEVENT 3726 C: END:VCALENDAR 3727 C: --boundary-trekvg-- 3728 C: END 3730 6.3.3.3 Sending and accepting an iTIP counter 3732 Having received the latest copy of the event C wishes to propose a 3733 venue for the event, using an iTIP COUNTER. To do this C-c sends the 3734 following to relcal1: 3736 C: MSG 1 28 . 34587 883 3737 C: Content-Type: multipart/related; boundary="boundary-werf"; 3738 C: start="1@cal.example.com"; 3739 C: type="application/beep+xml" 3740 C: 3741 C: --boundary-werf 3742 C: Content-Type: application/beep+xml 3743 C: Content-ID: 1@cal.example.com 3744 C: 3745 C: 3746 C: 3747 C: 3748 C: 3749 C: --boundary-werf 3750 C: Content-Type: text/calendar 3751 C: Content-ID: counter@cal.example.com 3752 C: 3753 C: BEGIN:VCALENDAR 3754 C: VERSION:2.1 3755 C: METHOD:COUNTER 3756 C: BEGIN:VEVENT 3757 C: UID:abcd12345 3758 C: DTSTART:19990307T180000Z 3759 C: DTEND:19990307T190000Z 3760 C: SEQUENCE:0 3761 C: ORGANIZER:cap://cal.example.com/relcal1 3762 C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2 3763 C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3 3764 C: SUMMARY:Important Meeting 3765 C: LOCATION:La Belle Province 3766 C: COMMENT:My favorite restaurant, I'll definitely go if it's 3767 C: there. 3768 C: END:VEVENT 3769 C: END:VCALENDAR 3770 C: --boundary-werf-- 3771 C: END 3773 Having sent the information to relcal1, C-c shouldn't store the new 3774 details in relcal3. If C-c updated the version in relcal3 and 3775 relcal1 did not reply to the counter, then relcal3 would have 3776 incorrect information. Instead C-c preserves the correct information 3777 and waits for a response from relcal1. A CUA implementation may wish 3778 to preserve this information itself, externally to the CS. 3780 In order to receive an iTIP counter A-c follows the same search as 3781 for other iTIP data, first find the incoming message, next find any 3782 matching events in the calendar store. 3784 Having found the matching event, A reviews the proposed changes and 3785 decides to accept the COUNTER. To do this, A-c modifies the version 3786 in relcal1 (bumping the sequence number) to: 3788 C: MSG 1 29 . 37650 850 3789 C: Content-Type: multipart/related; boundary="boundary-kmcrf"; 3790 C: start="1@cal.example.com"; 3791 C: type="application/beep+xml" 3792 C: 3793 C: --boundary-kmcrf 3794 C: Content-Type: application/beep+xml 3795 C: Content-ID: 1@cal.cal.example.com 3796 C: 3797 C: 3798 C: 3802 C: 3803 C: 3804 C: 3805 C: 3806 C: --boundary-kmcrf 3807 C: Content-Type: text/calendar 3808 C: Content-ID: query@cal.example.com 3809 C: 3810 C: BEGIN:VCALENDAR 3811 C: BEGIN:VQUERY 3812 C: QUERY: SELECT * FROM VEVENT WHERE UID='abcd12345' 3813 C: END:VQUERY 3814 C: END:VCALENDAR 3815 C: --boundary-kmcrf 3816 C: Content-Type: text/calendar 3817 C: Content-ID: update@cal.example.com 3818 C: 3819 C: BEGIN:VCALENDAR 3820 C: BEGIN:VEVENT 3821 C: LOCATION:La Belle Province 3822 C: SEQUENCE:1 3823 C: END:VCALENDAR 3824 C: --boundary-kmcrf-- 3825 C: END 3827 A-c then sends the updated version as a request to both relcal2 and 3828 relcal3: 3830 C: MSG 1 30 . 39450 909 3831 C: Content-Type: multipart/related; boundary="boundary-plmng"; 3832 C: start="1@cal.example.com"; 3833 C: type="application/beep+xml" 3834 C: 3835 C: --boundary-plmng 3836 C: Content-Type: application/beep+xml 3837 C: Content-ID: 1@cal.example.com 3838 C: 3839 C: 3840 C: 3841 C: 3842 C: 3843 C: 3844 C: --boundary-plmng 3845 C: Content-Type: text/calendar 3846 C: Content-ID: request@cal.example.com 3847 C: 3849 C: BEGIN:VCALENDAR 3850 C: VERSION:2.1 3851 C: METHOD:REQUEST 3852 C: BEGIN:VEVENT 3853 C: UID:abcd12345 3854 C: DTSTART:19990307T180000Z 3855 C: DTEND:19990307T190000Z 3856 C: ORGANIZER:cap://cal.example.com/relcal1 3857 C: ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- 3858 C: ACTION:cap://cal.example.com/relcal2 3859 C: ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- 3860 C: ACTION:cap://cal.example.com/relcal3 3861 C: SUMMARY:Important Meeting 3862 C: LOCATION:La Belle Province 3863 C: SEQUENCE:1 3864 C: DTSTAMP:19990307T054339Z 3865 C: END:VEVENT 3866 C: END:VCALENDAR 3867 C: --boundary-plmng-- 3868 C: END 3870 6.3.3.4 Declining an iTIP counter 3872 B does not like the new location and also counters the event, B-c 3873 sends the following iTIP: 3875 C: MSG 1 31 . 41620 762 3876 C: Content-Type: multipart/related; boundary="boundary-cafe3"; 3877 C: start="1@cal.example.com"; 3878 C: type="application/beep+xml" 3879 C: 3880 C: --boundary-cafe3 3881 C: Content-Type: application/beep+xml 3882 C: Content-ID: 1@cal.example.com 3883 C: 3884 C: 3885 C: 3886 C: 3887 C: 3888 C: --boundary-cafe3 3889 C: Content-Type: text/calendar 3890 C: Content-ID: counter@cal.example.com 3891 C: 3892 C: BEGIN:VCALENDAR 3893 C: VERSION:2.1 3894 C: METHOD:COUNTER 3895 C: BEGIN:VEVENT 3896 C: UID:abcd12345 3897 C: DTSTART:19990307T180000Z 3898 C: DTEND:19990307T190000Z 3899 C: ORGANIZER:cap://cal.example.com/relcal1 3900 C: ATTENDEE:cap://cal.example.com/relcal2 3901 C: ATTENDEE:cap://cal.example.com/relcal3 3902 C: SUMMARY:Important Meeting 3903 C: LOCATION:Guy et Dodo 3904 C: END:VEVENT 3905 C: END:VCALENDAR 3906 C: --boundary-cafe3-- 3907 C: END 3909 However, C does not accept the counter, and C-c replies with a 3910 decline counter: 3912 C: MSG 1 32 . 42901 631 3913 C: Content-Type: multipart/related; boundary="boundary-meme34"; 3914 C: start="1@cal.example.com"; 3915 C: type="application/beep+xml" 3916 C: 3917 C: --boundary-meme34 3918 C: Content-Type: application/beep+xml 3919 C: Content-ID: 1@cal.example.com 3920 C: 3921 C: 3922 C: 3923 C: 3924 C: 3925 C: --boundary-meme34 3926 C: Content-Type: text/calendar 3927 C: Content-ID: decline-counter@cal.example.com 3928 C: 3929 C: BEGIN:VCALENDAR 3930 C: VERSION:2.1 3931 C: METHOD:DECLINE-COUNTER 3932 C: BEGIN:VEVENT 3933 C: DTSTAMP:19990307T093245Z 3934 C: UID:abcd12345 3935 C: ORGANIZER:cap://cal.example.com/relcal1 3936 C: SEQUENCE:1 3937 C: END:VEVENT 3938 C: END:VCALENDAR 3939 C: --boundary-meme34-- 3940 C: END 3942 CUA-b MUST keep the original information when sending the counter, 3943 and there is no problem when no information is returned in the 3944 DECLINE-COUNTER. 3946 7. Response Codes 3948 Numeric response codes are returned at both the transfer and 3949 application layer. The same set of codes is used in both cases. 3951 [EDITORS NOTE: Do we want to use the same set of codes?] 3953 The format of these codes is described in [iCAL], and extend in 3954 [iTIP] and [iMIP]. The following describes new codes added to this 3955 set. 3957 At the application layer response codes are returned as the value of 3958 a "REQUEST-STATUS" property. The value type of this property is 3959 modified from that defined in [iCAL], to make the accompanying text 3960 optional. 3962 Code Description 3963 -------------------------------------------------------------- 3964 2.0 Success. The parameters vary with the 3965 operation and are specified. 3967 2.0.3 In response to the client issuing an 3968 "abort" reply, this reply code indicates 3969 that any command currently underway was 3970 successfully aborted. 3972 3.1.4 Capability not supported. 3974 4.1 Calendar store access denied. 3976 6.3 Attempt to create or modify an event 3977 such that it would overlap another event 3978 in either of the following two circum- 3979 stances: 3981 (a) One of the events has a TRANSP 3982 property set to OPAQUE-NOCONFLICT or 3983 TRANSPARENT-NOCONFLICT. 3985 (b) The calendar's ALLOW-CONFLICT 3986 property is set to NO. 3988 6.XXX [EDITORS NOTE: More are in this memo - 3989 add here TODO] 3991 7.0 A timeout has occurred. The server was 3992 unable to complete the operation in the 3993 requested time. 3995 8.0 A failure has occurred in the Calendar Service 3996 that prevents the operation from 3997 succeeding. 3999 8.2 Used to signal that an iCalendar object has 4000 exceeded the server's size limit 4002 8.3 A DATETIME value was too far in the future 4003 represented on this Calendar. 4005 8.4 A DATETIME value was too far in the past 4006 to be represented on this Calendar. 4008 8.5 An attempt was made to create a new 4009 object but the unique id specified is 4010 already in use. 4012 9.0 An unrecognized command was received. 4014 10.4 The operation has not been performed 4015 because it would cause the resources 4016 (memory, disk, CPU, etc) to exceed the 4017 allocated quota. 4018 -------------------------------------------------------------- 4020 8. BEEP Profile Registration 4022 Profile Identification: 4023 http://iana.org/beep/transient/calsch/cap/1.0 4025 Messages exchanged during Channel Creation: none 4027 Messages starting one-to-one exchanges: 4029 "timeout", "generate-uid", "identify", "get-capability" 4031 Messages in positive replies: 4033 "uid-list", "abort", "continue", "result", "capability" 4035 Messages in negative replies: 4037 "error" 4039 Messages in one-to-many exchanges: "create", "search", "delete", 4040 "modify" or "schedule" 4042 Message Syntax: c.f., Section 9 4044 Message Semantics: c.f., Section 6 4046 Contact Information: c.f., the "Author's Address" section of this 4047 memo 4049 9. CAP DTD 4051 4055 4056 %CAP; 4058 4072 4073 4074 4075 4076 4077 4078 4079 4081 4082 4084 4085 4087 4088 4090 4091 4093 4094 4096 4097 4099 4100 4103 4104 4105 action (ask|abort) "abort"> 4107 4108 4110 4112 4113 4117 4118 4120 4121 4123 4124 4126 4127 4129 4130 4132 4133 4135 4136 4138 4140 4141 4143 4144 4145 4147 4149 4151 4152 4154 4155 4156 4158 4159 4161 4162 4164 4166 10. Implementation Issues 4168 1. What are the minimum component properties set required to create 4169 a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and 4170 UID. 4172 [EDITORS NOTE (dr): They MUST be the same as for iTIP] 4174 2. What is the state of all undefined properties? PROPOSAL: Not 4175 defined. So a query will not return them, if they are selected. 4177 [EDITORS NOTE (dr): Many have default values, a CS may return the 4178 default values?] 4180 11. Properties 4182 [EDITORS NOTE: These extensions/changes to iCalendar need to be 4183 reformatted to conform to the IANA registration process defined in 4184 section 7 of [iCAL].] 4186 11.1 Calendar Store Properties 4188 The following are properties of the calendar store. 4190 Name Read Value Description 4191 Only Type 4192 -------------------------------------------------------------- 4193 CALMASTER N URI The e-mail address for a 4194 responsible person. MUST be a 4195 mailto URL. 4197 CSID Y URI The CSID of this calendar 4198 store. If not specified, it is 4199 the same as the hostname. 4201 DEFAULT_VCARS N TEXT A multivalued property 4202 containing the default VCARs 4203 for newly created top level 4204 calendars. Each entry is a 4205 CARID. It MUST include at a 4206 minimum 4207 READBUSYTIMEINFO,REQUESTONLY, 4208 UPDATEPARTSTATUS, and 4209 DEFAULTOWNER. 4211 MAXDATE Y DATE-TIME The date/time in the future 4212 beyond which the server cannot 4213 represent. If not specified, 4214 then 99991231T235959 will be 4215 assumed. 4217 MINDATE Y DATE-TIME The date/time in the past prior 4218 to which the server cannot 4219 represent. If not specified, 4220 then 00000101T000000 will be 4221 assumed. 4223 CURRENT_DATETIME Y DATE-TIME Current server time. This is 4224 returned as a local time and 4225 TZID. 4227 RECUR_ACCEPTED Y BOOLEAN Boolean value will be set to 4228 TRUE if the server will accept 4229 recurrence rules. It will be 4230 set to FALSE if the server will 4231 not accept recurrence rules. If 4232 not specified a CUA MUST assume 4233 TRUE. 4235 RECUR_EXPAND Y BOOLEAN If set to TRUE, the CS supports 4236 the expansion of recurrence 4237 rules. If set to FALSE, the CS 4238 is incapable of expanding 4239 recurrence rules. If not 4240 specified a CUA MUST assume 4241 TRUE. 4243 RECUR_LIMIT Y INTEGER This numeric value describes 4244 how the server handles 4245 unbounded recurrences. The 4246 value is only valid if 4247 RECURRENCE is TRUE. If the 4248 value is 0 it means that the 4249 server supports unbounded 4250 recurrence rules. If it is non- 4251 zero, it is a positive integer 4252 indicating the number of 4253 instances that will be created 4254 when the server expands an 4255 unbounded recurrence rule when 4256 fetched from the CS. A CUA MUST 4257 query for date ranges when this 4258 value is zero. 4260 VERSION Y TEXT The version of the CS. The 4261 default and the only currently 4262 Supported version is "2.0" to 4263 match the [iCAL] VERSION. 4265 11.2 Calendar Properties 4267 Name Read Value Description 4268 Only Type 4269 -------------------------------------------------------------- 4270 ALLOW-CONFLICT N BOOLEAN This boolean value indicates 4271 Whether or not the calendar 4272 supports event conflicts. That 4273 is, whether or not any of the 4274 events in the calendar can 4275 overlap. If not specified the 4276 default value is TRUE meaning 4277 that conflicts are allowed. 4279 CALSCALE N TEXT The CALSCALE for this calendar. 4280 If not specified the default is 4281 GREGORIAN. 4283 CHARSET N TEXT The default charset for 4284 Localized strings in this 4285 calendar. If not specified, the 4286 default is UTF-8. 4288 CHILDREN Y TEXT The list of sub-calendars 4289 Belonging to this calendar. An 4290 empty list means no children. 4291 The results may be a comma 4292 separated list of children. 4293 Each entry returned is a CALID. 4294 The default is an empty list. 4296 CREATED Y DATE-TIME The timestamp of the calendar's 4297 create date. 4299 DEFAULT_VCARS N TEXT The default VCARs for newly 4300 Created top level calendars. 4301 This is a CARID. The default 4302 value is the value of 4303 DEFAULT_VCARS in the CALSTORE 4304 table. 4306 LANGUAGE N TEXT The default language for 4307 localizable strings in this 4308 calendar. There is no default. 4309 This value MUST NOT be empty. 4311 LAST-MODIFIED N DATE-TIME The timestamp when the 4312 Properties of the calendar were 4313 last updated. Default is the 4314 same as CREATED. 4316 NAME N TEXT The display name for this 4317 calendar. It is a localizable 4318 string. If not provided, an 4319 empty value will be returned. 4321 OWNER N URI A multi-instanced property 4322 indicating the calendar owner. 4324 Each entry returned will be a 4325 UPN. There must be at least one 4326 owner. 4328 PARENT N URI The CALID of this calendar's 4329 Parent maintained by a CAP 4330 server. An empty value means 4331 the calendar is the top level 4332 parent. The default value is no 4333 parent. 4335 RELCALID N URI A unique identifier for the calendar. 4336 There is no default value and 4337 This value MUST NOT be empty. 4339 TOMBSTONE N BOOLEAN TRUE indicator that this 4340 Calendar has been marked as 4341 deleted. The default value is 4342 FALSE. 4344 TZID N TEXT The id of the timezone 4345 Associated with this calendar. 4346 See TZID in [iCAL]. The default 4347 value is UTC. 4349 12. CAP Item Registration 4351 This section provides the process for registration of new or modified 4352 CAP entities. 4354 12.1 Registration of New and Modified CAP Entities 4356 New CAP entities are registered by the publication of an IETF Request 4357 for Comment (RFC). Changes to a CAP item are registered by the 4358 publication of a revision of the RFC defining the method. 4360 12.2 Registration of New Entities 4362 This section defines procedures by which new entities (i.e., 4363 components, properties, parameters, enumerated values or restriction 4364 tables) for a CAP item can be registered with the IANA. 4366 Non-standard, experimental entities can be used by bilateral 4367 agreement, provided the associated properties names follow the "X-" 4368 convention. Such non-standard and experimental entities are non-IANA 4369 entities and need not be registered using this process. 4371 The procedures defined here are designed to allow public comment and 4372 review of new CAP entities, while posing only a small impediment to 4373 the definition of new properties. 4375 Registration of a new CAP item is accomplished by the following 4376 steps. 4378 12.2.1 Define the Item 4380 A CAP item is defined by completing the following template. 4382 To: ietf-calendar@imc.org 4383 Subject: Registration of CAP item XXX 4384 Item name: 4385 Item purpose: 4386 Description: 4387 CAP terminology changes: 4388 CAP data model changes: 4389 CAP system model changes: 4390 Conformance considerations: 4391 Format definition: 4392 Examples: 4394 The meaning of each field in the template is as follows. 4396 Item name: The name of the item. 4398 Item purpose: The purpose of the item (e.g., Extends the CAP 4399 command set to poll for notifications, etc.). Give a short but 4400 clear description. 4402 Description: Any special notes about the item, how it is to be 4403 used, etc. 4405 CAP terminology changes: Any change or additions to the existing 4406 CAP terminology needs to be specified. 4408 CAP data model changes: Any of the valid property parameters for 4409 the property needs to be specified. 4411 CAP system model changes: 4413 Conformance: A clear summary of how and where this CAP item 4414 extension MUST, MAY, SHOULD or can be used. Any changes or impact 4415 to the existing conformance definition for CAP should be 4416 explained. The impact to implementations conforming to the 4417 existing CAP specification should be clearly described. 4419 Format definition: The ABNF for each element of the CAP item needs 4420 to be specified. 4422 Examples: One or more examples of instances of the CAP item and 4423 each of its usage scenarios needs to be specified. 4425 12.2.2 Post the item definition 4427 The item description MUST be posted to the new item discussion list, 4428 ietf-calendar@imc.org. 4430 12.2.3 Allow a comment period 4432 Discussion on the new item MUST be allowed to take place on the list 4433 for a minimum of two weeks. Consensus MUST be reached on the 4434 property before proceeding to the next step. 4436 12.2.4 Submit the proposal for approval 4438 Once the two-week comment period has elapsed, and the proposer is 4439 convinced consensus has been reached on the proposal, the 4440 registration application should be submitted to the Method Reviewer 4441 for approval. The Method Reviewer is appointed by the Application 4442 Area Directors and can either accept or reject the proposal 4443 registration. An accepted registration should be passed on by the 4444 Method Reviewer to the IANA for inclusion in the official IANA method 4445 registry. The registration can be rejected for any of the following 4446 reasons. 1) Insufficient comment period; 2) Consensus not reached; 4447 3) Technical deficiencies raised on the list or elsewhere have not 4448 been addressed. The Method Reviewers decision to reject a proposal 4449 can be appealed by the proposer to the IESG, or the objections raised 4450 can be addressed by the proposer and the proposal resubmitted. 4452 [EDITORS NOTE: John Stracke to review any updates] 4454 12.3 Property Change Control 4456 Existing CAP entities can be changed using the same process by which 4457 they were registered. 4459 1. Define the change 4461 2. Post the change 4463 3. Allow a comment period 4465 4. Submit the proposal for approval 4467 Note that the original author or any other interested party can 4468 propose a change to an existing CAP object, but that such changes 4469 should only be proposed when there are serious omissions or errors in 4470 the published memo. The Method Reviewer can object to a change if it 4471 is not backward compatible, but is not required to do so. 4473 CAP objects definitions can never be deleted from the IANA registry, 4474 but objects which are no longer believed to be useful can be declared 4475 OBSOLETE by adding this text to their "Item purpose" field. 4477 13. IANA Considerations 4479 This memo defines IANA registered extensions to the attributes 4480 defined by iCalendar, as defined in [iCAL], and [iTIP]. 4482 IANA registration proposals for iCalendar and iTIP are to be mailed 4483 to the registration agent for the "text/calendar" [MIME] content- 4484 type, using the format defined in 4485 section 7 of [iCAL]. 4487 Authors' Addresses 4489 Steve Mansour 4490 AOL/Netscape 4491 466 Ellis Road 4492 Mountain View, CA 94043 4493 US 4495 Phone: +1-650-937-3351 4496 EMail: sman@netscape.com 4498 Doug Royer 4499 INET-Consulting LLC 4500 1795 W. Broadway #266 4501 Idaho Falls, ID 83402 4503 Phone: 208-520-4044 4504 EMail: Doug@royer.com 4506 George Babics 4507 Steltor 4508 2000 Peel Street 4509 Montreal, Quebec H3A 2W5 4510 CA 4512 Phone: +1-514-733-8500 x4201 4513 Fax: +1-514-733-8878 4514 EMail: georgeb@steltor.com 4515 Paul Hill 4516 Massachusetts Institute of Technology 4517 W92-172 4518 77 Massachusetts Avenue 4519 Cambridge, MA 02139 4520 US 4522 Phone: +1-617-253-0124 4523 Fax: +1-617-258-8736 4524 EMail: phb@mit.edu 4526 Appendix A. Acknowledgments 4528 The following have individuals were major contributors in the 4529 drafting and discussion of this memo: 4531 Harald Alvestrand, Mario Bonin, Andre Courtemanche, Dave Crocker, 4532 Bernard Desruisseaux, Pat Egen, Gilles Fortin, Jeff Hodges, Alex 4533 Hoppman, Bruce Kahn, Lisa Lippert, David Madeo, Bob Mahoney, Bob 4534 Morgan, Patrice Lapierre, Pete O'Leary, Richard Shusterman, Tony 4535 Small, John Stracke, Alexander Taler, Mark Wahl. 4537 Appendix B. Bibliography 4539 [BEEP] Rose, "The Block Extensible Exchange Protocol Core", RFC 4540 3080, March 2001 4542 [BEEPTCP] Rose, "Mapping the BEEP Core onto TCP", RFC 3081, March 4543 2001 4545 [MIME] N. Borenstein and N. Freed, "MIME (Multipurpose Internet 4546 Mail Extensions) Part One: Mechanisms for Internet Draft UTF-825 4547 July 1996 4549 [RFC 3087] Campbell, Sparks, "Control of Service Context using SIP 4550 Request-URI", RFC 3087, April 2001 4552 [RFC 2392] Levinson, "Content-ID and Message-ID Uniform Resource 4553 Locators", RFC 2392, August 1998 4555 Specifying and Describing the Format of Internet Message Bodies", 4556 RFC 1521, Bellcore, Innosoft, September 1993. 4558 [TLS] Dierks, Allen, "The TLS Protocol", RFC 2246, January 1999 4560 [RFC2119] TODO... 4562 [SASL] RFC2222 TODO... 4564 [URL] Berners-Lee, Fielding, Masinter, "Uniform Resource 4565 Identifiers 4567 (URI): Generic Syntax", RFC 2396, August 1998. 4569 [iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling 4570 Core Object Specification (iCalendar)", RFC 2445, November 1998 4572 [iTIP] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- 4573 Independent Interoperability Protocol (iTIP)", RFC 2446, November 4574 1998 4576 [iMIP] Dawson, Mansour, Silverberg, "iCalendar Message-Based 4577 Interoperability Protocol (iMIP)", RFC 2445, November 1998 4579 [SQL] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka ANSI 4580 X3.135-1992, aka FiPS PUB 127-2 4582 [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 4583 to ISO/IEC 9075: 1992, also adopted as Amendment 1 to ANSI 4584 X3.135.1992 4586 [UNICODE] The Unicode Consortium, "The Unicode Standard - 4588 Worldwide Character Encoding -- Version 1.0", Addison-Wesley, 4589 Volume 1, 1991, Volume 2, 1992. UTF-8 is described in Unicode 4590 Technical Report #4. 4592 [US-ASCII] Coded Character Set--7-bit American Standard Code for 4593 Information Interchange, ANSI X3.4-1986. 4595 Full Copyright Statement 4597 Copyright (C) The Internet Society (2001). All Rights Reserved. 4599 This document and translations of it may be copied and furnished to 4600 others, and derivative works that comment on or otherwise explain it 4601 or assist in its implementation may be prepared, copied, published 4602 and distributed, in whole or in part, without restriction of any 4603 kind, provided that the above copyright notice and this paragraph are 4604 included on all such copies and derivative works. However, this 4605 document itself may not be modified in any way, such as by removing 4606 the copyright notice or references to the Internet Society or other 4607 Internet organizations, except as needed for the purpose of 4608 developing Internet standards in which case the procedures for 4609 copyrights defined in the Internet Standards process must be 4610 followed, or as required to translate it into languages other than 4611 English. 4613 The limited permissions granted above are perpetual and will not be 4614 revoked by the Internet Society or its successors or assigns. 4616 This document and the information contained herein is provided on an 4617 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4618 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4619 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4620 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4621 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4623 Acknowledgement 4625 Funding for the RFC Editor function is currently provided by the 4626 Internet Society.