idnits 2.17.1 draft-ietf-calsch-cap-05.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 : ---------------------------------------------------------------------------- ** There are 52 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 86 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 34 instances 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 are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances 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 333: '...example, "events MUST be scheduled in ...' RFC 2119 keyword, line 472: '...flict, the realm SHOULD be postfixed w...' RFC 2119 keyword, line 523: '... mapping MUST never be deliverab...' RFC 2119 keyword, line 567: '... * CS1 MAY play the role of a CUA...' RFC 2119 keyword, line 569: '... * CS1 MUST be able play the role...' (191 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 523 has weird spacing: '...ever be deliv...' == Line 524 has weird spacing: '...ists of a...' == Line 525 has weird spacing: '... realm in th...' == Line 526 has weird spacing: '...me. In it's ...' == Line 613 has weird spacing: '... policy could...' == (47 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The response-args are defined in Section 8. The debug-text is human-readable information for protocol debugging and is optional and is only used to aid developers writing CSs and CUAs. The debug-text MUST not be depended on by CUAs in normal interactions with a CS. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Subsequent to the initial Anonymous Authentication with a CS, a CUA will have to provide a UPN for some CAP operations. For anonymous access the UPN that MUST be used by the CUA is "@", a UPN with a null username and null realm. The user's normal UPN MUST not be used for the subsequent CAP operations. -- 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 (July 20, 2001) is 8313 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? 'RFC2119' on line 5353 looks like a reference -- Missing reference section? 'IMPL' on line 246 looks like a reference -- Missing reference section? 'URL' on line 5357 looks like a reference -- Missing reference section? 'MIME' on line 5344 looks like a reference -- Missing reference section? 'TLS' on line 5351 looks like a reference -- Missing reference section? 'SASL' on line 5355 looks like a reference -- Missing reference section? 'RFC 2246' on line 953 looks like a reference -- Missing reference section? 'SQL' on line 5372 looks like a reference -- Missing reference section? 'CMDID' on line 4784 looks like a reference -- Missing reference section? 'IANA-PROP' on line 3839 looks like a reference -- Missing reference section? 'VQUERY' on line 3196 looks like a reference -- Missing reference section? 'VCARD' on line 5388 looks like a reference -- Missing reference section? 'SQLCOM' on line 5375 looks like a reference -- Missing reference section? 'UNICODE' on line 5379 looks like a reference -- Missing reference section? 'US-ASCII' on line 5385 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Mansour 3 Internet-Draft Netscape, iPlanet 4 Expires: January 18, 2002 D. Royer 6 G. Babics 7 Steltor 8 P. Hill 9 Massachusetts Institute of 10 Technology 11 July 20, 2001 13 Calendar Access Protocol (CAP) 14 draft-ietf-calsch-cap-05 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 January 18, 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-calendarand 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 . . . . . . . . . . . . . . . . . . . . . . 13 66 2.1 System Model . . . . . . . . . . . . . . . . . . . . . 13 67 2.1.1 Firewalls and Fanout . . . . . . . . . . . . . . . . . 14 68 2.2 Calendar Store Object Model . . . . . . . . . . . . . 15 69 2.3 Protocol Model . . . . . . . . . . . . . . . . . . . . 16 70 2.4 Security Model . . . . . . . . . . . . . . . . . . . . 17 71 2.4.1 Authentication, Credentials, and Identity . . . . . . 18 72 2.4.2 Calendar User and UPNs . . . . . . . . . . . . . . . . 19 73 2.4.2.1 UPNs and Certificates . . . . . . . . . . . . . . . . 19 74 2.4.2.2 Anonymous Users and Authentication . . . . . . . . . . 20 75 2.4.2.3 Required Security Mechanisms . . . . . . . . . . . . . 21 76 2.4.2.4 TLS Ciphersuites . . . . . . . . . . . . . . . . . . . 21 77 2.4.3 User Groups . . . . . . . . . . . . . . . . . . . . . 22 78 2.4.4 Access Rights - Summary . . . . . . . . . . . . . . . 23 79 2.4.4.1 VCalendar Access Right (VCAR) . . . . . . . . . . . . 24 80 2.4.4.2 Decreed VCARs . . . . . . . . . . . . . . . . . . . . 24 81 2.4.5 Inheritance . . . . . . . . . . . . . . . . . . . . . 25 82 2.4.6 CAP Session Identity . . . . . . . . . . . . . . . . . 25 83 2.5 Roles . . . . . . . . . . . . . . . . . . . . . . . . 26 84 2.6 Calendar Addresses . . . . . . . . . . . . . . . . . . 26 85 2.7 Extensions to iCalendar . . . . . . . . . . . . . . . 27 86 2.8 Relationship of RFC 2446 (ITIP) to CAP . . . . . . . . 28 87 3. State Diagram . . . . . . . . . . . . . . . . . . . . 30 88 4. Protocol Framework . . . . . . . . . . . . . . . . . . 32 89 4.1 CAP Application Layer . . . . . . . . . . . . . . . . 32 90 4.2 CAP Transfer Protocol . . . . . . . . . . . . . . . . 32 91 4.3 Pipelining Commands . . . . . . . . . . . . . . . . . 33 92 4.4 Auto-logout Timer . . . . . . . . . . . . . . . . . . 33 93 4.5 Bounded Latency . . . . . . . . . . . . . . . . . . . 33 94 4.6 Data Elements . . . . . . . . . . . . . . . . . . . . 34 95 5. Formal Command Syntax . . . . . . . . . . . . . . . . 35 96 5.1 Searching and Filtering . . . . . . . . . . . . . . . 35 97 5.1.1 Grammar For Search Mechanism . . . . . . . . . . . . . 35 98 5.1.2 SQL-MIN notes . . . . . . . . . . . . . . . . . . . . 36 99 5.1.3 SQL-92 notes . . . . . . . . . . . . . . . . . . . . . 37 100 5.1.4 Example, Query by UID . . . . . . . . . . . . . . . . 37 101 5.1.5 Query by Date-Time range . . . . . . . . . . . . . . . 38 102 5.1.6 Query for all Non-Booked Entries . . . . . . . . . . . 38 103 5.1.7 Query with Subset of Properties by Date/Time . . . . . 38 104 5.1.8 Components With Alarms In A Range . . . . . . . . . . 39 105 6. Access Rights . . . . . . . . . . . . . . . . . . . . 40 106 6.1 VCAR Inheritance . . . . . . . . . . . . . . . . . . . 40 107 6.2 Access Control and NOCONFLICT . . . . . . . . . . . . 40 108 7. Commands and Responses . . . . . . . . . . . . . . . . 41 109 7.1 Transfer Protocol Commands . . . . . . . . . . . . . . 41 110 7.1.1 Initial Connection . . . . . . . . . . . . . . . . . . 41 111 7.1.2 ABORT Command . . . . . . . . . . . . . . . . . . . . 42 112 7.1.3 AUTHENTICATE Command . . . . . . . . . . . . . . . . . 42 113 7.1.3.1 AUTHENTICATE ANONYMOUS . . . . . . . . . . . . . . . . 45 114 7.1.4 CALIDEXPAND Command . . . . . . . . . . . . . . . . . 46 115 7.1.5 CAPABILITY Command . . . . . . . . . . . . . . . . . . 48 116 7.1.6 CONTINUE Command . . . . . . . . . . . . . . . . . . . 50 117 7.1.7 DISCONNECT Command . . . . . . . . . . . . . . . . . . 51 118 7.1.8 IDENTIFY Command . . . . . . . . . . . . . . . . . . . 52 119 7.1.9 SENDDATA Command . . . . . . . . . . . . . . . . . . . 52 120 7.1.10 STARTTLS Command . . . . . . . . . . . . . . . . . . . 53 121 7.1.11 UPNEXPAND Method . . . . . . . . . . . . . . . . . . . 53 122 7.1.12 NOOP Command . . . . . . . . . . . . . . . . . . . . . 55 123 7.2 Application Protocol Commands . . . . . . . . . . . . 55 124 7.2.1 Calendaring Commands . . . . . . . . . . . . . . . . . 55 125 7.2.1.1 Restriction Tables . . . . . . . . . . . . . . . . . . 56 126 7.2.1.2 CREATE Method . . . . . . . . . . . . . . . . . . . . 56 127 7.2.1.2.1 Creating New Calendars . . . . . . . . . . . . . . . . 64 128 7.2.1.2.2 Creating a new VQUERY . . . . . . . . . . . . . . . . 66 129 7.2.1.3 DELETE Method . . . . . . . . . . . . . . . . . . . . 67 130 7.2.1.4 GENERATEUID Method . . . . . . . . . . . . . . . . . . 71 131 7.2.1.5 MODIFY Method . . . . . . . . . . . . . . . . . . . . 71 132 7.2.1.6 MOVE Method . . . . . . . . . . . . . . . . . . . . . 80 133 7.2.1.7 READ Method . . . . . . . . . . . . . . . . . . . . . 83 134 7.2.1.7.1 Query With A Stored Query . . . . . . . . . . . . . . 90 135 7.2.2 Scheduling Commands . . . . . . . . . . . . . . . . . 91 136 7.2.2.1 Reading Scheduling Components . . . . . . . . . . . . 92 137 7.2.2.2 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 93 138 7.2.2.3 REQUEST . . . . . . . . . . . . . . . . . . . . . . . 94 139 7.2.2.4 REPLY . . . . . . . . . . . . . . . . . . . . . . . . 94 140 7.2.2.5 ADD . . . . . . . . . . . . . . . . . . . . . . . . . 95 141 7.2.2.6 CANCEL . . . . . . . . . . . . . . . . . . . . . . . . 95 142 7.2.2.7 REFRESH . . . . . . . . . . . . . . . . . . . . . . . 95 143 7.2.2.8 COUNTER . . . . . . . . . . . . . . . . . . . . . . . 96 144 7.2.2.9 DECLINECOUNTER . . . . . . . . . . . . . . . . . . . . 96 145 7.2.3 iTIP Examples . . . . . . . . . . . . . . . . . . . . 96 146 7.2.3.1 Sending and Receiving an iTIP request . . . . . . . . 96 147 7.2.3.2 Handling an iTIP refresh . . . . . . . . . . . . . . . 99 148 7.2.3.3 Sending and accepting an iTIP counter . . . . . . . . 100 149 7.2.3.4 Declining an iTIP counter . . . . . . . . . . . . . . 102 150 8. Response Codes . . . . . . . . . . . . . . . . . . . . 104 151 8.1 Examples . . . . . . . . . . . . . . . . . . . . . . . 106 152 8.1.1 Authentication Examples . . . . . . . . . . . . . . . 106 153 8.1.1.1 Login Using Kerberos V4 . . . . . . . . . . . . . . . 106 154 8.1.1.2 Error Scenarios . . . . . . . . . . . . . . . . . . . 106 155 8.2 Read Examples . . . . . . . . . . . . . . . . . . . . 106 156 8.2.1 Read From A Single Calendar . . . . . . . . . . . . . 106 157 8.2.2 Read From Multiple Calendars . . . . . . . . . . . . . 107 158 8.2.3 Timeouts . . . . . . . . . . . . . . . . . . . . . . . 109 159 8.2.4 Using Parent and Children Properties . . . . . . . . . 110 160 8.2.5 Query VEVENT.DTSTART and VALARM.DTSTART . . . . . . . 110 161 9. Implementation Issues . . . . . . . . . . . . . . . . 111 162 10. Properties . . . . . . . . . . . . . . . . . . . . . . 112 163 10.1 Calendar Store Properties . . . . . . . . . . . . . . 112 164 10.2 Calendar Properties . . . . . . . . . . . . . . . . . 113 165 11. Security Considerations . . . . . . . . . . . . . . . 116 166 12. CAP Item Registration . . . . . . . . . . . . . . . . 117 167 12.1 Registration of New and Modified CAP Entities . . . . 117 168 12.2 Registration of New Entities . . . . . . . . . . . . . 117 169 12.2.1 Define the Item . . . . . . . . . . . . . . . . . . . 117 170 12.2.2 Post the item definition . . . . . . . . . . . . . . . 118 171 12.2.3 Allow a comment period . . . . . . . . . . . . . . . . 118 172 12.2.4 Submit the proposal for approval . . . . . . . . . . . 118 173 12.3 Property Change Control . . . . . . . . . . . . . . . 119 174 13. IANA Considerations . . . . . . . . . . . . . . . . . 120 175 Authors' Addresses . . . . . . . . . . . . . . . . . . 120 176 A. Acknowledegements . . . . . . . . . . . . . . . . . . 122 177 B. Bibliography . . . . . . . . . . . . . . . . . . . . . 123 178 Full Copyright Statement . . . . . . . . . . . . . . . 124 180 1. Introduction 182 This document specifies how a Calendar User Agent (CUA) interacts 183 with a Calendar Store (CS) to manage calendar information. In 184 particular, it specifies how to query, create, modify, and delete 185 iCalendar components (e.g., events, to-dos, or daily journal 186 entries). It further specifies how to search for available busy time 187 information. 189 This protocol is based on request/response form of data units, sent 190 from a client CUA to a calendar server. The protocol data units 191 leverage the standard iCalendar format [iCAL] for conveying CS 192 related information. 194 1.1 Formatting Conventions 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 Calendaring and scheduling roles are referred to in quoted- strings 201 of text with the first character of each word in upper case. For 202 example, "Organizer" refers to a role of a "Calendar User" (CU) 203 within the protocol defined by this memo. Calendar components 204 defined by [iCAL] are referred to with capitalized, quoted-strings of 205 text. All calendar components start with the letter "V". For 206 example, "VEVENT" refers to the event calendar component, "VTODO" 207 refers to the to-do calendar component and "VJOURNAL" refers to the 208 daily journal calendar component. Calendar access methods defined by 209 this memo, as well as scheduling methods defined by [iTIP], are 210 referred to with capitalized, quoted-strings of text. For example, 211 "CREATE" refers to the method for creating a calendar component on a 212 calendar, "READ" refers to the method for reading calendar 213 components. 215 Properties defined by this memo are referred to with capitalized, 216 quoted-strings of text, followed by the word "property". For 217 example, "ATTENDEE" property refers to the iCalendar property used to 218 convey the calendar address of a "Calendar User". Property 219 parameters defined by this memo are referred to with lower case, 220 quoted-strings of text, followed by the word "parameter". For 221 example, "value" parameter refers to the iCalendar property parameter 222 used to override the default data type for a property value. 223 Enumerated values defined by this memo are referred to with 224 capitalized text, either alone or followed by the word "value". 226 In tables, the quoted-string text is specified without quotes in 227 order to minimize the table length. 229 1.2 Related Documents 231 Implementers will need to be familiar with several other memos that, 232 along with this one, describe the Internet calendaring and scheduling 233 standards. These documents are: 235 [iCAL] (RFC2445) which specifies the objects, data types, properties 236 and property parameters used in the protocols, along with the methods 237 for representing and encoding them, 239 [iTIP] (RFC2446) which specifies an interoperability protocol for 240 scheduling between different implementations. The related documents 241 are: 243 [iMIP] (RFC2447) which specifies an Internet email binding for 244 [iTIP]. 246 [IMPL] (draft/rfc...) which is a guide to implementers and describes 247 the elements of a calendaring system, how they interact with each 248 other, how they interact with end users, and how the standards and 249 protocols are used. 251 This memo does not attempt to repeat the specification of concepts or 252 definitions from these other memos. Where possible, references are 253 made to the memo that provides for the specification of these 254 concepts or definitions. 256 1.3 Definitions 258 Authentication ID (AuthID) 260 A tuple of username, realm, and authentication method, used by the 261 Calendar Service internally to identify a successfully 262 authenticated CAP session. 264 Booked 266 A entry in a calendar has one of two conceptual states. It is 267 scheduled or it is booked. A scheduled entry has been stored in 268 the calendar store but has not been acted on by a calendar user or 269 calendar user agent. A booked appointment is an entry that has 270 had its state changed from one of the [iTIP] scheduling methods to 271 a CAP method of CREATE by a calendar user or calendar user agent 272 which resulted in decision to keep the entry in the calendar 273 store. 275 Calendar 276 A collection of logically related objects or entities each of 277 which may be associated with a calendar date and possibly time of 278 day. These entities can include other calendar properties or 279 calendar components.In addition, a calendar might be 280 hierarchically related to other sub-calendars. A calendar is 281 identified by its unique calendar identifier. The [iCAL] defines 282 calendar properties, calendar components and component properties 283 that make up the content of a calendar. 285 Calendar Access Protocol (CAP) 287 The standard Internet protocol that permits a Calendar User Agent 288 to access and manipulate a calendar residing on a Calendar Store. 290 Calendar Access Rights (CAR) 292 The mechanism for specifying the CAP operations ("ACTIONS") that a 293 particular calendar user ("UPN") are granted or denied permission 294 to perform on a given calendar item ("OBJECT"). The calendar 295 access rights are specified with the "VCAR" calendar components 296 within a CS and calendar. 298 Calendar Collection 300 A collection of Calendars, Resource Calendars, and/or other 301 Calendar Collections. These collections are expanded by the CS 302 and may reside either locally or in an external database or 303 directory. The calendars in the collection may be fixed or 304 dynamic over time. 306 Calendar Component 308 An item within a calendar. Some types of calendar components 309 include events, to-dos, journals, alarms, time zones and freebusy 310 data. A calendar component consists of component properties and 311 possibly other sub-components. For example, an event may contain 312 an alarm component. 314 Calendar Component Properties 316 An attribute of a particular calendar component. Some calendar 317 component properties are applicable to different types of calendar 318 components. For example, DTSTART is applicable to VEVENT, VTODO, 319 VJOURNAL calendar components. Other calendar components are 320 applicable only to an individual type of calendar component. For 321 example, TZURL is only applicable to VTIMEZONE calendar 322 components. 324 Calendar Identifier (CalID) 326 A globally unique identifier associated with a calendar. 327 Calendars reside within a CS. See Qualified Calendar Identifier 328 and Relative Calendar Identifier. 330 Calendar Policy 332 A CAP operational restriction on the access or manipulation of a 333 calendar. For example, "events MUST be scheduled in unit 334 intervals of one hour". 336 Calendar Properties 338 An attribute of a calendar. The attribute applies to the 339 calendar, as a whole. For example, CALSCALE specifies the 340 calendar scale (e.g., GREGORIAN) for the whole calendar. 342 Calendar Service 344 An implementation of a Calendar Store that manages one or more 345 calendars. 347 Calendar Store (CS) 349 The data and service model definition for a Calendar Service. 351 Calendar Store Identifier (CSID) 353 The globally unique identifier for an individual CS. A CSID 354 consists of the host and port portions of a "Common Internet 355 Scheme Syntax" part of a URL, as defined by [URL]. 357 Calendar Store Components 359 Components maintained in a CS specify a grouping of calendar 360 store-wide information. Calendar store components can be accessed 361 using CAP. 363 Calendar Store Properties 365 Properties maintained in a Calendar Store calendar store-wide 366 information. Calendar store properties can be accessed using CAP. 368 Calendar User (CU) 370 An entity (often biological) that uses a calendaring system. 372 Calendar User Agent (CUA) 374 The CUA is the client application that a CU or UG utilizes to 375 access and manipulate a calendar. 377 Calendaring and Scheduling System 379 The computer sub-system that provides the services for accessing, 380 manipulating calendars and scheduling calendar components. 382 CAP Session 384 An open communication channel between a CAP CUA and a CAP CS. 386 Connected Mode 388 A mobile computing mode where the CUA is directly connected to the 389 CS. 391 Delegate 393 Is a calendar user (sometimes called the delegatee) who has been 394 assigned participation in a scheduled calendar component (e.g., 395 VEVENT) by one of the attendees in the scheduled calendar 396 component (sometimes called the delegator). An example of a 397 delegate is a team member told to go to a particular meeting. 399 Designate 401 Is a calendar user who is authorized to act on behalf of another 402 calendar user. An example of a designate is an assistant. 404 Disconnected Mode 406 A mobile computing mode where a CUA can be disconnected from a CS. 407 When the CUA is disconnected, it is in the disconnected mode. 409 Fan Out 411 The calendaring and scheduling process by which a calendar 412 operation on one calendar is also performed on every other 413 calendar specified in the operation. This may include the 414 calendar associated with TARGET calendar property. 416 Hierarchical Calendars 418 A CS feature where a calendar have a hierarchical relationship 419 with another calendar in the CS. The top-most calendar in the 420 hierarchical relationship has the CS as its parent. There may be 421 multiple top- most calendars in a given CS. Within a given 422 hierarchical relationship, all sub-calendars have a calendar with 423 a "parent" topographical relationship. In addition, sub-calendars 424 may have a relationship with another calendar that has a "child" 425 topographical relationship. In addition, a calendar may have a 426 relationship such that one or more calendars have a "sibling" 427 topographical relationship with the calendar. The hierarchical 428 calendar feature is not a storage relationship of the calendars 429 within the CS. Instead it is a feature that relates access 430 control rights to calendar content between different calendars in 431 the CS. The hierarchical relationship of a calendar is specified 432 in the "PARENT" and "CHILDREN" calendar properties. 434 High Bandwidth Connection 436 A communications connection supporting high transfer rates; 437 transfer rates commonly found within a LAN. 439 Local Store 441 A CS which is on the same platform as the CUA. 443 Low Bandwidth Connection 445 A communications connection supporting slow transfer rates; 446 transfer rates commonly found in remote access technology. 448 Overlapped Booking 450 A policy which indicates whether or not OPAQUE events can overlap 451 one another. When the policy is applied to a calendar it 452 indicates whether or not the time span of any entry (VEVENT, 453 VTODO, ...) in the calendar can overlap the time span of any other 454 entry in the same calendar. When applied to an individual entry, 455 it indicates whether or not any other entry's time span can 456 overlap that individual entry. 458 Owner 460 One or more CUs or UGs that have "OWNER" calendar access rights 461 for a calendar. The owner is specified in the "OWNER" calendar 462 property and in the "OWNER" calendar store property. 464 Qualified Calendar Identifier (Qualified CalID) 466 A CalID where both the and are present. 468 Realm 470 A collection of calendar user accounts, identified by a string. 471 The name of the realm is only used in UPNs. In order to avoid 472 namespace conflict, the realm SHOULD be postfixed with an 473 appropriate DNS domain name. (eg: the foobar realm could be 474 called foobar.example.com). 476 Relative Calendar Identifier (Relative CalID) 478 An identifier for an individual calendar in a calendar store. It 479 is unique within a calendar store. It is recommended to be 480 globally unique. A Relative CalID consists of the portion of the 481 "scheme part" of a Qualified CalID following the Calendar Store 482 Identifier. This is the same as the "URL path" of the "Common 483 Internet Scheme Syntax" portion of a URL, as defined by [URL]. 485 Remote Store 487 A CS which is not on the same platform as the CUA. 489 Resource Calendar (RC) 491 A non-human Calendar, associated with an organizational resource. 492 There is no syntactic difference between an RC and a Calendar. 494 Session Identity 496 A UPN associated with a CAP session. A session gains an identity 497 after successful authentication. The identity is used in 498 combination with CAR to determine access to data in the CS. 500 Sub-calendars 502 Calendars that have a "child" hierarchical relationship with 503 another calendar, its "parent". 505 User Group (UG) 507 A collection of Calendar Users and/or User Groups. These groups 508 are expanded by the CS and may reside either locally or in an 509 external database or directory. The group membership may be fixed 510 or dynamic over time. 512 User Name 514 A name which denotes a Calendar User within a realm. This is part 515 of a UPN. 517 User Principal Name (UPN) 519 An identifier that denotes a unique CU. A UPN is an RFC 822 520 compliant email address, with exceptions listed below, and in most 521 cases it is deliverable to the CU. In some cases it is identical 522 to the CU's well known email address. A CU's UPN to email address 523 mapping MUST never be deliverable to a different person as there 524 is not requirement that they are the same. It consists of a 525 realm in the form of a valid, and unique, DNS domain name and a 526 unique username. In it's simplest form it looks like 527 "user@example.com". 529 In certain cases a UPN will not be RFC 822 compliant. When 530 anonymous authentication is used, or anonymous authorization is 531 being defined, the special UPN "@" will be used. When 532 authentication must be used, but unique identity must be obscured, 533 a UPN of the form @DNS-domain-name may be used. For example, 534 "@example.com". Usage of these special cases is further discussed 535 in the authentication and authorization sections of this document. 537 2. CAP Design 539 2.1 System Model 541 The system model describes the high level components of a calendar 542 system and how they interact with each other. 544 CAP is used by a "Calendar User Agent" (CUA) to send commands to and 545 receive responses from a "Calendar Service" (CS). The CUA prepares a 546 [MIME] encapsulated iCalendar object containing a command, sends it 547 to the CS, and receives a [MIME] encapsulated iCalendar object as a 548 response. There are two distinct protocols in operation to 549 accomplish this exchange. The Transfer Protocol is used to move 550 these encapsulations between a CUA and a CS. The Application 551 Protocol defines the content and semantics of the iCalendar objects 552 sent between the CUA and the CS. This document defines both the 553 Transfer Protocol and the Application Protocol. 555 In the diagram below, a user uses CUA1 to communicate with CS1 using 556 CAP. The CUA must authenticate the Calendar User (CU) so that access 557 to calendars on CS1 can be controlled. The CUA can then view, 558 create, edit, and delete calendars, calendar properties, and calendar 559 components subject to the access rights. 561 CAP servers support fanout. Fanout allows a CUA to communicate with 562 a single CS to perform scheduling operations with calendars on 563 multiple CSs. That is, a CU can book or schedule events (or to-dos) 564 on or read events (or to-dos) from calendars on other calendar 565 stores. To accomplish this, a CAP server takes on these roles: 567 * CS1 MAY play the role of a CUA and use CAP to access CS2; 569 * CS1 MUST be able play the role of a CUA and use [iMIP] to 570 interoperate with other CUAs. 572 +-----+ +-----+ 573 | | CAP | | CAP 574 CUA1------| CS1 |----------| CS2 |--------- CUA2 575 | | | | A 576 | | | | | 577 | | | | | 578 +-----+ +-----+ | 579 | IMIP | 580 +--------------------------------+ 582 Note that the fanout feature in CAP is a convenience to the CUA. It 583 is perfectly valid for the CUA to assume the responsibility for 584 fanout if it wishes. That is, [iMIP] messages could also be sent 585 from CUA1 to CUA2. 587 CAP does not specify any trust model between CS1 and CS2. 588 Implementations may require a trust model to exist in order to 589 accomplish scheduling between CS1 and CS2. 591 2.1.1 Firewalls and Fanout 593 - - - ------INTERNET---------------------- - - - 594 | | 595 +----------------+ +----------------------+ 596 | Site Public CS |<---->| Other Site Public CS | 597 | (CS-P) | | (CS-P2) | 598 +----------------+ +----------------------+ 599 ^ ^ 600 | . 601 v . 602 +----------------+ . 603 | Site Firewall | - - - ---Other LAN---- - 604 +----------------+ 605 | 606 - - ---------------LAN---------------------------- - - - 607 | | | 608 +--------------+ +--------------+ +- - - - - - - - + 609 | Department-1 | | Department-2 | | . . . | 610 | CS-1 | | CS-2 | | CS-n | 611 +--------------+ +--------------+ +- - - - - - - - + 613 One example of a site site policy could be that all entries in 614 department calendars that were marked PUBLIC, were visible on the 615 internet to any users that was granted access to CS-P. 617 With fanout in place, CS-P would authenticate the internet user and 618 decide in an implementation specific way, which user CS (CS-1, CS- 619 2, CS-n) the TARGET calendar physically existed. Then using 620 fanout, CS- P sends the request subject to VCARs or immutable 621 VCARS from CS-P to the users CS and back to the CUA through CS-P. 622 CS-P could be a smart proxy. 624 And there is no reason that the target calendar need to exist under 625 the firewall (CS-P2), only that the CSs can authenticate with each 626 other. In this way all users in a domain could appear to be at 627 calendar.site.com, hiding all CS-1 through CS-n from the internet. 628 And also hiding that fact that CS-P2 may be a separate domain 629 controlled by the same site administrators as CS-P (which in turn 630 could do fanout to its LAN). 632 2.2 Calendar Store Object Model 634 The conceptual model for a calendar store is shown below. The 635 calendar store contains calendars, VTIMEZONEs, VCARs, and calendar 636 store properties. 638 Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, and 639 calendar properties. Calendars may also contain other calendars. 641 Calendar Store 642 | 643 +-- VCARs 644 +-- Properties 645 +-- VTIMEZONEs 646 +-- VCALENDARs 647 | 648 +--VEVENTs 649 +--VALARMs 650 +--VTODOs 651 +--VALARMs 652 +--VJOURNALs 653 +--VCARs 654 +--Properties 655 +--VTIMEZONEs 656 +--VSCHEDULE 657 +--VQUERY 658 +--Calendar 659 | 660 +--VEVENTs 661 +--VALARMs 662 +--VTODOs 663 +--VALARMs 664 +--VJOURNALs 665 +--VCARs 666 +--Properties 667 +--VTIMEZONEs 668 +--VSCHEDULE 669 +--VQUERY 670 +--Calendar 671 | 672 ... 674 Calendars within a Calendar Store are identified by their Relative 675 CALID. 677 In this model, VSCHEDULE is a queue of scheduling messages that have 678 not yet been applied to the calendar. Items in VSCHEDULE are 679 discussed in more detail below. 681 2.3 Protocol Model 683 A generic transfer-layer, Calendar Server Transfer Protocol (CSTP), 684 is used to move data objects between a CUA and the CS. CSTP commands 685 are listed below and their usage and semantics are defined in section 686 7.1 of this document. 688 CSTP Commands 689 ----------------------------------------------------------- 690 Command Description 691 ----------------------------------------------------------- 692 ABORT Stop a command. Perhaps because its latency 693 time has been exceeded. 694 AUTHENTICATE Authenticate a UPN. 695 CONTINUE Continue the execution of a command whose 696 Latency time has been exceeded. 697 IDENTIFY Set a new identity for calendar access. 698 DISCONNECT Terminate a connection with the server. 699 SENDDATA Send a data object [MIME] encapsulated 700 iCalendar. 701 STARTTLS Negotiate transport level security using 702 [TLS]. 703 NOOP Do nothing operation. 704 ----------------------------------------------------------- 706 Application-level commands are used to manipulate data on the 707 calendar store. They are listed below and discussed in detail in 708 section 7.2. 710 CAP Calendaring Commands 711 ---------------------------------------------------------- 712 Command Description 713 ---------------------------------------------------------- 714 CREATE Create a new calendar or component. 715 DELETE Delete a calendar or component. 716 GENERATEUID Generate one or more unique ids. 717 MODIFY Change a calendar or component. 718 MOVE Move a calendar. 719 READ Read a calendar properties or components. 720 ---------------------------------------------------------- 722 CAP Scheduling Commands 723 (As defined in [iTIP]) 724 ----------------------------------------------------------- 725 Command Description 726 ----------------------------------------------------------- 727 PUBLISH Publish a calendar entry to one or more 728 calendars. 729 REQUEST Schedule a calendar entry with one or more 730 calendars. 731 REPLY Response to a scheduling request. 732 ADD Add one or more instances to an existing 733 calendar entry. 734 CANCEL Cancel one or more instances to an existing 735 calendar entry. 736 REFRESH A request for the latest version of a 737 calendar entry. 738 COUNTER A request for a change (a counter-proposal) 739 to a calendar entry. 740 DECLINECOUNTER Decline a counter proposal. 741 ----------------------------------------------------------- 743 2.4 Security Model 745 Authentication to the CS will be performed using [SASL]. 747 As noted in the CAP system model section, a variety of connectivity 748 scenarios are possible. This complicates the security model 749 considerably, and a thorough familiarity with the concepts is 750 required to ensure interoperability. 752 Basic threats to a Calendaring and Scheduling System include: 754 (1) Unauthorized access to data via data-fetching operations, 756 (2) Unauthorized access to reusable client authentication 757 information by monitoring others' access, 759 (3) Unauthorized access to data by monitoring others' access, 761 (4) Unauthorized modification of data, 763 (5) Unauthorized or excessive use of resources (denial of 764 service), and 766 (6) Spoofing of CS: Tricking a client into believing that 767 information came from the CS when in fact it did not, either 768 by modifying data in transit or misdirecting the client's 769 connection. 771 Threats (1), (4), (5) and (6) are due to hostile clients. Threats 772 (2), and (3) are due to hostile agents on the path between client and 773 server, or posing as a server. 775 CAP can be protected with the following security mechanisms: 777 (1) Client authentication by means of the SASL mechanism set, 778 possibly backed by the TLS credentials exchange mechanism, 780 (2) Client authorization by means of access control based on the 781 requestor's authenticated identity, 783 (3) Data integrity protection by means of the TLS protocol or data 784 integrity SASL mechanisms, 786 (4) Protection against snooping by means of the TLS protocol or 787 data encrypting SASL mechanisms, 789 (5) Resource limitation by means of administrative limits on 790 service controls, and 792 (6) Server authentication by means of the TLS protocol or SASL 793 mechanism. 795 Imposition of access controls (authorizations) is done by means of 796 VCARs, an overview is provided in the section 2.4.4 and a 797 detailed syntax is provided in section 6 Authentication is 798 explained in detail in section 2.4.1 800 2.4.1 Authentication, Credentials, and Identity 802 Generically, authentication credentials are the evidence supplied by 803 one party to another, asserting the identity of the supplying party 804 (e.g. a user) who is attempting to establish an association with the 805 other party (typically a server). Authentication is the process of 806 generating, transmitting, and verifying these credentials and thus 807 the identity they assert. An authentication identity is the name 808 presented in a credential. 810 There are many forms of authentication credentials. The form used 811 depends upon the particular authentication mechanism negotiated by 812 the parties. For example: X.509 certificates, Kerberos tickets, 813 simple identity and password pairs. Note that an authentication 814 mechanism may constrain the form of authentication identities used 815 with it. 817 SASL only provides a protocol to negotiate a mutually acceptable 818 authentication mechanism. SASL itself does not constrain or dictate 819 the form of the authentication identities used to perform the 820 authentication. 822 2.4.2 Calendar User and UPNs 824 A Calendar User(CU) is an entity that can be authenticated. It is 825 represented in CAP as a UPN. A UPN is the owner of a calendar and 826 the subject of access rights. The UPN representation is independent 827 of the authentication mechanism used during a particular CUA/CS 828 interaction. This is because UPNs are used within VCARs. If the UPN 829 were dependent on the authentication mechanism, a VCAR could not be 830 consistently evaluated. A CU may use one mechanism while using one 831 CUA but the same CU may use a different authentication mechanism when 832 using a different CUA, or while connecting from a different location. 834 The user may also have multiple UPNs for various purposes. 836 Note that the immutability of the user's UPN may be achieved by using 837 SASL's authorization identity feature. (The transmitted 838 authorization identity may be different than the identity in the 839 client's authentication credentials.) [SASL, section 3] This also 840 permits a CU to authenticate using their own credentials, yet request 841 the access privileges of the identity for which they are proxying 842 SASL. Also, the form of authentication identity supplied by a 843 service like TLS may not correspond to the UPNs used to express a 844 server's access control policy, requiring a server-specific mapping 845 to be done. The method by which a server composes and validates an 846 authorization identity from the authentication credentials supplied 847 by a client is implementation-specific. 849 For Calendaring and Scheduling Systems that are integrated with a 850 directory system, the CS MUST support the ability to configure which 851 schema attribute stores the UPN. The CS MAY allow one or more 852 attributes to be searched for the UPN. 854 2.4.2.1 UPNs and Certificates 856 When using X.509 certificates for purposes of CAP authentication, the 857 UPN should appear in the certificate. Unfortunately there is no 858 single correct guideline for which field should contain the UPN. 860 From RFC-2459, section 4.1.2.6 (Subject): 862 If subject naming information is present only in the subjectAlt- 863 Name extension (e.g., a key bound only to an email address or 864 URI), then the subject name MUST be an empty sequence and the 865 subjectAltName extension MUST be critical. 867 Implementations of this specification MAY use these comparison 868 rules to process unfamiliar attribute types (i.e., for name 869 chaining). This allows implementations to process certificates 870 with unfamiliar attributes in the subject name. 872 In addition, legacy implementations exist where an RFC 822 name is 873 embedded in the subject distinguished name as an EmailAddress 874 attribute. The attribute value for EmailAddress is of type 875 IA5String to permit inclusion of the character '@', which is not 876 part of the PrintableString character set. EmailAddress attribute 877 values are not case sensitive (e.g., "fanfeedback@redsox.com" is 878 the same as "FANFEEDBACK@REDSOX.COM"). 880 Conforming implementations generating new certificates with 881 electronic mail addresses MUST use the rfc822Name in the subject 882 alternative name field (see sec. 4.2.1.7 [of RFC 2459]) to 883 describe such identities. Simultaneous inclusion of the 884 EmailAddress attribute in the subject distinguished name to 885 support legacy implementations is deprecated but permitted. 887 Since no single method of including the UPN in the certificate will 888 work in all cases, CAP implementations MUST support the ability to 889 configure what the mapping will be by the CS administrator. 890 Implementations MAY support multiple mapping definitions, for 891 example, the UPN may be found in either the subject alternative name 892 field, or the UPN may be embedded in the subject distinguished name 893 as an EmailAddress attribute. 895 Note: If a CS or CUA is validating data received via iMIP, if the 896 "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe 897 Random User:juser@example.com" then the email address should be 898 checked against the UPN, and the CN should also be checked. This is 899 so the "ATTENDEE" property couldn't be munged to something misleading 900 like "ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass 901 validation. This validation will also defeat other attempts at 902 confusion. 904 2.4.2.2 Anonymous Users and Authentication 906 Anonymous access is often desirable. For example an organization may 907 publish calendar information that does not require any access control 908 for viewing or login. Conversely, a user may wish to view 909 unrestricted calendar information without revealing their identity. 911 CAP implementations MUST support anonymous authentication, as defined 912 in section 914 CAP implementations MAY support anonymous authentication with TLS, as 915 defined in section 917 2.4.2.3 Required Security Mechanisms 919 The following implementation conformance requirements are in place: 921 (1) For a read-only, public CS, anonymous authentication, 922 described in section can be used. 924 (2) Implementations providing password-based authenticated access 925 MUST support authentication using Digest, as described in section 926 and SHOULD support authentication 937 with a certificate as described in section Together, 938 these can provide integrity and disclosure protection of 939 transmitted data, and authentication of client and server, 940 including protection against active intermediary attacks. 942 2.4.2.4 TLS Ciphersuites 944 The following ciphersuites defined in [RFC 2246] MUST NOT be used for 945 confidentiality protection of passwords or data: 947 TLS_NULL_WITH_NULL_NULL 949 TLS_RSA_WITH_NULL_MD5 951 TLS_RSA_WITH_NULL_SHA 953 The following ciphersuites defined in [RFC 2246] can be cracked 954 easily (less than a week of CPU time on a standard CPU in 1997). The 955 client and server SHOULD carefully consider the value of the password 956 or data being protected before using these ciphersuites: 958 TLS_RSA_EXPORT_WITH_RC4_40_MD5 960 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 962 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 963 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 965 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 967 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 969 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 971 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 973 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 975 The following ciphersuites are vulnerable to man-in-the-middle 976 attacks, and SHOULD NOT be used to protect passwords or sensitive 977 data, unless the network configuration is such that the danger of a 978 man-in-the-middle attack is tolerable: 980 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 982 TLS_DH_anon_WITH_RC4_128_MD5 984 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 986 TLS_DH_anon_WITH_DES_CBC_SHA 988 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 990 A client or server that supports TLS MUST support at least: 992 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 994 2.4.3 User Groups 996 A User Group is used to represent a collection of CUs or other UGs 997 that can be referenced in VCARS. A UG is represented in CAP as a 998 UPN. The CUA cannot distinguish between a UPN that represents a CU 999 or a UG. 1001 UGs are expanded as necessary by the CS. The CS MUST accept a CUA 1002 request for UG expansion, although the CS may be configured to 1003 restrict some responses. The CS MAY expand a UG (including nested 1004 UGs) to obtain a list of unique CUs. Duplicate UPNs are filtered 1005 during expansion. Incomplete expansion should be treated as a 1006 failure. 1008 Groups may be in a directory service with its own ACL model and CAP 1009 should use the directory service to expand a UPN subject to the 1010 directory service access control model for the authenticated entity. 1012 The CS should not preserve UG expansions across operations. A UG may 1013 reference a static list of members, or it may represent a dynamic 1014 list. Each operation SHOULD generate its own expansion in order to 1015 recognize changes to UG membership. However, during fan out to other 1016 CSs, the originating CS SHOULD expand all UGs so that the target CS 1017 receives only a list of unique CUs. This is to prevent confusion 1018 when two CSs do not share the same UG database or directory. 1020 CAP does not define commands or methods for managing UGs. 1022 Small UG: 1024 The Three Stooges. There is only and always three at any one 1025 time. 1027 Large UG: 1029 The MIT graduating class of 1999. This is a static list. 1031 Dynamic UG: 1033 The IETF membership which is a large and changing list of members. 1035 Nested UG: 1037 The National Football League, made up of the AFC and NFC, which 1038 are made up of 3 divisions each... 1040 2.4.4 Access Rights - Summary 1042 Access rights are used to grant or deny access to a calendar for a 1043 CU. CAP defines a new component type called a Vcalendar Access Right 1044 (VCAR). Specifically, a VCAR grants, or denies, UPNs the right to 1045 read and write components, properties, and parameters on calendars 1046 within a CS. 1048 The VCAR model does not put any restriction on the sequence in which 1049 the object and access rights are created. That is, an event 1050 associated with a particular VCAR might be created before or after 1051 the actual VCAR is defined. In addition, the VCAR and VEVENT 1052 definition might be created in the same iCalendar object and passed 1053 together in a single command. 1055 All rights MUST be denied unless specifically granted; individual 1056 VCARs MUST be specifically granted to an authenticated CU. 1058 The access for a particular UPN is the union of all grants for that 1059 UPN minus the union of its denies. 1061 2.4.4.1 VCalendar Access Right (VCAR) 1063 Access rights within CAP are specified with the "VCAR" calendar 1064 component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" 1065 component properties. 1067 Properties within an iCalendar object are unordered. This also is 1068 the case for the "GRANT", "DENY" and "CARID" properties. Likewise, 1069 there is no implied ordering required for components of a "RIGHTS" 1070 value type other than that specified by the ABNF. [EDITOR'S NOTE, 1071 this requires a lot of review. We think that this paragraph may be 1072 incorrect. ] 1074 For details on the VCAR syntax please see section 1076 2.4.4.2 Decreed VCARs 1078 A CS MAY choose to implement and allow persistent immutable VCARs, 1079 that are configured by the CS Administrator, which apply to all 1080 calendars on the server. 1082 When a user attempts to modify a decreed VCAR an error will be 1083 returned, indicating that the user has insufficient authorization to 1084 perform the operation. 1086 The CAP protocol does not define the semantics used to initially 1087 create a decreed VCAR. This administrative task is out side the 1088 scope of the CAP protocol. 1090 For example an implementation or a CS administrator may wish to 1091 define a VCAR that will always allow the calendar owners to have full 1092 access to their own calendars. The GRANT property allows the OWNERs 1093 all (OBJECT=*) access to their own calendar objects. The DENY 1094 property disallows anyone (UPN=*) from being able to delete or modify 1095 this VCAR. 1097 BEGIN:VCAR 1098 CARID:Users Default Access 1099 GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* 1100 DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; 1101 VALUE="Users Default Access" 1102 ;OBJECT=METHOD,VALUE=DELETE,MODIFY 1103 END:VCAR 1105 Decreed VCARs MUST be readable by the calendar owner in standard VCAR 1106 format. 1108 2.4.5 Inheritance 1110 Calendars inherit VCARs from their parent calendar. Calendars whose 1111 parent is the Calendar Store inherit VCARs from the Calendar Store. 1113 VCARs specified in a calendar or a sub-calendar override all 1114 inherited VCARs. 1116 2.4.6 CAP Session Identity 1118 A CAP session has an associated set of authentication credentials, 1119 from which is derived a UPN. This UPN is the identity of the CAP 1120 session, and is used to determine access rights for the session. 1122 The CUA may change the identity of a CAP session by calling the 1123 "IDENTIFY" command. The Calendar Service only permits the operation 1124 if the session's authentication credentials are good for the 1125 requested identity. The method of checking this permission is 1126 implementation dependent, but may be thought of as a mapping from 1127 authentication credentials to UPNs. The "IDENTIFY" command allows a 1128 single set of authentication credentials to choose from multiple 1129 identities, and allows multiple sets of authentication credentials to 1130 assume the same identity. 1132 For anonymous access the identity of the session is "@", a UPN with a 1133 null username and null realm. A UPN with a null username, but non- 1134 null realm, such as "@foo.com" may be used to mean any identity from 1135 that realm, which is useful to grant access rights to all users in a 1136 given realm. A UPN with a non-null username and null realm, such as 1137 "bob@" could be a security risk and MUST NOT be used. 1139 Since the UPN includes realm information it may be used to govern 1140 calendar store access rights across realms. However, governing 1141 access rights across realms is only useful if login access is 1142 available. This could be done through a trusted server relationship 1143 or a temporary account. 1145 The "IDENTIFY" command provides for a weak group implementation. By 1146 allowing multiple sets of authentication credentials belonging to 1147 different users to identify as the same UPN, that UPN essentially 1148 identifies a group of people, and may be used for group calendar 1149 ownership, or the granting of access rights to a group. 1151 Examples: 1153 Small UG: 1155 The Three Stooges. There will always be three, it will not 1156 change. 1158 Large UG: 1160 The MIT graduating class of 1999. This is a static list. 1162 Dynamic UG: 1164 The IETF membership, which is a large and changing list of 1165 members. 1167 Nested UG: 1169 The National Football League, made up of the AFC and NFC, which 1170 are made up of 3 divisions each. 1172 2.5 Roles 1174 CAP defines methods for managing [iCAL] objects on a Calendar Store 1175 and exchanging [iCAL] objects for the purposes of group calendaring 1176 and scheduling between "Calendar Users" (CUs) or "User Groups" (UGs). 1177 There are two distinct roles taken on by CUs in CAP. The CU who 1178 creates an initial event or to-do and invites other CUs or UGs as 1179 attendees takes on the role of "Organizer". The CUs or UGs asked to 1180 participate in the group event or to-do take on the role of 1181 "Attendee". Note that "role" is also a descriptive parameter to the 1182 "ATTENDEE" property. Its use is to convey descriptive context to an 1183 "Attendee" such as "chair", "REQ-PARTICIPANT" or "NON- PARTICIPANT" 1184 and has nothing to do with the scheduling workflow. 1186 2.6 Calendar Addresses 1188 Calendar addresses are URIs that are modeled after URLs [URL]. CAP 1189 uses the following forms of URI. 1191 [[]://[:]/] 1193 where: 1195 is "cap", the protocol described in this memo. 1197 is the Calendar Store ID. It is the network address of the 1198 computer on which the CAP server is running. 1200 is optional. Its default value is 5229. The port must be 1201 present in the URL if the CAP server does not listen on this 1202 default port of 5229. 1204 is an identifier that uniquely identifies the 1205 calendar on a particular calendar store. There is no implied 1206 structure in a Relative CALID. It is an arbitrary string of 1207 printable 7 bit ASCII characters. It may refer to the calendar of 1208 a user or of a resource such as a conference room. It MUST be 1209 unique within the calendar store. It is recommended that the 1210 Relative CALID be globally unique. 1212 If the and are present the calendar address is said 1213 to be "qualified". Senders are required to supply the 1214 portion of the address. A qualified calendar address 1215 is required when the of the target calendar address differs 1216 from that of the CAP server receiving the command. 1218 Examples of CAP URIs: 1220 cap://calendar.example.com/user1 1221 ://calendar.example.com/user1 1222 user1 1223 cap://calendar.example.com/conferenceRoomA 1224 cap://calendar.example.com/89798-098-zytytasd 1226 For a user currently authenticated to a CAP server on 1227 calendar.example.com, the first three addresses refer to the same 1228 calendar. 1230 2.7 Extensions to iCalendar 1232 In mapping the CAP command set, query feature, and access rights onto 1233 the iCalendar format, several extended iCalendar methods and 1234 components are defined by this memo. 1236 The search function is specified with the new iCalendar QUERY 1237 method. The QUERY method makes use of a new component, called 1238 VQUERY, that contains the search filter. The component consists 1239 of a set of new properties: EXPAND, MAXSIZE, MAXRESULTS, QUERY and 1240 QUERYNAME, that define the search filter. Note that QUERY simply 1241 is the filter that is used by the CS to select the data used in 1242 METHOD:READ, METHOD:CREATE, METHOD:MODIFY, METHOD:DELETE, any 1243 other METHOD that is defined to use a QUERY filter. 1245 Access control is specified the the new iCalendar VCAR component. 1247 The iCalendar METHOD property format has been updated with new 1248 values. 1250 A new iCalendar component, VCOMMAND, has been added. VCOMMANDs 1251 are needed to specify CAP commands. 1253 VCAP is a new container for data that is transmitted as part of a 1254 VCOMMAND 1256 TARGET is a new property within the VCOMMAND component. It 1257 indicates the calendars to which the command applies 1259 CMDID is a Command ID that is used in a VCOMMAND to uniquely 1260 identify a command. Responses to a VCOMMAND will contain the 1261 same CMDID. 1263 2.8 Relationship of RFC 2446 (ITIP) to CAP 1265 [iTIP] describes scheduling methods which result in indirect 1266 manipulation of calendar components. CAP methods provide direct 1267 manipulation of calendar components. In the CAP calendar store 1268 model, scheduling messages are conceptually kept separate from other 1269 calendar components. This is modeled with the VSCHEDULE queue. Note 1270 that this is a conceptual model, the actual storage details are left 1271 to implementations. The model is shown pictorially as follows: 1273 +-----------------VCALENDAR-------------------+ 1274 | | 1275 | +-----------+ +-------VSCHEDULE---------+ | 1276 | | VEVENTs | | PUBLISH messages | | 1277 | | VTODOs | | REQUEST messages | | 1278 | | VJOURNALs | | REPLY messages | | 1279 | | | | ADD messages | | 1280 | | | | CANCEL messages | | 1281 | | | | REFRESH messages | | 1282 | | | | COUNTER messages | | 1283 | | | | DECLINECOUNTER messages | | 1284 | +-----------+ +-------------------------+ | 1285 +---------------------------------------------+ 1287 The METHOD is saved along with components. Scheduled components 1288 become booked components when the METHOD changes from an ITIP method 1289 to the CAP storage method CREATE. For example, a component whose 1290 METHOD is "REQUEST" is scheduled. The component becomes booked when 1291 the METHOD is changed to "CREATED". 1293 Several scheduled entries can be in the CS for the same UID. They 1294 are consolidated when booked. Or they are removed from the CS. 1296 For example, if you were on vacation, you could have a REQUEST to 1297 attend a meeting and several updates to that meeting. Your CUA would 1298 have to READ them out of the CS using CAP, process them, determine 1299 what the final state of the object from a possible combination of 1300 user input and programmed logic. Then the CUA would instruct the CS 1301 to CREATE a new booked entry or MODIFY an existing entry. Followed 1302 by a DELETE of all of these now old scheduling requests in the CS. 1303 See [iTIP] for details on resolving multiple [iTIP] scheduling 1304 entries. 1306 3. State Diagram 1308 This section describes the states of the transport connection between 1309 a CUA and a CS. The state diagram is shown below. State names are 1310 shown with first letter capitalized. Commands used to switch between 1311 states are shown next to an arrow connecting the states. The 1312 commands are listed in all capital letters. A condition that causes 1313 a state to change is shown in lower case letters. 1315 STARTTLS / 1316 CAPABILITY 1317 +-------+ 1318 | | +---------------+ 1319 | +-----------+ AUTHENTICATE | | 1320 +-->| Connected |-------------->| Authenticated | 1321 +-----------+ | | 1322 | +---------------+ 1323 | | 1324 | | +-----+ 1325 | V | |STARTTLS / 1326 | +---------------+ |IDENTIFY 1327 | | |<-+ 1328 | | Identified |<-----+ 1329 | +--------| | | 1330 | | +---------------+ | 1331 | | | command| 1332 V |DISCONNECT | completes| 1333 +--------------+ | | | 1334 | Disconnected |<--+ | | 1335 +--------------+ |SENDDATA | ABORT 1336 A | | 1337 | V | 1338 | DISCONNECT +---------------+ | 1339 +--------------------| Receive |------+ 1340 | |<--+ 1341 +---------------+ | 1342 | | 1343 +----+ 1344 CONTINUE 1346 The connection begins the Connected state when a CUA connects to a 1347 CAP server. The capabilities of the CS are reported in the response 1348 from the CS. From this state, the CUA can issue the DISCONNECT 1349 command to terminate the connection, the CAPABILITY, STARTTLS, or 1350 AUTHENTICATE commands. One use of the CAPABILITY command at this 1351 stage is to determine the supported authentication mechanisms 1352 supported by the server. Once the STARTTLS command has been 1353 successfully executed from either the Connected or Authenticated 1354 state, it must not be executed again. 1356 If an AUTHENTICATE command is successful, the connection enters the 1357 Authenticated state and then immediately goes to the IDENTIFIED 1358 state. While in the Identified state, the CALIDEXPAND and UPNEXPAND 1359 commands can be executed. From here the CUA can issue the CAPABILITY 1360 command. The capabilities offered by the server in the Authenticated 1361 state may be different than those in the Connected state to allow for 1362 the user's realm to be used to grant or deny features. The CUA can 1363 also use the IDENTIFY command to change the identity of the user 1364 subject to access control. The connection remains in the Identified 1365 state after the CAPABILITY command completes. The CUA can issue the 1366 DISCONNECT command to terminate the connection. The SENDDATA command 1367 can be used to send a request to read, write, modify, or delete data 1368 on the server. 1370 After the SENDDATA command has been issued the connection enters the 1371 Receive state while the CUA awaits and reads a server reply. 1372 Normally, the server handles the command, sends a reply which is read 1373 by the CUA and the connection returns to the Authenticated state. 1374 The CUA may have issued the SENDATA command with a maximum latency 1375 time. This informs the server that the CUA expects a response within 1376 the maximum latency time, even if the command was not completed. 1377 When the server is unable to complete the command in the maximum 1378 latency time, it issues an appropriate reply code and waits for the 1379 CUA to tell it how to proceed. If the CUA issues a CONTINUE command 1380 the server continues processing the command and the connection 1381 remains in the Receive state. If the CUA issues the ABORT command 1382 the server need not process the command any further and the 1383 connection returns to the Identified state. The DISCONNECT command 1384 can also be issued from the Receive state. 1386 4. Protocol Framework 1388 4.1 CAP Application Layer 1390 The CAP application layer is used for the manipulation of the 1391 calendar store. Commands and responses are transmitted between the 1392 CUA and CS inside "VCAP" wrappers. Commands are specified as the 1393 value of a "METHOD" property, and responses are specified as the 1394 value of a "REQUEST-STATUS" property. An optional "CMDID" may be 1395 used to uniquely identify commands. 1397 4.2 CAP Transfer Protocol 1399 The CAP transfer protocol defines the format of data transmitted 1400 between a CUA and the CS. 1402 CAP transfer protocol commands are transmitted using the underlying 1403 transport. The transport used is a TCP/IP socket connection between 1404 the CUA and the CS. The default port that the CS listens for 1405 connections on is port 5229. 1407 Messages sent between the CUA and CS are formatted as a command 1408 followed by any associated data: 1410 [] 1412 Server responses consist of a response code and any parameters: 1414 [response-args] [; debug-text ] 1415 . 1416 [] 1417 . 1419 The response-args are defined in Section 8. The debug-text is human- 1420 readable information for protocol debugging and is optional and is 1421 only used to aid developers writing CSs and CUAs. The debug-text 1422 MUST not be depended on by CUAs in normal interactions with a CS. 1424 The optional application-data begins on the next line. 1426 The response is terminated with the second "." 1427 sequence. Any "." sequences which appear in the transmitted 1428 data must be quoted by placing an additional "." between the 1429 and the ".". For example, the following sequences of characters in 1430 the application data: 1432 . 1433 ..2 1434 ...3 1436 are quoted as follows: 1438 .. 1439 ...2 1440 ....3 1442 4.3 Pipelining Commands 1444 If the CS returns a PIPELINE number greater then one (1) as a 1445 result of a CAPABILITY command then the CUA can send up to PIPELINE 1446 VCAP (each with a unique CMDID/VCOMMAND) without waiting for the CS 1447 to reply. 1449 It is unspecified what happens of the CUA exceedes the CS limit. 1451 4.4 Auto-logout Timer 1453 If a server has an inactivity auto-logout timer, that timer MUST be 1454 of at least 15 minutes duration if there is no value of 1455 AUTOLOGOUTTIME returned in the CS CAPABILITY reply. The receipt of 1456 ANY command from the client during that interval MAY reset the auto- 1457 logout timer, subject to CS administrators policy. A CUA may be 1458 discouraged from attempts to do useless things only to keep the 1459 connection alive. 1461 A CS MAY have different AUTOLOGOUTTIME values depending on the UPN or 1462 the realm of the UPN. 1464 When a timeout occurs, the server drops the connection to the CUA. 1466 4.5 Bounded Latency 1468 CAP is designed so that the CUA can either obtain an immediate 1469 response from a request or discover within a specified amount of time 1470 that the request could not be completed in the requested amount of 1471 time. When the CUA initiates a command that the server cannot 1472 complete within the specified latency time, the server returns an 1473 appropriate response code. The CUA then issues either a CONTINUE or 1474 ABORT command. The ABORT command immediately terminates the command 1475 in progress identified by CMDID and the connection returns to the 1476 Authenticated state. The CONTINUE command instructs the server to 1477 continue processing the command identified by the CMDID. 1479 4.6 Data Elements 1481 The data elements for CAP are [MIME] encapsulated iCalendar objects. 1483 5. Formal Command Syntax 1485 5.1 Searching and Filtering 1487 This section describes CAP's selecting and filtering entities within 1488 a calendar store. It is based on the Standard Query Language (SQL) 1489 defined in [SQL]. 1491 5.1.1 Grammar For Search Mechanism 1493 search = "BEGIN:VQUERY" CRLF 1494 [expand] [maxresults] [maxsize] querycomp 1495 "END:VQUERY" CRLF 1497 expand = "EXPAND" ":" ( "TRUE" / "FALSE") 1498 # the default is EXPAND:FALSE 1500 comp-name = "VEVENT" / "VTODO" / "VJOURNAL" 1501 / "VTIMEZONE" / "VALARM" / "VFREEBUSY" 1502 / "VCAR" / iana-name / x-name 1504 maxresults = "MAXRESULTS" ":" integer 1506 maxsize = "MAXSIZE" ":" integer 1508 querycomp = ( query ) / ( queryname query ) / queryname 1510 queryname = "QUERYNAME:" text 1512 query = "QUERY:" ( query-min / query-92 ) 1513 # 1514 # NOTE: query-min MUST be implemented in CSs. 1515 # 1516 # query-92 is ONLY used if CAPABILITY returns SQL-92 1517 # as the QUERYLEVEL value or if QUERYLEVEL is not 1518 # specified. 1519 # 1521 query-min = capselect-min capfrom-min capwhere-min 1523 capselect-min = "SELECT" capmin-cols "FROM" capmin-comps 1524 "WHERE" capmin-cmp 1526 capmin-col = # Any property name found in any of the 1527 components. 1529 capmin-cols = ( capmin-col / capmin-col "," 1530 capmin-cols ) 1532 capmin-comps = ( comp-name / comp-name "," 1533 compmin-comps ) 1535 capmin-cmp = ( colname cmpmin-oper colvalue 1536 / colname cmpmin-oper colvalue 1537 capmin-logical capmin-cmp ) 1539 colname = ( # Any valid component property name. 1540 / "*" ) 1542 cmpmin-oper = ( " = " / " != " / " < " / " > " / " <= " 1543 / " >= " ) 1545 capmin-logical = ( " AND " / " OR " ) 1547 query-92 = capselect-92 capfrom-92 capwhere-92 1548 caporderby-92 1550 capselect-92 = # Any valid [SQL] string that goes into 1551 a SELECT clause. 1553 capfrom-92 = # Like capmin-comps except embedded spaces 1554 # are allowed between commas - per [SQL]. 1556 capwhere-92 = # Any valid [SQL] string that goes into a 1557 # WHERE clause. 1559 caporderby-92 = # Any valid [SQL] string that goes into a 1560 # ORDERBY clause. 1562 5.1.2 SQL-MIN notes 1564 (1) No inlined spaces are allowed if not in the grammar above. 1566 (2) Note that cmpmin-oper and capmin-logical elements are 1567 surrounded by exactly one space. 1569 Use 'VEVENT,VTODO', not 'VEVENT, VTODO' 1570 Use 'DTSTART <= 20000605T131313Z', not 1571 'DTSTART<= 20000605T131313Z'. 1572 Use ' AND ' and ' OR ', not 'AND' and not 'OR'. 1574 (3) There is no ORDERBY. Sorting will take place in the order the 1575 columns are supplied in the command. 1577 (4) The CS MUST sort at least the first column.The CS MAY sort 1578 additional columns. 1580 (5) If EXPAND=FALSE and if colname is "*" sorting will be by the 1581 DTSTART value ascending. If EXPAND=TRUE and if colname is "*" 1582 sorting will be by the RECURRENCE-ID value ascending. 1584 If colname is "*" and capmin-coms is VALARM only then sorting will 1585 be by TRIGGER time in GMT ascending. 1587 (6) SQL-MIN MUST be implemented. 1589 5.1.3 SQL-92 notes 1591 (1) Although this memo specifies that any [SQL] query can be used, 1592 some of the [SQL] grammar is optional and therefore is considered 1593 optional in CSs advertising an SQL-92 implementation with CAPABILITY. 1595 (2) A CS implementation MAY implement SQL-92. If a CS does not 1596 implement SQL-92 then it MUST advertise SQL-MIN in the capability 1597 reply. 1599 5.1.4 Example, Query by UID 1601 This example would select the entire contents of uid123 and not 1602 expand any multiple instances of the component. If the CUA does not 1603 know if 'uid123' was a VEVENT, VTODO, VJOURNAL, or other component, 1604 then all components that the CUA supports MUST be supplied on the 1605 QUERY property. This example assumes the CUA only supports VTODO and 1606 VEVENT. 1608 If the results were empty it could also mean that 'uid123' was a 1609 property in a component other than a VTODO or VEVENT. 1611 BEGIN:VQUERY 1612 QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123' 1613 END:VQUERY 1615 This example would select the entire contents of uid123 and would 1616 expand any instances of the component after applying any recurrence 1617 rules. This query could select multiple instances of components each 1618 with the same UID. Each instance would have a unique RECURRENCE-ID 1619 of the expanded component. 1621 BEGIN:VQUERY 1622 EXPAND:TRUE 1623 QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123' 1624 END:VQUERY 1626 5.1.5 Query by Date-Time range 1628 This query selects the entire contents of every booked VEVENT that 1629 has an instance less than or equal to July 31st, 2000 23:59:59 Z and 1630 greater than or equal to July 1st, 2000 00:00:00 Z 1632 BEGIN:VQUERY 1633 EXPAND:TRUE 1634 QUERY:SELECT * FROM VEVENT 1635 WHERE RECURRENCE-ID >= '20000801T000000Z' 1636 AND RECURRENCE-ID <= '20000831T235959Z' 1637 AND METHOD = 'CREATE' 1638 END:VQUERY 1640 5.1.6 Query for all Non-Booked Entries 1642 This example selects the entire contents of all scheduling (non- 1643 booked) VEVENTS in the CS. The default for EXPAND is FALSE, so the 1644 recurrence rules will not be expanded. 1646 BEGIN:VQUERY 1647 QUERY:SELECT * FROM VEVENT,VTODO WHERE METHOD != 'CREATE' 1648 END:VQUERY 1650 The following example fetches the UIDs of all non-booked VEVENTs and 1651 VTODOs. 1653 BEGIN:VQUERY 1654 QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE' 1655 END:VQUERY 1657 5.1.7 Query with Subset of Properties by Date/Time 1659 This MUST implement is similar to the one above, except only the 1660 named properties will be selected and all booked and non- booked 1661 components will be selected that have a DTSTART from Feb 1st to Feb 1662 10th. 1664 BEGIN:VQUERY 1665 QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT 1666 WHERE DTSTART >= '20000201T000000Z' 1667 AND DTSTART <= '20000210T235959Z' 1669 END:VQUERY 1671 5.1.8 Components With Alarms In A Range 1673 This example fetches all components with an alarm that triggers 1674 within the specified time range. In this case only the UID, SUMMARY, 1675 and DESCRIPTION will be selected for all booked VEVENTS that have an 1676 alarm between the two date-times. 1678 BEGIN:VQUERY 1679 EXPAND:TRUE 1680 QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT 1681 WHERE VALARM.TRIGGER >= '20000101T030405Z' 1682 AND VALARM.TRIGGER <= '20001231T235959Z' 1683 AND METHOD = 'CREATE' 1684 END:VQUERY 1686 6. Access Rights 1688 Access rights within CAP are specified with the "VCAR" calendar 1689 component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" 1690 component properties. 1692 Individual calendar access rights MUST be specifically granted to an 1693 authenticated calendar user (i.e., UPN); all rights are denied unless 1694 specifically granted. 1696 Properties within a VCAR must be evaluated in the order provided. 1698 6.1 VCAR Inheritance 1700 Calendar access rights specified in a calendar store are inherited as 1701 default calendar access rights for any calendar in the parent 1702 calendar store. Likewise, any calendar access rights specified in a 1703 root calendar are inherited as default calendar access rights for any 1704 sub- calendar to the root calendar. By implication, calendar access 1705 rights specified in a sub-calendar are inherited as default calendar 1706 access rights for any calendars that are hierarchically below the 1707 sub- calendar. 1709 Calendar access rights specified in a calendar override any default 1710 calendar access rights. Calendar access rights specified within a 1711 sub-calendar override any default calendar access rights. 1713 6.2 Access Control and NOCONFLICT 1715 The TRANSP property can take on values (TRANSPARENT- NOCONFLICT, 1716 OPAQUE-NOCONFLICT) that prohibit other events from overlapping it. 1717 This setting overrides access While access control may allow a UPN to 1718 store an event on a particular calendar. , the CONFLICTS Calendar or 1719 component setting may prevent it, returning an error code "6.3" 1721 7. Commands and Responses 1723 CAP commands and responses are described in this section. 1725 Command arguments, identified by "Arguments:" in the command 1726 descriptions below, are described by function, not by syntax. The 1727 precise syntax of command arguments is described in the Formal Syntax 1728 section. 1730 Some commands cause specific server data to be returned; these are 1731 identified by "Data:" in the command descriptions below. See the 1732 response descriptions in the Responses section for information on 1733 these responses, and the Formal Syntax section for the precise syntax 1734 of these responses. 1736 The "Result:" in the command description refers to the possible 1737 status responses to a command, and any special interpretation of 1738 these status responses. 1740 Commands have the general form: 1742 [arguments...] 1744 where is a command listed in the table above. A command 1745 MAY have arguments. Arguments are defined in the detailed command 1746 definitions below. 1748 Responses to commands have the following general form: 1750 responseCode [sep transportDescr sep 1751 [applicationDescr]] 1752 CRLF "." CRLF 1754 In the examples below, lines preceded with "S:" refer to the sender 1755 and lines preceded with "R:" refer to the receiver. Lines in which 1756 the first non-whitespace character is a "#" are editorial comments 1757 and are not part of the protocol. 1759 7.1 Transfer Protocol Commands 1761 7.1.1 Initial Connection 1763 Arguments: none 1765 Data: none 1767 Result: 2.0 - success. 8.1 - server too busy 1768 Upon session startup, the server sends a response of 2.0 to indicate 1769 that it is ready to receive commands. A response of 8.1 indicates 1770 that the server is too busy to accept the connection. In addition, 1771 the general capabilities of the CS are reported in the response from 1772 the CS. These capabilities may be different than those reported in 1773 the authenticated state. 1775 7.1.2 ABORT Command 1777 Arguments: [CMDID] 1779 Data: none 1781 Result: 2.0 - success 2.2 - no command is in progress 1783 The ABORT command is issued by the CUA to stop a command. A common 1784 usage could be to ABORT a command whose latency time has been 1785 exceeded. When the latency time is specified on the SENDATA command, 1786 the CS must issue a reply to the CUA within the specified time. It 1787 may be a reply code indicating that the CS has not yet processed the 1788 request. The CUA must then tell the server whether to continue or 1789 abort. 1791 The CUA can issue the ABORT command at any time after the SENDATA 1792 command has been completed but before receiving a reply. 1794 If CMDID is supplied then the command identified by CMDID is aborted. 1796 If CMDID is not supplied then the fist command that is still pending 1797 is aborted. 1799 7.1.3 AUTHENTICATE Command 1801 Arguments: [] 1803 Data: continuation data may be requested 1805 Result: 1807 2.0 - Authenticate completed, now in authenticated state. 1809 6.0 - Failed authentication. 6.1 - Authorization identity 1810 refused. 1812 6.2 - Sender aborted authentication, authentication exchange 1813 cancelled. 1815 6.3 - Unsupported Authentication Mechanism. 1817 6.4 - Temporary failure (back end authentication server down). 1819 6.5 - Authentication exchange cancelled. 1821 6.6 - Authentication mechanism too weak. 1823 6.7 - Encryption required. 1825 6.8 - Pass phrase expired. The pass phrase was correct but 1826 expired. The user will have to contact a pass phrase change 1827 server prior to authenticating. 1829 6.9 - The user is valid but the server does not have an entry in 1830 the authentication database for the requested mechanism (e.g., 1831 DIGEST- MD5). If the user successfully authenticates using a 1832 plain text password, then the back end back end entry will be 1833 updated. Note that if the client chooses to fall back to plain 1834 text password authentication it should enable an encryption layer 1835 or get user-con- firmation that a one-time transition is ac- 1836 ceptable. 1838 6.10 - User account disabled. The user will have to contact the 1839 system administrator to get the account re-enabled. 1841 9.1 - Unexpected command. 1843 The capabilities of the CS in the authenticated state are reported in 1844 the response from the CS. These may be different than the 1845 capabilities in the Connected, but unauthenticated state. 1847 The AUTHENTICATE command is used by the CUA to identify the user to 1848 the CS. CAP supports a number of authentication methods, the SASL 1849 specification for authentication is the preferred method. 1851 If STARTTLS is negotiated prior to the AUTHENTICATE command, the 1852 client MUST discard all information about the CS capabilities fetched 1853 prior to the TLS negotiation. In particular, the value of supported 1854 SASL Mechanisms MAY be different after TLS has been negotiated. 1856 If a SASL security layer is negotiated, the client MUST discard all 1857 information about the CS capabilities fetched prior to SASL. In 1858 particular, if the client is configured to support multiple SASL 1859 mechanisms, it SHOULD fetch supported SASL Mechanisms both before and 1860 after the SASL security layer is negotiated and verify that the value 1861 has not changed after the SASL security layer was negotiated. This 1862 detects active attacks which remove supported SASL mechanisms from 1863 the supported SASL Mechanisms list. 1865 is an optional parameter which can be used for 1866 mechanisms which require an initial response from the CUA. 1868 The AUTHENTICATE command is followed by an authentication protocol 1869 exchange, in the form of a series of CS challenges and CUA responses, 1870 per the relevant RFC that describes the specific SASL mechanism being 1871 used. 1873 Cancelling the authentication process during its negotiation is 1874 implementation specific and not within scope of the CAP 1875 specification. 1877 If a security layer was negotiated it comes into effect for the CS 1878 starting with the first octet transmitted after the CRLF which 1879 follows the 2.0 reply code, and for the CUA starting with the first 1880 octet after the CRLF of its last response in the authentication 1881 exchange. Encrypted data is transmitted as described in SASL. 1883 The service name specified by this protocol's profile of SASL is 1884 "cap". [EDITORS NOTE: this must be registered with IANA, has anyone 1885 done this yet?] 1887 The result of the AUTHENTICATE command includes data indicating the 1888 identity which has been assigned to the session, derived from the 1889 supplied authentication credentials, and/or authorization identifier. 1890 A CAP session does not have an identity until the CUA has issued the 1891 "AUTHENTICATE" command. 1893 The CUA may not issue the "AUTHENTICATE" command multiple times, even 1894 if the first attempt was aborted. If a CUA attempts to do this the 1895 CS must terminate the session. 1897 Here is an example of a successful authentication: 1899 C: AUTHENTICATE KERBEROS_V4 1900 S: AmFYig== 1901 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 1902 S: or//EoAADZI= 1903 C: DiAF5A4gA+oOIALuBkAAmw== 1904 S: 2.0 1905 S: . 1906 S: Content-Type:text/calendar; method=REQUEST; 1907 S: charset=US-ASCII 1908 S: Content-Transfer-Encoding: 7bit 1909 S: 1910 S: BEGIN:VCAP 1911 S: PRODID:-//ACME/CAPserver//EN 1912 S: VERSION:2.1 1913 S: IDENTITY=bill@example.com 1914 S: CAPVERSION=1.0 1915 S: ITIPVERSION=1.0 1916 S: AUTH=KERBEROS_V4 1917 S: AUTH=DIGEST_MD5 1918 S: CAR=CAR-FULL-1 1919 S: MINDATE=19700101T000000Z 1920 S: MAXDATE=20370201T000000Z 1921 S: END:VCAP 1922 S: . 1924 This example shows a failed authentication: 1926 C: AUTHENTICATE KERBEROS_V4 1928 S: AmFYig== 1929 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 1930 S: . 1931 S: 6.0 1932 S: . 1933 S: . 1935 7.1.3.1 AUTHENTICATE ANONYMOUS 1937 RFC-2245 defines the Anonymous SASL mechanism. This RFC states that 1938 "the mechanism consists of a single message from the client to the 1939 server. The client sends optional trace information in the form of a 1940 human readable string. The trace information should take one of 1941 three forms: an Internet email address, an opaque string which does 1942 not contain the '@' character and can be interpreted by the system 1943 administrator of the client's domain, or nothing. For privacy 1944 reasons, an Internet email address should only be used with 1945 permission from the user." 1947 RFC-2245 goes on to state, "A client which uses the user's correct 1948 email address as trace information without explicit permission may 1949 violate that user's privacy." Information about who accesses an 1950 anonymous CS on a sensitive subject (e.g., AA meeting times and 1951 locations) has strong privacy needs. "Clients should not send the 1952 email address without explicit permission of the user and should 1953 offer the option of supplying no trace token -- thus only exposing 1954 the source IP address and time." 1956 Example of CUA using the Capability command followed by an anonymous 1957 authentication: 1959 C: CAPABILITY 1960 S: 2.0 1961 S:CAPVERSION=1.0 1962 S:AUTH=KERBEROS_V4 1963 S:AUTH=DIGEST_MD5 1964 S:AUTH=ANONYMOUS 1965 S:. 1966 C:AUTHENTICATE ANONYMOUS 1967 S:+ 1968 C:c21yaGM= 1969 S:2.0 1971 Subsequent to the initial Anonymous Authentication with a CS, a CUA 1972 will have to provide a UPN for some CAP operations. For anonymous 1973 access the UPN that MUST be used by the CUA is "@", a UPN with a null 1974 username and null realm. The user's normal UPN MUST not be used for 1975 the subsequent CAP operations. 1977 Note that the CS implementation may have internal audit logs that use 1978 the user's asserted UPN as trace information. However, this UPN will 1979 not appear on the wire after the initial SASL anonymous 1980 authentication. 1982 Use of the "@" UPN and wild-carding of UPNs within VCARs are covered 1983 in 1985 Section . 1987 7.1.4 CALIDEXPAND Command 1989 Arguments: CalID 1991 Data: no specific data for this command 1993 Result: 2.0 Successful, and requested data follows 1995 2.1 Permission Denied 1997 2.2 Requested CSID not found 1999 2.3 Result exceeds MAXEXPANDLIST 2001 2.4 Misc. EXPAND error 2003 Return the members of the argument CalID. Successful result yields 2004 one or more Calendars and/or Resource Calendars. More than one C or 2005 RC returned implies that the CalID was a CC. 2007 If the number of items exceeds MAXCALIDEXPAND, then up to 2008 MAXCALIDEXPAND items are returned along with result 2.3. 2010 If the result is 2.4, then as many of the items as possible will be 2011 returned. It is possible that no items will be returned. The 2.4 2012 response may have optional text describing the problem. Any such 2013 text MUST be in the language and charset that is defined by the 2014 calendar store properties LANGUAGE and CHARSET. If calendar store 2015 CHARSET is not set, but the LANGUAGE property is set, then the 2016 error message will be in LANGUAGE in the UTF-8 charset. If calendar 2017 store LANGUAGE property is not set, then the CS MUST NOT return any 2018 text with the results. 2020 Examples: 2022 Example #1: Request lookup of CSID which is a Calendar Collection 2024 C: CALIDEXPAND cap://cal.example.com/calid14 2025 S: 2.0 2026 S: cap://cal.example.com/calid14 2027 S: cap://cal.example.com/calid2 2028 S: cap://cal.example.com/calid5 2029 S: cap://cal.example.com/calid66 2030 S: . 2032 Example #2: Request lookup a CSID which is a Resource Calendar 2034 C: CALIDEXPAND cap://cal.example.com/conf5 2035 S: 2.0 2036 S: cap://cal.example.com/conf5 2037 S: cap://cal.example.com/conf5 2038 S: . 2040 Example #3: Request CSID which exceeds MAXCALIDEXPANDLIST 2042 C: CALIDEXPAND cap://cal.example.com/calid76 2043 S: 2.3 Expansion resulted in too much data 2044 S: cap://cal.example.com/calid76 2045 S: cap://cal.example.com/calid3 2046 S: cap://cal.example.com/calid12 2047 S: cap://cal.example.com/calid21 2048 S: cap://cal.example.com/calid33 2049 S: . 2051 Example #4: CS loses contact with directory server during CALIDEXPAND 2053 C: CALIDEXPAND cap://cal.example.com/calid76 2054 S: 2.4 Lost contact with directory server 2055 S: cap://cal.example.com/calid76 2056 S: cap://cal.example.com/calid3 2057 S: cap://cal.example.com/calid5 2058 S: . 2060 7.1.5 CAPABILITY Command 2062 Arguments: none 2064 Data: none 2066 Result: capabilities as described below 2068 The CAPABILITY command returns information about the CAP server given 2069 the current state of the connection with the client. The values 2070 returned may differ depending on whether the connection is in the 2071 Connected or the Authenticated state. The return values may also be 2072 different for a secure versus a non-secure connection. 2074 Client implementations SHOULD NOT require any capability name beyond 2075 those defined in this specification, and MAY ignore any non-standard, 2076 experimental capability names. Non-standard experimental capability 2077 names MUST be prefixed with the text "X-". The prefix SHOULD also 2078 include a short character vendor identifier For example, "X-FOO- 2079 BARCAPABILITY", for the non- standard "BARCAPABILITY" capability of 2080 the implementor "FOO". This command may return different results in 2081 the Connected state versus the Authenticated state. It may also 2082 return different results depending on the UPN. 2084 Capability Occurs Description 2085 ------------------------------------------------------- 2086 AUTH 1+ The authentication mechanisms 2087 supported. Implementations MUST 2088 implement at least 2090 AUTOLOGOUTTIME 2091 0 or 1 An integer value that specifies 2092 the default idle time in seconds 2093 the CS will wait before 2094 disconnecting an idle CUA.If the 2095 CS is busy the CS may adjust down 2096 the auto-logout timer. If not 2097 specified, the value is 15 minutes 2098 (900 seconds). A value of zero (0) 2099 indicates unlimited connect time 2100 is allowed. 2102 CAPVERSION 1 Revision of CAP, MUST include at 2103 least "1.0". Comma separated 2104 values. 2106 ITIPVERSION 0 or 1 Revision of ITIP, MAY be present. 2107 If present, it MUST include at 2108 least "1.0" 2109 CAR 0 or 1 Indicates level of CAR support. 2110 CAR-MIN or CAR-FULL-1. If not 2111 specified the default is 2112 CAR-FULL-1. Implementations 2113 MUST implement CAR-MIN. 2114 Implementations MAY implement 2115 CAR-FULL-1. 2117 QUERYLEVEL 0 or 1 Indicates level of SQL support. 2118 SQL-MIN or SQL-92. If not 2119 specified the default is SQL-92. 2120 Implementations MUST implement 2121 SQL-MIN. Implementations MAY 2122 implement SQL-92. 2124 MAXICALOBJECTSIZE 2125 0 or 1 An integer value that specifies 2126 The largest ICAL object the server 2127 will accept in bytes. Objects 2128 larger than this will be rejected. 2129 A value of zero (0) indicates 2130 unlimited. The default is zero (0) 2131 if not specified. 2133 MAXDATE 0 or 1 The datetime value in GMT beyond 2134 which the server cannot accept. If 2135 not specified the default is 2136 99991231T235959Z. 2138 MAXCALIDEXPANDLIST 2139 0 or 1 An integer value that specifies 2140 the maximum number of CalIDs that 2141 can be returned by the CALIDEXPAND 2142 Command. A value of zero (0) 2143 indicates unlimited which is the 2144 default if not specified. 2146 MAXUPNEXPANDLIST 2147 0 or 1 An integer value that specifies 2148 the maximum number of UPNs that 2149 can be returned by the UPNEXPAND 2150 Command. A value of zero (0) 2151 indicates unlimited which is the 2152 default if not specified. 2154 MINDATE 0 or 1 The datetime value prior to which 2155 the server cannot accept. If not 2156 specified the default is 2157 00000101T000000Z. 2159 PIPELINE 0 or 1 An integer value that specifies 2160 the maximum number of commands a 2161 CUA may send without the CUA 2162 waiting for a reply from the CS. 2163 If not specified, the default 2164 value is one (1). A value of zero 2165 (0)indicates unlimited. 2167 Example: 2169 C: CAPABILTIY 2170 S: 2.0 2171 S: . 2172 S: CAPVERSION=1.0 2173 S: ITIPVERSION=1.0 2174 S: AUTH=KERBEROS_V4 2175 S: AUTH=DIGEST_MD5 2176 S: . 2178 7.1.6 CONTINUE Command 2180 Arguments: latency time in seconds (optional) 2182 Data: none 2184 Result: results from the command in progress 2.0.2 - reply pending. 2186 The CONTINUE command is issued by the client in response to a SENDATA 2187 timeout. When a timeout value is specified on the SENDDATA command, 2188 the server must issue a reply to the client within the specified 2189 time. If the latency time has elapsed prior to the server completing 2190 the command it returns a timeout response code. If the client wants 2191 the server to continue processing the command it responds with the 2192 CONTINUE command. 2194 If latencyTime is present, it must be a positive integer that 2195 specifies the maximum number of seconds the client will wait for the 2196 next response. If it is omitted, the receiver waits an indefinite 2197 period of time for the response. 2199 In this example, the client requests a response from the server every 2200 10 seconds. 2202 C: SENDDATA:10 2203 C: Content-Type:text/calendar; method=READ; component=VEVENT 2204 C: 2205 C: BEGIN:VCAP 2206 # etc 2207 C: END:VCAP 2208 C: . 2209 # after 10 seconds... 2210 S: . 2211 S: 2.0.2 2212 S: . 2213 S: . 2214 C: CONTINUE:10 2215 S: 2.0 2216 S: . 2217 S: Content-type:text/calendar; 2218 S: Method=RESPONSE;Component=VCAP; 2219 S: Optinfo=VERSION:2.1 2220 S: 2221 S: BEGIN:VCAP 2223 S: VERSION:2.1 2224 S: CALID:cap://cal.example.com/relcal2 2225 # etc. 2226 S: END:VCAP 2227 S: . 2229 7.1.7 DISCONNECT Command 2231 Arguments: none 2233 Data: 2235 Result: 2.0 2237 The DISCONNECT command is used by a client to terminate a connection. 2238 It always succeeds. 2240 The CUA MUST wait for the CS 2.0 reply to ensure that TCP/IP (which 2241 knows nothing about CAP) can be sure the connection should go away. 2242 This avoids the CS connection being stuck in TCP-WAIT state. 2244 Example: 2246 C: DISCONNECT 2247 # [EDITORS NOTE: Note: should the client now wait for a response from 2248 the 2249 server 2250 # before disconnecting? ] 2251 S: 2.0 2252 S: . 2253 S: . 2254 S: 2255 C: 2257 7.1.8 IDENTIFY Command 2259 Arguments: Identity to assume 2261 Data: None 2263 Result: 2.0 .4 Identity not permitted 2265 The "IDENTIFY" command allows the CUA to select a new identity to be 2266 used for calendar access. This command may only be called in the 2267 Identified State. 2269 The CS determines through an internal mechanism if the credentials 2270 supplied at authentication permit the assumption of the selected the 2271 identity. If they do the session assumes the new identity, otherwise 2272 a security error is returned. 2274 7.1.9 SENDDATA Command 2276 Arguments: [latencyTime] 2278 Data: a [MIME] encapsulated iCalendar object 2280 Result: 2.0.1 - Server will now accept input until . 2281 is encountered. 2283 The SENDDATA command is used to send calendar requests and commands 2284 to the server. After a response code of 2.0.1 is issued the CUA 2285 sends a [MIME] encapsulated iCalendar object to the server. The end 2286 of this [MIME] data is signaled by the special sequence . 2287 . 2289 7.1.10 STARTTLS Command 2291 Arguments: None 2293 Data: None 2295 Result: 2.0 5 TLS not supported 2297 The "STARTTLS" command is issued by the CUA to indicate to the CS 2298 that it wishes to negotiate transport level security using [TLS]. If 2299 the CS does not support TLS it returns status code 6.5. If the CS 2300 supports TLS it issues an initial response of 2.0.12 indicating that 2301 the CUA should proceed with TLS negotiation. Once the TLS 2302 negotiation is complete the server returns the response code 2.0. 2304 After issuing the "STARTTLS" command the CUA issues the 2305 "AUTHENTICATE" command. The SASL external mechanism may be used if 2306 the CUA wishes to use the authentication id which was used in the TLS 2307 negotiation. 2309 The CUA MUST NOT issue a "STARTTLS" if it has already issued an 2310 "AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does 2311 this the CS must terminate the session. 2313 The following examples illustrate the use of the "STARTTLS" command: 2315 Unsupported TLS: 2317 C: STARTTLS 2318 S: 6.5 2320 Supported TLS: 2322 C: STARTTLS 2323 S: 2.0.12 2324 2325 S: 2.0 2327 S: . 2328 S: . 2330 7.1.11 UPNEXPAND Method 2332 Arguments: UPN 2334 Data: no specific data for this command 2335 Result: 2.0 - success 2.1 Permission Denied 2.2 Requested UPN not 2336 found 2.3 Result exceeds MAXUPNEXPANDLIST 2.4 Misc. UPNEXPAND error 2338 Return the members of the argument UPN. Successful result yields one 2339 or more CalIDs. More than one CalID returned implies that the UPN 2340 was a UG. 2342 If the number of items exceeds MAXUPNEXPANDLIST, then up to 2343 MAXUPNEXPANDLIST items are returned along with result 2.3. 2345 If the result is 2.4, then as many of the items as possible will be 2346 returned. It is possible that no items will be returned. The 2.4 2347 response may have optional text describing the problem. Any such 2348 text MUST be in the language and charset that is defined by the 2349 calendar store properties LANGUAGE and CHARSET. 2351 If calendar store CHARSET is not set, but the LANGUAGE property is 2352 set, then the error message will be in LANGUAGE in the UTF-8 2353 charset. If calendar store LANGUAGE property is not set, then the 2354 CS MUST NOT return any text with the results. 2356 Example #1: Request lookup of a UPN which is a CU 2358 C: UPNEXPAND upn@example.com 2359 S: 2.0 2360 S: upn@example.com 2361 S: cap://cal.example.com/calid3 2362 S: . 2364 Example #2: Request lookup of UPN which is a UG 2366 C: UPNEXPAND group@example.com 2367 S: 2.0 2368 S: group@example.com 2369 S: cap://cal.example.com/calid3 2370 S: cap://cal.example.com/calid6 2371 S: cap://cal.example.com/calid1342 2372 S: . 2374 Example #3: Request lookup exceeds MAXUPNEXPANDLIST 2376 C: UPNEXPAND group@example.com 2377 S: 2.3 Lookup resulted in too much data 2378 S: group@example.com 2379 S: cap://cal.example.com/calid3 2380 S: cap://cal.example.com/calid12 2381 S: cap://cal.example.com/calid21 2382 S: cap://cal.example.com/calid33 2383 S: . 2385 Example #4: CS loses contact with directory server during UPNEXPAND 2387 C: UPNEXPAND group@example.com 2388 S: group@example.com 2389 S: 2.4 Lost contact with directory server 2390 S: cap://cal.example.com/calid3 2391 S: cap://cal.example.com/calid5 2392 S: . 2394 7.1.12 NOOP Command 2396 Arguments: none 2398 Data: none 2400 Result: 2.0 - success 2402 This method does nothing. It can be sent to the server periodically 2403 to request that the CS not time out the session. 2405 [EDITORS NOTE: should an unauthenticated and unidentified client be 2406 able to issue this command?] 2408 [EDITORS NOTE: need to add NOOP in the state diagram?] 2410 Example: 2412 C: NOOP 2414 S: 2.0 2415 S: . 2417 7.2 Application Protocol Commands 2419 7.2.1 Calendaring Commands 2421 The following methods provide a set of calendaring commands in CAP. 2422 Calendaring commands (or methods) allow a CU to directly manipulate a 2423 calendar. 2425 Calendar access rights can be granted for the more generalized access 2426 provided by the calendar commands. 2428 7.2.1.1 Restriction Tables 2430 Commands are sent to CAP servers encapsulated in iCalendar objects. 2431 The reply to these commands are also encapsulated in iCalendar 2432 objects. The restriction tables listed in the commands below 2433 describe the composition of the iCalendar data for these commands and 2434 replies. 2436 The Presence column uses the following values to assert whether a 2437 property is required, is optional and the number of times it may 2438 appear in the iCalendar object. A Comment may be provided to further 2439 clarify the presence criteria. 2441 The table below defines the values for the Presence column. 2443 Presence Value Description 2444 -------------------------------------------------------------- 2445 1 One instance MUST be present 2446 1+ At least one instance MUST be present 2447 0 Instances of this property Must NOT be present 2448 0+ Multiple instances MAY be present 2449 0 or 1 Up to 1 instance of this property MAY be present 2450 -------------------------------------------------------------- 2452 While the tables list every component and property, their purpose is 2453 not to define the meaning of the component or property. 2455 There will be a REQUEST-STATUS for each VCALENDAR and component 2456 created, modified, deleted, or requested. The number of REQUEST- 2457 STATUS values returned MUST be equal to the number of TARGETS times 2458 the number of objects in the command. The responses MUST be ordered 2459 first by TARGET then by the order of the objects as supplied in the 2460 command. 2462 7.2.1.2 CREATE Method 2464 Arguments: none 2466 Data: no specific data for this command 2468 Result: 2470 2.0 - successfully created the component or calendar 2472 6.0 - Permission denied 2474 6.1 - Container(s) not found 2475 6.2 - Calendar or component already exists 2477 6.3 - Bad args 2479 The CREATE method is used to create a new iCalendar object of type 2480 objtype. The property TARGET specifies the container(s) for the 2481 create. The type of object wrapped inside of the VCALENDAR/CREATE 2482 object is the object type(s) being created. When creating a new 2483 calendar at the top level, the CSID is specified. Otherwise the 2484 container will be a CalID. 2486 Restriction table 2488 Component/Property Presence Comment 2489 ------------------- -------- ----------------------------- 2490 VCAP 1+ The CUA can send up 2491 PIPELINE commands 2492 without processing a 2493 response 2495 . VERSION 1 MUST be 2.0 2496 . [IANA-PROP] 0+ any IANA registered 2497 property 2499 . VCOMMAND 1 MUST at least one container 2500 (VCALENDAR, VCAR, VQUERY, 2501 VEVENT, VTODO, VJOURNAL) 2502 . . CMDID 0 or 1 If CMDID is not supplied, 2503 then there must not be 2504 pending replies to previous 2505 command. 2507 . . [IANA-PROP] 0+ any IANA registered 2508 property 2509 . . METHOD 1 MUST be CREATE. 2510 . . TARGET 1+ MUST be the CSID or CALID 2512 . . VCALENDAR 0+ 2513 . . . CALMASTER 0 or 1 2514 . . . NAME 0 or 1 2515 . . . OWNER 1+ 2516 . . . RELCALID 1 2517 . . . TZID 0 or 1 2518 . . . [IANA-PROP] 0+ any IANA registered 2519 property 2521 . . VCAR 0+ 2522 . . . CARID 0 or 1 2523 . . . DENY 0+ Note, there must be at 2524 least one GRANT or DENY 2525 within the VCAR. 2526 . . . GRANT 0+ Note, there must be at 2527 least one GRANT or DENY 2528 within the VCAR. 2529 . . . [IANA-PROP] 0+ any IANA registered 2530 property 2532 . . VQUERY 0+ 2533 . . . EXPAND 0 or 1 2534 . . . MAXRESULTS 0 or 1 2535 . . . MAXSIZE 0 or 1 2536 . . . QUERYNAME 1 2537 . . . QUERY 1 2538 . . . [IANA-PROP] 0+ any IANA registered 2539 property 2541 . . VEVENT 0+ 2542 . . . ATTENDEE 0+ 2543 . . . SEQUENCE 0 or 1 MUST be present if value is 2544 greater than 0, 2545 MAY be present if 0 2546 . . . SUMMARY 1 Can be null 2547 . . . UID 1 2549 . . . ATTACH 0+ 2550 . . . CATEGORIES 0 or 1 2551 . . . CLASS 0 or 1 2552 . . . COMMENT 0 or 1 2553 . . . CONTACT 0+ 2554 . . . CREATED 0 or 1 2555 . . . DESCRIPTION 0 or 1 Can be null 2556 . . . DTEND 0 or 1 if present DURATION MUST 2557 NOT be present 2558 . . . DTSTAMP 1 2559 . . . DTSTART 1 2560 . . . DURATION 0 or 1 if present DTEND MUST NOT 2561 be present 2562 . . . EXDATE 0+ 2563 . . . EXRULE 0+ 2564 . . . GEO 0 or 1 2565 . . . LAST-MODIFIED 0 or 1 2566 . . . LOCATION 0 or 1 2567 . . . METHOD 1 <> 2569 . . . ORGANIZER 1 2570 . . . PRIORITY 0 or 1 2571 . . . RDATE 0+ 2572 . . . RECURRENCE-ID 0 or 1 only if referring to an 2573 instance of a recurring 2574 calendar component. 2575 Otherwise it MUST NOT be 2576 present. 2577 . . . RELATED-TO 0+ 2578 . . . REQUEST-STATUS 0+ 2579 . . . RESOURCES 0 or 1 This property MAY contain a 2580 list of values 2581 . . . RRULE 0+ 2582 . . . STATUS 0 or 1 2583 . . . TRANSP 0 or 1 2584 . . . URL 0 or 1 2585 . . . X-PROPERTY 0+ 2586 . . . [IANA-PROP] 0+ any IANA registered 2587 property 2589 . . . VALARM 0+ 2590 . . . . ACTION 1 2591 . . . . ALARMID 0 or 1 MUST be 1 if multiple 2592 VALARMs are present in 2593 same component. 2594 . . . . ATTACH 0+ 2595 . . . . DESCRIPTION 0 or 1 2596 . . . . DURATION 0 or 1 if present REPEAT MUST be 2597 present 2598 . . . . REPEAT 0 or 1 if present DURATION MUST be 2599 present 2600 . . . . SUMMARY 0 or 1 2601 . . . . TRIGGER 1 2602 . . . . X-PROPERTY 0+ 2603 . . . . [IANA-PROP] 0+ any IANA registered property 2605 . . VTODO 0+ 2606 . . . ATTENDEE 0+ 2607 . . . SEQUENCE 0 or 1 MUST be present if value is 2608 greater than 0, MAY be 2609 present if 0 2610 . . . SUMMARY 1 Can be null. 2611 . . . UID 1 2613 . . . ATTACH 0+ 2614 . . . CATEGORIES 0 or 1 This property may contain a 2615 list of values 2616 . . . CLASS 0 or 1 2617 . . . COMMENT 0 or 1 2618 . . . CONTACT 0+ 2619 . . . CREATED 0 or 1 2620 . . . DESCRIPTION 0 or 1 Can be null 2621 . . . DTSTAMP 1 2622 . . . DTSTART 1 2623 . . . DUE 0 or 1 If present DURATION MUST NOT 2624 be present 2625 . . . DURATION 0 or 1 If present DUE MUST NOT be 2626 present 2627 . . . EXDATE 0+ 2628 . . . EXRULE 0+ 2629 . . . GEO 0 or 1 2630 . . . LAST-MODIFIED 0 or 1 2631 . . . LOCATION 0 or 1 2632 . . . METHOD 1 <> 2634 . . . ORGANIZER 1 2635 . . . PRIORITY 1 2636 . . . PERCENT-COMPLETE 0 or 1 2637 . . . RDATE 0+ 2638 . . . RECURRENCE-ID 0 or 1 MUST only if referring to an 2639 instance of a recurring 2640 calendar component. 2641 Otherwise it MUST NOT be 2642 present. 2643 . . . RELATED-TO 0+ 2644 . . . REQUEST-STATUS 0 2645 . . . RESOURCES 0 or 1 This property may contain a 2646 list of values 2647 . . . RRULE 0+ 2648 . . . STATUS 0 or 1 MAY be one of COMPLETED, 2649 NEEDS-ACTION, 2650 IN-PROCESS, CANCELLED 2651 . . . URL 0 or 1 2653 . . . X-PROPERTY 0+ 2654 . . . [IANA-PROP] 0+ any IANA registered property 2656 . . . VALARM 0+ 2657 . . . . ACTION 1 2658 . . . . ALARMID 0 or 1 MUST be 1 if multiple 2659 VALARMs are present in 2660 same component. 2661 . . . . ATTACH 0+ 2662 . . . . DESCRIPTION 0 or 1 2663 . . . . DURATION 0 or 1 if present REPEAT MUST be 2664 present 2665 . . . . REPEAT 0 or 1 if present DURATION MUST be 2666 present 2667 . . . . SUMMARY 0 or 1 2668 . . . . TRIGGER 1 2669 . . . . X-PROPERTY 0+ 2670 . . . . [IANA-PROP] 0+ any IANA registered property 2672 . . VJOURNAL 0+ 2673 . . . ATTENDEE 0 2674 . . . DESCRIPTION 1 Can be null. 2675 . . . DTSTAMP 1 2676 . . . DTSTART 1 2677 . . . ORGANIZER 1 2678 . . . UID 1 2680 . . . ATTACH 0+ 2681 . . . CATEGORIES 0 or 1 This property MAY contain a list 2682 of values 2683 . . . CLASS 0 or 1 2684 . . . COMMENT 0 or 1 2685 . . . CONTACT 0+ 2686 . . . CREATED 0 or 1 2687 . . . EXDATE 0+ 2688 . . . EXRULE 0+ 2689 . . . LAST-MODIFIED 0 or 1 2690 . . . METHOD 1 <> 2692 . . . RDATE 0+ 2693 . . . RECURRENCE-ID 0 or 1 MUST only if referring to 2694 an instance of a recurring 2695 calendar component. 2696 Otherwise it MUST NOT be 2697 present. 2698 . . . RELATED-TO 0+ 2699 . . . RRULE 0+ 2700 . . . SEQUENCE 0 or 1 MUST be present if 2701 non-zero. MAY be 2702 present if zero. 2703 . . . STATUS 0 or 1 2704 . . . SUMMARY 0 or 1 Can be null 2705 . . . URL 0 or 1 2706 . . . X-PROPERTY 0+ 2707 . . . [IANA-PROP] 0+ any IANA registered 2708 property 2710 . . VFREEBUSY 0 2711 . . VTIMEZONE 0+ MUST be present if any 2712 date/time refers to a 2713 timezone 2714 . . . DAYLIGHT 0+ MUST be one or more of 2715 either STANDARD or 2716 DAYLIGHT 2717 . . . . . COMMENT 0 or 1 2718 . . . . . DTSTART 1 2719 . . . . . RDATE 0+ if present RRULE MUST NOT 2720 be present 2721 . . . . . RRULE 0+ if present RDATE MUST NOT 2722 be present 2723 . . . . . TZNAME 0 or 1 2724 . . . . . TZOFFSET 1 2725 . . . . . TZOFFSETFROM 1 2726 . . . . . TZOFFSETTO 1 2727 . . . . . X-PROPERTY 0+ 2728 . . . . . [IANA-PROP] 0+ any IANA registered 2729 property 2730 . . . LAST-MODIFIED 0 or 1 2731 . . . STANDARD 0+ 2732 . . . . . COMMENT 0 or 1 2733 . . . . . DTSTART 1 2734 . . . . . RDATE 0+ if present RRULE MUST NOT 2735 be present 2736 . . . . . RRULE 0+ if present RDATE MUST NOT 2737 be present 2738 . . . . . TZNAME 0 or 1 2739 . . . . . TZOFFSETFROM 1 2740 . . . . . TZOFFSETTO 1 2741 . . . . . X-PROPERTY 0+ 2742 . . . . . [IANA-PROP] 0+ any IANA registered property 2743 . . . TZID 1 2744 . . . TZURL 0 or 1 2745 . . . X-PROPERTY 0+ 2746 . . . [IANA-PROP] 0+ any IANA registered property 2748 Server Restriction Table for the CREATE command 2750 Component/Property Presence Comment 2751 ------------------- -------- ------------------------------- 2753 VCAP 1+ 2754 . VCALENDAR 1+ 2755 . . TARGET 1 2757 . . VERSION 1 MUST be 2.0 2758 . . CMDID 0 or 1 MUST be returned if the 2759 request contained 2760 a CMDID 2761 . . REQUEST-STATUS 0 if not creating a calendar 2762 1+ if creating a calendar 2764 . . . VCAR 0+ 2765 . . . . REQUEST-STATUS 1+ 2766 . . . . * 0 No other VCAR properties 2767 are present 2768 . 2769 . . . VCOMMAND 0 2771 . . . VEVENT 0+ 2772 . . . . REQUEST-STATUS 1+ 2773 . . . . * 0 No other VEVENT properties 2774 are present 2775 . . . . VALARM 0 if VEVENT was successfully 2776 saved 2777 1+ if there were errors saving 2778 alarms 2779 . . . . . REQUEST-STATUS 1+ 2781 . . . VFREEBUSY 0+ 2782 . . . . REQUEST-STATUS 1+ 2783 . . . . * 0 No other VFREEBUSY 2784 properties are present 2786 . . . VJOURNAL 0+ 2787 . . . . REQUEST-STATUS 1+ 2788 . . . . * 0 No other VJOURNAL 2789 properties are present 2791 . . . VQUERY 0+ 2792 . . . . REQUEST-STATUS 1+ 2793 . . . . * 0 No other VQUERY properties 2794 are present 2796 . . . VTODO 0+ 2797 . . . . REQUEST-STATUS 1+ 2798 . . . . * 0 No other VTODO properties 2799 are present 2801 . . . . VALARM 0 if VTODO was successfully 2802 saved 2803 1+ if there were errors saving 2804 alarms 2805 . . . . . REQUEST-STATUS 1+ 2807 7.2.1.2.1 Creating New Calendars 2809 Example to create two new calendars different containers. In the 2810 following example, the client is in the Authenticated state with CS 2811 cal.example.com. 2813 C: SENDDATA 2814 C: CONTENT-TYPE: text/calendar; method=CREATE; 2815 C: component=VCOMMAND 2816 C: Content-Transfer-Encoding:7bit 2817 C: 2818 C: BEGIN:VCAP 2819 C: VERSION:2.1 2820 C: BEGIN:VCOMMAND 2821 C: METHOD:CREATE 2822 C: TARGET:cap://cal.example.com/ 2823 C: TARGET:relcal4 2824 C: BEGIN:VCALENDAR 2825 C: RELCALID:relcalz1 2826 C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Bill's Soccer Team 2827 C: OWNER:bill 2828 C: CALMASTER:mailto:bill@example.com 2829 C: TZID:US_PST 2830 C: BEGIN:VCAR 2831 C: CARID:12345 2832 C: GRANT:UPN=bill;ACTION=*;OBJECT=* 2833 C: END:VCAR 2834 C: END:VCALENDAR 2835 C: BEGIN:VCALENDAR 2836 C: RELCALID:relcalz2 2837 C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Mary's personal 2838 C: calendar 2839 C: OWNER:mary 2840 C: CALMASTER:mailto:mary@example.com 2841 C: TZID:US_PST 2842 C: BEGIN:VCAR 2843 C: CARID:12346 2844 C: GRANT:UPN=mary;ACTION=*;OBJECT=* 2845 C: END:VCAR 2846 C: END:VCALENDAR 2847 C: END:VCOMMAND 2848 C: END:VCAP 2849 C: . 2850 S: 2.0 2851 S: Content-Type:text/calendar; method=RESPONSE; 2852 S: OPTINFO="CMDID:abcde" 2853 # This 2.0 is the transport reply status and ends with a 2854 # CRLF.CRLF (below) 2855 S: BEGIN:VCAP 2856 S: METHOD:RESPONSE 2857 S: TARGET:cap://cal.example.com/ 2858 S: REQUEST-STATUS:2.0 2859 S: END:VCAP 2860 S: BEGIN:VCAP 2861 S: METHOD:RESPONSE 2862 S: REQUEST-STATUS:2.0 2863 S: END:VCAP 2864 S: . 2866 Example to create a new component. 2868 C: SENDDATA 2869 C: Content-Type:text/calendar; method=CREATE; 2870 C: charset=US-ASCII 2871 C: Content-Transfer-Encoding:7bit 2872 C: 2873 C: BEGIN:VCAP 2874 C: VERSION:2.1 2875 C: CMDID:abcde 2876 C: BEGIN:VCOMMAND 2877 C: METHOD:CREATE 2878 C: TARGET:cap://cal.example.com/relcal1 2879 C: TARGET:relcal2 2880 C: BEGIN:VEVENT 2882 C: DTSTART:99990307T180000Z 2883 C: UID:abcd12345 2884 C: DTEND:99990307T190000Z 2885 C: SUMMARY:Important Meeting 2886 C: END:VEVENT 2887 C: END:VCOMMAND 2888 C: END:VCAP 2889 C: . 2890 S: 2.0 2891 S: Content-Type:text/calendar; method=RESPONSE; 2892 S: OPTINFO="CMDID:abcde" 2893 S: 2894 S: BEGIN:VCAP 2895 S: VERSION:2.1 2896 S: CMDID:abcde 2897 S: METHOD:RESPONSE 2898 S: BEGIN:VEVENT 2899 S: TARGET::cap://cal.example.com/relcal1 2900 S: REQUEST-STATUS:2.9 2901 S: END:VEVENT 2902 S: BEGIN:VEVENT 2903 S: REQUEST-STATUS:2.9 2904 S: REQUEST-STATUS:2.10 2905 S: END:VEVENT 2906 S: END:VCAP 2907 S: . 2909 The response contains the calendar (CALID) and UID of the component 2910 so that the CUA can match up the TARGET from multiple objects created 2911 on multiple calendards (TARGETs). 2913 7.2.1.2.2 Creating a new VQUERY 2915 This example creates a stored VQUERY that selects all unprocessed 2916 scheduling entries. QUERYNAME must not exist in the TARGET 2917 calendar. 2919 C: SENDDATA 2920 C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII 2921 C: Content-Transfer-Encoding:7bit 2922 C: 2923 C: BEGIN:VCAP 2924 C: VERSION:2.1 2925 C: CMDID:abcde-2 2926 C: METHOD:CREATE 2927 C: TARGET:cap://cal.example.com/relcal1 2928 C: BEGIN:VQUERY 2929 C: BEGIN:VQUERY 2930 C: QUERYNAME:GetAlliTIPinQueue 2931 C: QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE' 2932 C: END:VQUERY 2933 C: END:VEVENT 2934 C: END:VCAP 2935 C: . 2936 S: 2.0 2937 S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde" 2938 S: 2939 S: BEGIN:VCAP 2940 S: CMDID:abcde-2 2941 S: METHOD:RESPONSE 2942 S: TARGET::cap://cal.example.com/relcal1 2943 S: BEGIN:VQUERY 2944 S: REQUEST-STATUS:2.0; 2945 S: END:VQUERY 2946 S: END:VCAP 2947 S: . 2949 [EDITORS NOTE - can return QUERYNAME already exists error] 2951 7.2.1.3 DELETE Method 2953 Arguments: none 2955 Data: no specific data for this command 2957 Result: 2959 2.0 - successfully deleted the component or calendar 2961 Permission 2963 Calendar or component not found 2965 Bad args 2967 Container(s) not found 2969 The DELETE method is used to delete a calendar or component. The 2970 TARGET properties specify the container(s) for the delete. When 2971 deleting a calendar at the top level, the CSID is specified. 2972 Otherwise the container will be a CalID. 2974 Restriction Table 2976 Component/Property Presence Comment 2977 ------------------- -------- --------------------------- 2978 VCAP 1+ The CUA can send up 2979 PIPELINE commands 2980 without processing a 2981 response 2983 VERSION 1 MUST be 2.0 2985 VCOMMAND 1 2986 CMDID 0 or 1 If CMDID is not supplied, 2987 then there must 2988 not be pending replies to 2989 previous command. 2990 METHOD 1 MUST be DELETE. 2991 TARGET 1+ MUST be a the CSID or CALID 2993 VQUERY 0+ 2994 EXPAND 0 ? 2995 MAXRESULTS 0 or 1 Limit the solution set to 2996 no more than this many 2997 entries. 2999 MAXSIZE 0 ? 3000 QUERYNAME 1 Name by which this query is 3001 referenced 3002 QUERY 1 The query 3004 Server Restriction Table for the DELETE command 3006 Component/Property Presence Comment 3007 ------------------- -------- ----------------------------- 3009 VCAP 1+ 3010 TARGET 1 3012 VERSION 1 MUST be 2.0 3014 CMDID 0 or 1 MUST be returned if the 3015 request contained a CMDID 3017 VCALENDAR Only if VCALENDARs were 3018 deleted 3019 REQUEST-STATUS 1 3020 * 1+ No other VALARM properties 3021 are present 3023 VALARM 0+ Only if VALARM components 3024 were deleted 3025 REQUEST-STATUS 1 3026 * 0 No other VALARM properties 3027 are present 3029 VCAR 0+ Only if VCAR components were 3030 deleted 3031 REQUEST-STATUS 1 3032 * 0 No other VCAR properties are 3033 present 3035 VEVENT 0+ Only if VEVENT components 3036 were deleted 3037 REQUEST-STATUS 1+ 3039 * 0 No other VEVENT properties 3040 are present 3042 VFREEBUSY 0 3043 REQUEST-STATUS 1+ 3044 * 0 No other VFREEBUSY properties 3045 are present 3047 VJOURNAL 0+ Only if VJOURNAL components 3048 were deleted 3049 REQUEST-STATUS 1+ 3050 * 0 No other VJOURNAL properties 3051 are present 3053 VQUERY 0+ Only if VQUERY components 3054 were deleted 3055 REQUEST-STATUS 1+ 3056 * 0 No other VQUERY properties 3057 are present 3059 VTIMEZONE 0+ Only if VTIMEZONE components 3060 were deleted 3061 REQUEST-STATUS 1+ 3062 * 0 No other VQUERY properties 3063 are present 3065 VTODO 0+ Only if VTODO components were 3066 deleted 3067 REQUEST-STATUS 1+ 3068 * 0 No other VTODO properties are 3069 present 3071 ---------------------------------------------------------- 3073 [EDITORS NOTE: Issues: 3075 - Currently CAP requires that the server return a response status. 3076 However, if there are multiple components deleted, should the UID 3077 also be returned? 3079 - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to 3080 deletion? 3082 - Can one use DELETE to remove all VALARMs and VTIMEZONEs that 3083 match a certain search criteria and that belong to all components, 3084 event though VALARMs and VTIMEZONEs never exist as independent 3085 components? Or should one use MODIFY? If they can be deleted, do 3086 we return the REQUEST-STATUS of their deletion in a VEVENT or 3087 separately? 3089 - In the example in CAP where a calendar is deleted all the server 3090 returns is 2.0, nothing else? 3092 - We should not be able to delete any VFREEBUSY components? 3093 - Can we delete multiple calendars? 3095 - Currently one can not delete a VCALENDAR and some other 3096 component in the same DELETE command. This seems OK. Anyone see 3097 any need to be able to do this? 3099 - Should the MAXRESULTS property of VQUERY apply to deletion? We 3100 can use it to delete only the first n components that match. ] 3102 Example to delete a VEVENT with UID 'abcd12345': 3104 C: SENDDATA 3105 C: Content-Type:text/calendar; method=DELETE; 3106 component=VCOMMAND 3107 C: Content-Transfer-Encoding:7bit 3108 C: 3110 C: BEGIN:VCAP 3111 C: BEGIN:VCOMMAND 3112 C: METHOD:DELETE 3113 C: TARGET:cap://cal.foo.com/bill 3114 C: BEGIN:VQUERY 3115 C: QUERY:SELECT UID FROM VEVENT WHERE UID = 'abcd12345' 3116 C: END:VQUERY 3117 C: END:VCOMMAND 3118 C: END:VCAP 3119 C: . 3120 S: 2.0 3121 S: Content-Type:text/calendar; method=DELETE; 3122 S: component=VCOMMAND 3123 S: 3124 S: BEGIN:VCAP 3125 S: METHOD:RESPONSE 3126 S: BEGIN:VEVENT 3127 S: REQUEST-STATUS:2.0 3128 S: END:VEVENT 3129 S: END:VCAP 3130 S: . 3131 C: SENDDATA 3132 C: Content-Type:text/calendar; method=DELETE; 3133 C: component=VCOMMAND 3134 C: Content-Transfer-Encoding:7bit 3135 C: 3136 C: BEGIN:VCAP 3137 C: BEGIN:VCOMMAND 3138 C: METHOD:DELETE 3139 C: TARGET:cap://cal.foo.com/MrBill 3140 C: END:VCOMMAND 3141 C: END:VCAP 3142 C: . 3143 S: 2.0 3144 S: . 3146 7.2.1.4 GENERATEUID Method 3148 Arguments: Number of UIDs to generate. 3150 Data: new uids 3152 Result: 2.0 3154 GENERATEUID returns one or more new unique identifier which MUST be 3155 unique on the server's calendar store. It is recommended that the 3156 return value be a globally unique id. 3158 Example: 3160 C: GENERATEUID 2 3161 S: 2.0 3162 S: abcde1234567-asdf-lkhh 3163 S: abcde1234567-asdf-3455 3164 S: . 3166 [EDITORS NOTE: this example needs work. It's not packaged right] 3168 7.2.1.5 MODIFY Method 3170 Arguments: none 3172 Data: no specific data for this command 3174 Result: 3176 2.0 - successfully modified the component or calendar 3178 Permission 3180 Calendar or component not found 3182 Bad args 3184 Container(s) not found 3186 The MODIFY method is used to change an existing calendar or 3187 component. TARGET specify the container(s) of the modification. 3189 When modifying a calendar at the top level, the CSID is specified. 3190 Otherwise the container will be a CalID. 3192 The format of the request is two or three containers inside of a 3193 VCOMMAND container: 3195 BEGIN:VCOMMAND 3196 [VQUERY] 3197 OLD-VALUES 3198 NEW-VALUES 3199 END:VCOMMAND 3201 If a VQUERY is present, then only objects matching the query results 3202 are modified. 3204 Restriction Table 3206 Component/Property Presence Comment 3207 ------------------- -------- --------------------------- 3208 VCAP 1+ The CUA can send up 3209 PIPELINE commands 3210 without processing a 3211 response 3213 . VERSION 1 MUST be 2.0 3214 . [IANA-PROP] 0+ any IANA registered 3215 property 3217 . VCOMMAND 1 MUST have at least one 3218 container (VCALENDAR, 3219 VCAR, VQUERY, VEVENT, 3220 VTODO, VJOURNAL) 3221 . . CMDID 0 or 1 If CMDID is not supplied, 3222 then there must 3223 not be pending replies to 3224 previous command. 3225 . . [IANA-PROP] 0+ any IANA registered 3226 property 3227 . . METHOD 1 MUST be MODIFY 3228 . . TARGET 1+ MUST be the CALID 3230 . . VCALENDAR 0+ 3231 . . . CALMASTER 0 or 1 3232 . . . NAME 0 or 1 3233 . . . OWNER 1+ 3234 . . . RELCALID 1 3235 . . . TZID 0 or 1 3236 . . . [IANA-PROP] 0+ any IANA registered 3237 property 3239 . . VCAR 0+ 3240 . . . CARID 0 or 1 3241 . . . DENY 0+ Note, there must be at 3242 least one GRANT or DENY 3243 within the VCAR. 3244 . . . GRANT 0+ Note, there must be at 3245 least one GRANT or DENY 3246 within the VCAR. 3247 . . . [IANA-PROP] 0+ any IANA registered 3248 property 3250 . . VQUERY 0+ 3251 . . . EXPAND 0 or 1 3252 . . . MAXRESULTS 0 or 1 3253 . . . MAXSIZE 0 or 1 3254 . . . QUERYNAME 1 3255 . . . QUERY 1 3256 . . . [IANA-PROP] 0+ any IANA registered 3257 property 3259 . . VEVENT 0+ 3260 . . . ATTENDEE 0+ 3261 . . . SEQUENCE 0 or 1 MUST be present if value is 3262 greater than 0, 3263 MAY be present if 0 3264 . . . SUMMARY 1 Can be null 3265 . . . UID 1 3267 . . . ATTACH 0+ 3268 . . . CATEGORIES 0 or 1 3269 . . . CLASS 0 or 1 3270 . . . COMMENT 0 or 1 3271 . . . CONTACT 0+ 3272 . . . CREATED 0 or 1 3273 . . . DESCRIPTION 0 or 1 Can be null 3274 . . . DTEND 0 or 1 if present DURATION MUST 3275 NOT be present 3276 . . . DTSTAMP 1 3277 . . . DTSTART 1 3278 . . . DURATION 0 or 1 if present DTEND MUST NOT 3279 be present 3280 . . . EXDATE 0+ 3281 . . . EXRULE 0+ 3282 . . . GEO 0 or 1 3283 . . . LAST-MODIFIED 0 or 1 3284 . . . LOCATION 0 or 1 3285 . . . METHOD 1 <> 3287 . . . ORGANIZER 1 3288 . . . PRIORITY 0 or 1 3289 . . . RDATE 0+ 3290 . . . RECURRENCE-ID 0 or 1 only if referring to an 3291 instance of a recurring 3292 calendar component. 3293 Otherwise it MUST NOT be 3294 present. 3295 . . . RELATED-TO 0+ 3296 . . . REQUEST-STATUS 0+ 3297 . . . RESOURCES 0 or 1 This property MAY contain a 3298 list of values 3299 . . . RRULE 0+ 3300 . . . STATUS 0 or 1 3301 . . . TRANSP 0 or 1 3302 . . . URL 0 or 1 3303 . . . X-PROPERTY 0+ 3304 . . . [IANA-PROP] 0+ any IANA registered 3305 property 3307 . . . VALARM 0+ 3308 . . . . ACTION 1 3309 . . . . ALARMID 0 or 1 MUST be 1 if multiple 3310 VALARMs are present in same 3311 component. 3312 . . . . ATTACH 0+ 3313 . . . . DESCRIPTION 0 or 1 3314 . . . . DURATION 0 or 1 if present REPEAT MUST be 3315 present 3316 . . . . REPEAT 0 or 1 if present DURATION MUST be 3317 present 3318 . . . . SUMMARY 0 or 1 3319 . . . . TRIGGER 1 3320 . . . . X-PROPERTY 0+ 3321 . . . . [IANA-PROP] 0+ any IANA registered 3322 property 3324 . . VTODO 0+ 3325 . . . ATTENDEE 0+ 3326 . . . SEQUENCE 0 or 1 MUST be present if value is 3327 greater than 0, MAY be 3328 present if 0 3329 . . . SUMMARY 1 Can be null. 3330 . . . UID 1 3331 . . . ATTACH 0+ 3332 . . . CATEGORIES 0 or 1 This property may contain a 3333 list of values 3334 . . . CLASS 0 or 1 3335 . . . COMMENT 0 or 1 3336 . . . CONTACT 0+ 3337 . . . CREATED 0 or 1 3338 . . . DESCRIPTION 0 or 1 Can be null 3339 . . . DTSTAMP 1 3340 . . . DTSTART 1 3341 . . . DUE 0 or 1 If present DURATION MUST 3342 NOT be present 3343 . . . DURATION 0 or 1 If present DUE MUST NOT be 3344 present 3345 . . . EXDATE 0+ 3346 . . . EXRULE 0+ 3347 . . . GEO 0 or 1 3348 . . . LAST-MODIFIED 0 or 1 3349 . . . LOCATION 0 or 1 3350 . . . METHOD 1 <> 3352 . . . ORGANIZER 1 3353 . . . PRIORITY 1 3354 . . . PERCENT-COMPLETE 0 or 1 3355 . . . RDATE 0+ 3356 . . . RECURRENCE-ID 0 or 1 MUST only if referring to 3357 an instance of a recurring 3358 calendar component. 3359 Otherwise it MUST NOT 3360 be present. 3361 . . . RELATED-TO 0+ 3362 . . . REQUEST-STATUS 0 3363 . . . RESOURCES 0 or 1 This property may contain a 3364 list of values 3365 . . . RRULE 0+ 3366 . . . STATUS 0 or 1 MAY be one of COMPLETED, 3367 NEEDS-ACTION, 3368 IN-PROCESS, CANCELLED 3369 . . . URL 0 or 1 3371 . . . X-PROPERTY 0+ 3372 . . . [IANA-PROP] 0+ any IANA registered 3373 property 3375 . . . VALARM 0+ 3376 . . . . ACTION 1 3377 . . . . ALARMID 0 or 1 MUST be 1 if multiple 3378 VALARMs are present in 3379 same component. 3380 . . . . ATTACH 0+ 3381 . . . . DESCRIPTION 0 or 1 3382 . . . . DURATION 0 or 1 if present REPEAT MUST be 3383 present 3384 . . . . REPEAT 0 or 1 if present DURATION MUST be 3385 present 3386 . . . . SUMMARY 0 or 1 3387 . . . . TRIGGER 1 3388 . . . . X-PROPERTY 0+ 3389 . . . . [IANA-PROP] 0+ any IANA registered 3390 property 3392 . . VJOURNAL 0+ 3393 . . . ATTENDEE 0 3394 . . . DESCRIPTION 1 Can be null. 3395 . . . DTSTAMP 1 3396 . . . DTSTART 1 3397 . . . ORGANIZER 1 3398 . . . UID 1 3400 . . . ATTACH 0+ 3401 . . . CATEGORIES 0 or 1 This property MAY contain a 3402 list of values 3403 . . . CLASS 0 or 1 3404 . . . COMMENT 0 or 1 3405 . . . CONTACT 0+ 3406 . . . CREATED 0 or 1 3407 . . . EXDATE 0+ 3408 . . . EXRULE 0+ 3409 . . . LAST-MODIFIED 0 or 1 3410 . . . METHOD 1 <> 3412 . . . RDATE 0+ 3413 . . . RECURRENCE-ID 0 or 1 MUST only if referring to 3415 an instance of a recurring 3416 calendar component. 3417 Otherwise it MUST NOT be 3418 present. 3419 . . . RELATED-TO 0+ 3420 . . . RRULE 0+ 3421 . . . SEQUENCE 0 or 1 MUST be present if non- 3422 zero. MAY be 3423 . . . . . present if zero. 3425 . . . STATUS 0 or 1 3426 . . . SUMMARY 0 or 1 Can be null 3427 . . . URL 0 or 1 3428 . . . X-PROPERTY 0+ 3429 . . . [IANA-PROP] 0+ any IANA registered 3430 property 3432 . . VFREEBUSY 0 3434 . . VTIMEZONE 0+ MUST be present if any 3435 date/time refers 3436 to a timezone 3437 . . . DAYLIGHT 0+ MUST be one or more of 3438 either STANDARD 3439 or DAYLIGHT 3440 . . . . . COMMENT 0 or 1 3441 . . . . . DTSTART 1 3442 . . . . . RDATE 0+ if present RRULE MUST NOT 3443 be present 3444 . . . . . RRULE 0+ if present RDATE MUST NOT 3445 be present 3446 . . . . . TZNAME 0 or 1 3447 . . . . . TZOFFSET 1 3448 . . . . . TZOFFSETFROM 1 3449 . . . . . TZOFFSETTO 1 3450 . . . . . X-PROPERTY 0+ 3451 . . . . . [IANA-PROP] 0+ any IANA registered 3452 property 3453 . . . LAST-MODIFIED 0 or 1 3454 . . . STANDARD 0+ 3455 . . . . . COMMENT 0 or 1 3456 . . . . . DTSTART 1 3457 . . . . . RDATE 0+ if present RRULE MUST NOT 3458 be present 3459 . . . . . RRULE 0+ if present RDATE MUST NOT 3460 be present 3461 . . . . . TZNAME 0 or 1 3462 . . . . . TZOFFSETFROM 1 3463 . . . . . TZOFFSETTO 1 3464 . . . . . X-PROPERTY 0+ 3465 . . . . . [IANA-PROP] 0+ any IANA registered 3466 property 3467 . . . TZID 1 3468 . . . TZURL 0 or 1 3469 . . . X-PROPERTY 0+ 3470 . . . [IANA-PROP] 0+ any IANA registered 3471 property 3473 Server Restriction Table for the MODIFY command 3475 Component/Property Presence Comment 3476 --------------------- -------- -------------------------- 3478 VCAP 1+ 3479 . VCALENDAR 1+ 3480 . . TARGET 1 3482 . . VERSION 1 MUST be 2.0 3484 . . CMDID 0 or 1 MUST be returned if the 3485 request contained a CMDID 3486 . . REQUEST-STATUS 0 if not creating a calendar 3487 1+ if creating a calendar 3489 . . . VCAR 0+ 3490 . . . . REQUEST-STATUS 1+ 3491 . . . . * 0 No other VCAR properties are 3492 present 3493 . 3494 . . . VCOMMAND 0 3496 . . . VEVENT 0+ 3497 . . . . REQUEST-STATUS 1+ 3498 . . . . * 0 No other VEVENT properties 3499 are present 3500 . . . . VALARM 0 if VEVENT was successfully 3501 saved 3502 1+ if there were errors saving 3503 alarms 3504 . . . . . REQUEST-STATUS 1+ 3506 . . . VFREEBUSY 0+ 3507 . . . . REQUEST-STATUS 1+ 3508 . . . . * 0 No other VFREEBUSY 3509 properties are 3510 present 3512 . . . VJOURNAL 0+ 3513 . . . . REQUEST-STATUS 1+ 3514 . . . . * 0 No other VJOURNAL properties 3515 are present 3517 . . . VQUERY 0+ 3518 . . . . REQUEST-STATUS 1+ 3519 . . . . * 0 No other VQUERY properties 3520 are present 3522 . . . VTODO 0+ 3523 . . . . REQUEST-STATUS 1+ 3524 . . . . * 0 No other VTODO properties 3525 are present 3526 . . . . VALARM 0 if VTODO was successfully 3527 saved 3528 1+ if there were errors saving 3529 alarms 3530 . . . . . REQUEST-STATUS 1+ 3532 [EDITORS NOTES: Issues: freebusy - a cap server should dynamically 3533 calculate freebusy information we recommend that you cannot create, 3534 modify, or delete freebusy composers ] 3536 In the example below, the start and end time of the event with UID 3537 abcd12345 is changed and the LOCATION property is removed. 3539 C: SENDDATA 3540 C: Content-type:text/calendar; Method=MODIFY; 3541 C: Component=VCOMMAND 3542 C: 3543 C: BEGIN:VCAP 3544 C: VERSION:2.1 3545 C: BEGIN:VCOMMAND 3546 C: METHOD:MODIFY 3547 C: TARGET:relcal2 3548 C: BEGIN:VCOMMAND 3549 C: BEGIN:VQUERY 3550 C: QUERY:SELECT UID FROM VEVENT WHERE UID = 'abcd12345' 3551 C: END:VQUERY 3552 C: BEGIN:VEVENT 3553 C: DTSTART:19990421T160000Z 3554 C: DTEND:19990421T163000Z 3555 C: LOCATION:Joe's Diner 3556 C: END:VCOMMAND 3557 C: END:VEVENT 3559 C: BEGIN:VEVENT 3560 C: DTSTART:19990421T160000Z 3561 C: DTEND:19990421T163000Z 3562 C: END:VEVENT 3563 C: END:VCOMMAND 3564 C: END:VCAP 3565 C: . 3567 S: 2.0 cap://cal.example.com/relcal2 3569 And in this example, all instances of "Building 6" are replaced by 3570 "New office lobby" in VEVENTs: 3572 C: SENDDATA 3573 C: Content-type:text/calendar; Method=MODIFY; 3574 C: Component=VCOMMAND 3575 C: 3576 C: BEGIN:VCAP 3577 C: VERSION:2.1 3578 C: BEGIN:VCOMMAND 3579 C: METHOD:MODIFY 3580 C: TARGET:relcal2 3581 C: BEGIN:VCOMMAND 3582 C: BEGIN:VEVENT 3583 C: LOCATION:Building 6 3584 C: END:VEVENT 3585 C: BEGIN:VEVENT 3586 C: LOCATION:New office lobby 3587 C: END:VEVENT 3588 C: END:VCOMMAND 3589 C: END:VCOMMAND 3590 C: END:VCAP 3591 C: . 3592 S: 2.0 cap://cal.example.com/relcal2 3594 7.2.1.6 MOVE Method 3596 Arguments: ContainerId 3598 Data: data as described below 3600 Result: 3602 2.0 - success 3604 2.2 - will attempt operation on the remote CAP server 3606 Permission 3608 Calendar already exists 3610 Bad args 3612 Parent Calendar(s) not found 3614 The format of the command is: 3616 BEGIN:VCALENDAR 3617 METHOD:MOVE 3618 ... 3619 TARGET:target-name 3620 BEGIN:VCOMMAND 3621 BEGIN:VCALENDAR 3622 PARENT: 3623 END:VCALENDAR 3624 BEGIN:VCALENDAR 3625 PARENT: 3626 END:VCALENDAR 3627 END:VCOMMAND 3628 END:VCALENDAR 3630 This looks similar to a MODIFY command. Except the CS MUST ensure 3631 that VCARs are still valid after the move. And the CS MUST update 3632 the CHILDREN list in the new and old parent containers. 3634 This method is used to move a calendar within the CS's hierarchy of 3635 calendars. 3637 Restriction Table 3639 Component/Property Presence Comment 3640 ------------------- -------- --------------------- 3641 VCAP 1+ The CUA can send up 3642 PIPELINE commands without 3643 processing a response 3645 . VERSION 1 MUST be 2.0 3647 . VCOMMAND 1 MUST have at least one 3648 VCALENDAR 3650 . . CMDID 0 or 1 If CMDID is not supplied, 3651 then there must not be 3652 pending replies to 3653 previous command. 3655 . . [IANA-PROP] 0+ any IANA registered 3656 property 3658 . . METHOD 1 MUST be MOVE. 3659 . . TARGET 1 MUST be a the CSID or 3660 CALID 3662 . . VCALENDAR 1+ 3663 . . . CALMASTER 0 3664 . . . NAME 0 3665 . . . OWNER 0 3666 . . . RELCALID 1 3667 . . . TZID 0 3668 . . . [IANA-PROP] 0+ any IANA registered 3669 property 3671 Server Restriction Table for the MOVE command 3673 Component/Property Presence Comment 3674 ------------------- -------- ----------------------------- 3676 VCAP 1+ 3678 . VCALENDAR 1+ 3680 . . TARGET 1 3681 . . VERSION 1 MUST be 2.0 3683 . . CMDID 0 or 1 MUST be returned if the 3684 request contained 3685 a CMDID 3686 . . REQUEST-STATUS 1+ 3688 --------------------------------------------------------- 3690 [EDITORS NOTE: Issues: 3692 1) Should one be able to move a calendar owned by person X into a 3693 calendar owned by person Y. (Can these such rights be specified 3694 in VCARs?) 3696 2) Should we also be able to move components from one calendar to 3697 another? What if the calendars are owned by different users? (With 3698 components one can do a copy, then delete the original.) 3700 3) There was very little information about MOVE in CAP. Why was 3701 it added? Was there some major need for it? 3703 4) Can one move multiple calendars into one calendar?] 3705 An example of moving a calendar from Nellis to Area-51 3707 C: SENDDATA 3708 C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND 3709 C: 3710 C: BEGIN:VCAP 3711 C: VERSION:2.1 3712 C: METHOD:MOVE 3713 C: TARGET:Nellis 3714 C: BEGIN:VCOMMAND 3715 C: BEGIN:VCALENDAR 3716 C: PARENT:Department-33 3717 C: END:VCALENDAR 3718 C: BEGIN:CALENDAR 3719 C: PARENT:Area-51 3720 C: END:VCALENDAR 3721 C: END:VCOMMAND 3722 C: END:VCAP 3723 C: . 3724 S: 2.0 3725 S: Content-Type:text/calendar; method=RESPONSE 3726 S: 3727 S: BEGIN:VCAP 3728 S: METHOD:RESPONSE 3729 S: TARGET:relcal2 3730 S: BEGIN:VCALENDAR 3731 S: REQUEST-STATUS:2.0; 3732 S: END:VCALENDAR 3733 S: END:VCAP 3734 S: . 3736 7.2.1.7 READ Method 3738 Arguments: ContainerId 3740 Data: data as described below 3742 Result: 3744 2.0 - - successful and the requested data follows 3746 2.2 - will attempt read on the remote CAP server 3748 Permission 3750 Bad args 3752 Restriction Table 3754 Component/Property Presence Comment 3755 ------------------- -------- --------------------------- 3756 VCAP 1+ The CUA can send 3757 PIPELINE commands 3758 without processing a 3759 response 3761 . VERSION 1 MUST be 2.0 3762 . [IANA-PROP] 0+ any IANA registered 3763 property 3765 . VCOMMAND 1 MUST have at least one 3766 container (VCALENDAR, 3767 VCAR, VQUERY, VEVENT, 3768 VTODO, VJOURNAL) 3769 . . CMDID 0 or 1 If CMDID is not supplied, 3770 then there must not be pending 3771 replies to previous command. 3772 . . [IANA-PROP] 0+ any IANA registered 3773 property 3774 . . METHOD 1 MUST be READ 3775 . . TARGET 1+ MUST be the CALID 3777 . . VCALENDAR 0+ 3778 . . . CALMASTER 0 or 1 3779 . . . NAME 0 or 1 3780 . . . OWNER 1+ 3781 . . . RELCALID 1 3782 . . . TZID 0 or 1 3783 . . . [IANA-PROP] 0+ any IANA registered 3784 property 3786 . . VCAR 0 3788 . . VQUERY 1 3789 . . . EXPAND 0 or 1 3790 . . . MAXRESULTS 0 or 1 3791 . . . MAXSIZE 0 or 1 3792 . . . QUERYNAME 1 3793 . . . QUERY 1 3794 . . . [IANA-PROP] 0+ any IANA registered 3795 property 3797 . . VEVENT 0 3798 . . VTODO 0 3799 . . VJOURNAL 0 3800 . . VFREEBUSY 0 3802 . . VTIMEZONE 0+ MUST be present if any 3803 date/time refers 3804 to a timezone 3805 . . . DAYLIGHT 0+ MUST be one or more of 3806 either STANDARD 3807 or DAYLIGHT 3808 . . . . . COMMENT 0 or 1 3809 . . . . . DTSTART 1 3810 . . . . . RDATE 0+ if present RRULE MUST NOT 3811 be present 3812 . . . . . RRULE 0+ if present RDATE MUST NOT 3814 be present 3815 . . . . . TZNAME 0 or 1 3816 . . . . . TZOFFSET 1 3817 . . . . . TZOFFSETFROM 1 3818 . . . . . TZOFFSETTO 1 3819 . . . . . X-PROPERTY 0+ 3820 . . . . . [IANA-PROP] 0+ any IANA registered 3821 property 3822 . . . LAST-MODIFIED 0 or 1 3823 . . . STANDARD 0+ 3824 . . . . . COMMENT 0 or 1 3825 . . . . . DTSTART 1 3826 . . . . . RDATE 0+ if present RRULE MUST NOT 3827 be present 3828 . . . . . RRULE 0+ if present RDATE MUST NOT 3829 be present 3830 . . . . . TZNAME 0 or 1 3831 . . . . . TZOFFSETFROM 1 3832 . . . . . TZOFFSETTO 1 3833 . . . . . X-PROPERTY 0+ 3834 . . . . . [IANA-PROP] 0+ any IANA registered 3835 property 3836 . . . TZID 1 3837 . . . TZURL 0 or 1 3838 . . . X-PROPERTY 0+ 3839 . . . [IANA-PROP] 0+ any IANA registered 3840 property 3842 Server Restriction Table for the READ command 3844 Component/Property Presence Comment 3845 --------------------- -------- -------------------------- 3847 VCAP 1+ 3848 . VCALENDAR 1+ 3849 . . TARGET 1 3850 . . VERSION 1 MUST be 2.0 3852 . . CMDID 0 or 1 MUST be returned if the 3853 request contained a CMDID 3854 . . REQUEST-STATUS 0 if not creating a calendar 3855 1+ if creating a calendar 3857 . . . VCAR 0+ 3858 . . . . REQUEST-STATUS 1+ 3859 . . . . * 0 No other VCAR properties are 3861 present 3862 . 3863 . . . VCOMMAND 0 3865 . . . VEVENT 0+ 3866 . . . . REQUEST-STATUS 1+ 3867 . . . . * 0 No other VEVENT properties 3868 are present 3869 . . . . VALARM 0 if VEVENT was successfully 3870 saved 3871 1+ if there were errors saving 3872 alarms 3873 . . . . . REQUEST-STATUS 1+ 3875 . . . VFREEBUSY 0+ 3876 . . . . REQUEST-STATUS 1+ 3877 . . . . * 0 No other VFREEBUSY 3878 properties are 3879 present 3881 . . . VJOURNAL 0+ 3882 . . . . REQUEST-STATUS 1+ 3883 . . . . * 0 No other VJOURNAL properties 3884 are present 3886 . . . VQUERY 0+ 3887 . . . . REQUEST-STATUS 1+ 3888 . . . . * 0 No other VQUERY properties 3889 are present 3891 . . . VTODO 0+ 3892 . . . . REQUEST-STATUS 1+ 3893 . . . . * 0 No other VTODO properties 3894 are present 3895 . . . . VALARM 0 if VTODO was successfully 3896 saved 3898 1+ if there were errors saving 3899 alarms 3900 . . . . . REQUEST-STATUS 1+ 3902 Read Events 3904 In the example below events on March 10,1999 between 080000Z and 3905 190000Z are read. In this case only 4 properties for each event are 3906 returned. Two calendars are specified. Only booked (vs scheduled) 3907 entries are to be returned. The first returns two VEVENTS that match 3908 in that TARGET, the second result returns only one VEVENT for the 3909 second TARGET. 3911 C: SENDDATA 3912 C: Content-type:text/calendar; Method=READ; Component=VQUERY 3913 C: 3914 C: BEGIN:VCAP 3915 C: VERSION:2.1 3916 C: BEGIN:VCOMMAND 3917 C: METHOD:READ 3918 C: CMDID:xyz12345 3919 C: TARGET:relcal2 3920 C: TARGET:cap://bobo.ex.com/relcal3 3921 C: BEGIN:VQUERY 3922 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID 3923 FROM VEVENT 3924 WHERE DTEND >= '19990310T080000Z' 3925 AND DTSTART <= '19990310T190000Z' 3926 AND METHOD = 'CREATE' 3927 C: END:VQUERY 3928 C: END:VCOMMAND 3929 C: END:VCAP 3930 C: . 3931 S: 2.0 cap://cal.example.com/relcal2 3932 S: Content-type:text/calendar; Method=RESPONSE; 3933 Optinfo=VERSION:2.1 3934 S: Content-Transfer-Encoding: 7bit 3935 S: 3936 S: BEGIN:VCAP 3937 S: VERSION:2.1 3938 S: METHOD:RESPONSE 3939 S: BEGIN:VEVENT 3941 S: DTSTART:19990310T090000Z 3942 S: DTEND:19990310T100000Z 3943 S: UID:abcxyz12345 3944 S: SUMMARY:Meet with Sir Elton 3945 S: END:VEVENT 3946 S: BEGIN:VEVENT 3947 S: DTSTART:19990310T130000Z 3948 S: DTEND:19990310T133000Z 3949 S: UID:abcxyz8999 3950 S: SUMMARY:Meet with brave brave Sir Robin 3951 S: END:VEVENT 3952 S: END:VCAP 3953 S: . 3954 S: 2.0 cap://bobo.ex.com/relcal3 3955 S: Content-type:text/calendar; Method=RESPONSE; 3956 S: Optinfo=VERSION:2.1 3957 S: Content-Transfer-Encoding: 7bit 3958 S: 3959 S: BEGIN:VCAP 3960 S: VERSION:2.1 3961 S: METHOD:RESPONSE 3962 S: BEGIN:VEVENT 3963 S: DTSTART:19990310T140000Z 3964 S: DTEND:19990310T150000Z 3965 S: UID:123456asdf 3966 S: SUMMARY:Summer Budget 3967 S: END:VEVENT 3968 S: END:VCAP 3969 S: . 3971 The return values are subject to VCAR filtering. That is, if the 3972 request contains properties to which the UPN does not have access, 3973 those properties will not appear in the return values. If the UPN 3974 has access to at least one property of events, but has been denied 3975 access to all properties called out in the request, the response will 3976 contain a single REQUEST-STATUS property indicating the error. That 3977 is, the VEVENT components will be the following: 3979 [EDITORS NOTE: Should the one(s) that the UPN has access to - be 3980 returned?] 3982 S: 2.0 cap://bobo.ex.com/sally 3983 S: Content-type:text/calendar; 3984 Method=RESPONSE; 3985 S: Optinfo=VERSION:2.1 3986 S: Content-Transfer-Encoding: 7bit 3987 S: 3988 S: BEGIN:VCAP 3989 S: VERSION:2.1 3990 S: BEGIN:VEVENT 3991 S: REQUEST-STATUS:3.8 3992 S: END:VEVENT 3993 S: END:VCAP 3994 S: . 3996 If the UPN has no access to any events at all, the response will 3997 simply be an empty data set. The response looks the same if there 3998 are particular events to which the requester has been denied access. 4000 S: 2.0 cap://bobo.ex.com/sally 4001 S: Content-type:text/calendar; Method=RESPONSE; 4002 S: Optinfo=VERSION:2.1 4003 S: Content-Transfer-Encoding: 7bit 4004 S: 4005 S: BEGIN:VCAP 4006 S: VERSION:2.1 4007 S: END:VCAP 4008 S: . 4010 Find alarms within a range of time for booked (METHOD = CREATE) 4011 VEVENTs. 4013 C: SENDDATA 4014 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4015 C: 4016 C: BEGIN:VCAP 4017 C: VERSION:2.1 4018 C: BEGIN:VCOMMAND 4019 C: METHOD:READ 4020 C: CMDID:xyz12345 4021 C: TARGET:relcal2 4022 C: TARGET:cap://bobo.ex.com/relcal3 4023 C: BEGIN:VQUERY 4024 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID, VALARM.* 4025 FROM VEVENT,VTODO 4026 WHERE VALARM.TRIGGER >= '19990310T080000Z' 4027 AND VALARM.TRIGGER <= '19990310T190000Z' 4028 AND METHOD = 'CREATE' 4029 C: END:VQUERY 4030 C: END:VCOMMAND 4031 C: END:VCAP 4032 C: . 4033 S: 2.0 cap://bobo.ex.com/relcal3 4034 S: Content-type:text/calendar; Method=RESPONSE; 4035 S: Optinfo=VERSION:2.1 4036 S: Content-Transfer-Encoding: 7bit 4037 S: 4038 S: BEGIN:VCAP 4039 S: VERSION:2.1 4040 S: METHOD:RESPONSE 4041 S: CMDID:xyz12345 4042 S: TARGET:cap://bobo.ex.com/relcal3 4043 S: BEGIN:VEVENT 4044 S: DTSTART:19990310T130000Z 4045 S: DTEND:19990310T133000Z 4047 S: UID:abcxyz8999 4048 S: SUMMARY:Meet with brave brave Sir Robin 4049 S: BEGIN:VALARM 4050 S: TRIGGER:19990310T132500Z 4051 S: SUMMARY:Almost time.. 4052 S: ACTION:DISPLAY 4053 S: END:VALARM 4054 S: END:VEVENT 4055 S: END:VCAP 4056 S: . 4057 S: 2.0 cap://bobo.ex.com/relcal2 4058 S: Content-type:text/calendar; Method=RESPONSE; 4059 S: Optinfo=VERSION:2.1 4060 S: Content-Transfer-Encoding: 7bit 4061 S: 4062 S: BEGIN:VCAP 4063 S: VERSION:2.1 4064 S: METHOD:RESPONSE 4065 S: CMDID:xyz12345 4066 S: TARGET:cap://bobo.ex.com/relcal2 4067 S: BEGIN:VEVENT 4068 S: REQUEST-STATUS:2.0 4069 S: END:VEVENT 4070 S: END:VCAP 4071 S: . 4073 7.2.1.7.1 Query With A Stored Query 4075 This will run a stored VQUERY and return the results of the 4076 VQUERY. 4078 BEGIN:VQUERY 4079 QUERYNAME:StoredVQuery-1 4080 END:VQUERY 4082 This will fetch all calendar store properties. This MUST NOT 4083 return any VCALENDARs. 4085 BEGIN:VCAP 4086 VERSION:2.1 4087 METHOD:READ 4088 CMDID:-2ir- 4089 TARGET:cap://bobo.ex.com 4090 BEGIN:VQUERY 4091 QUERY:SELECT * FROM CALSTORE 4092 END:VQUERY 4093 END:VCAP 4095 This will fetch all calendar properties. This MUST NOT return any 4096 components. 4098 BEGIN:VCAP 4099 VERSION:2.1 4100 METHOD:READ 4101 CMDID:-2ir- 4102 TARGET:cap://bobo.ex.com/relcal4 4103 BEGIN:VQUERY 4104 QUERY:SELECT * FROM VCALENDAR 4105 END:VQUERY 4106 END:VCAP 4108 This will fetch all stored VQUERYs. 4110 BEGIN:VCAP 4111 VERSION:2.1 4112 METHOD:READ 4113 CMDID:didmc 4114 TARGET:cap://bobo.ex.com/relcal4 4115 BEGIN:VQUERY 4116 QUERY:SELECT * FROM VQUERY 4117 END:VQUERY 4118 END:VCAP 4120 7.2.2 Scheduling Commands 4122 The following provide a set of scheduling commands (or methods) in 4123 CAP. Scheduling commands allow a CU to indirectly manipulate a 4124 calendar by asking another CU to perform an operation on their 4125 calendar. For example, CU-A can request CU- B to add a meeting to 4126 their calendar; in effect inviting CU-B to the meeting. 4128 Calendar access rights can be granted for scheduling commands without 4129 granting rights for more generalized access with the calendar 4130 commands. 4132 [EDITORS NOTE: This section needs to be completed by adding the 4133 restriction tables for each of these iTIP methods. The basis for the 4134 text is to be taken from [iTIP].] 4136 7.2.2.1 Reading Scheduling Components 4138 A CU might be invited to a meeting. If the CU had been invited by 4139 CAP, the entry in the CU calendar will be scheduled, but not booked. 4140 So a CUA will need to look for scheduled entries in the calendar and 4141 present them to the CU or automaticly decide if the invitation is to 4142 be accepted or processed. 4144 Example: 4146 The little league coach places the teams entire schedule into your 4147 calendar. Lets say that every game and practice is on a Friday night 4148 and your calendar now has this iTIP scheduling data: 4150 BEGIN:VCAP 4151 VERSION:2.0 4152 METHOD:PUBLISH 4153 BEGIN:VEVENT 4154 DTSTAMP;TZID=US/Pacific:20000229T180000 4155 DTSTART;TZID=US/Pacific:20000303T180000 4156 ORGANIZER:coach@little.league.com 4157 SUMMARY: Schedule of games and practice 4158 UID:1-coach@little.league.com 4159 SEQUENCE:0 4160 DESCRIPTION:Please have your child at the field 4161 and ready to play by 6pm. 4162 RRULE:FREQ=WEEKLY;COUNT=10 4163 END:VEVENT 4164 END:VCAP 4166 At this point the above VEVENT is not booked in your calendar, It is 4167 simply scheduled. A CUA would fetch this and all other scheduled 4168 VEVENTs from your calendar with: 4170 C: SENDDATA 4171 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4172 C: 4173 C: BEGIN:VCAP 4174 C: VERSION:2.1 4175 C: BEGIN:VCOMMAND 4176 C: METHOD:READ 4177 C: CMDID:xyz12345 4178 C: TARGET:relcal2 4179 C: BEGIN:VQUERY 4180 C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE' 4181 C: END:VQUERY 4182 C: END:VCOMMAND 4183 C: END:VCAP 4184 C: . 4186 The the CUA and CU could determine which scheduling items were to 4187 remain on the calendar. Each scheduling component could be deleted 4188 or updated with METHOD:MODIFY to change the METHOD from PUBLISH, 4189 REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to 4190 what the CU and CUA had decided. 4192 In some cases the CUA could automaticly do the work and inform the 4193 CU. An example of this is CANCEL. If configured to process 4194 METHOD:CANCEL it could METHOD:DELETE the component an inform the CU 4195 that the booked component had been canceled. 4197 The CUA MUST process the scheduled components in the order sent. 4198 Some optimization could be done by the CUA. One example is if a 4199 PUBLISH and later a CANCEL for the same component with the same 4200 SEQUENCE number were scheduled, but not booked. The CUA might never 4201 inform the CU and treat it as if the PUBLISH had never been received 4202 by doing a METHOD:DELETE on both entries. 4204 It is important to note that scheduled components do not show up in 4205 busy time as BUSY. Only when they are booked does the TRANSP:OPAQUE 4206 property take effect. A CS implementation MAY mark the time as 4207 TENTATIVE. This is an implementation and administrative choice. 4209 7.2.2.2 PUBLISH 4211 Arguments: 4213 Data: data as described below 4215 Result: 4217 2.0 - success 4219 2.2 - will attempt operation on the remote CAP server 4221 Permission 4223 Calendar already exists 4225 Bad args 4227 Parent Calendar(s) not found 4229 If the CU wishes to keep the published entry. A METHOD:MODIFY 4230 changing the entries METHOD from PUBLISH to CREATE would be done, 4231 booking the entry. Or METHOD:DELETE if the CU did not wish this 4232 scheduled item to exist in their calendar. 4234 7.2.2.3 REQUEST 4236 Arguments: 4238 Data: data as described below 4240 Result: 4242 2.0 - success 4244 2.2 - will attempt operation on the remote CAP server 4246 Permission 4248 Calendar already exists 4250 Bad args 4252 Parent Calendar(s) not found 4254 This as described in [iTIP] and would be modified just like PUBLISH 4255 above. 4257 7.2.2.4 REPLY 4259 Arguments: 4261 Data: data as described below 4263 Result: 4265 2.0 - success 4267 2.2 - will attempt operation on the remote CAP server 4269 Permission 4271 Calendar already exists 4273 Bad args 4275 Parent Calendar(s) not found 4277 7.2.2.5 ADD 4279 Arguments: 4281 Data: data as described below 4283 Result: 4285 2.0 - success 4287 2.2 - will attempt operation on the remote CAP server 4289 Permission 4291 Calendar already exists 4293 Bad args 4295 Parent Calendar(s) not found 4297 7.2.2.6 CANCEL 4299 Arguments: 4301 Data: data as described below 4303 Result: 4305 7.2.2.7 REFRESH 4307 Arguments: 4309 Data: data as described below 4311 Result: 4313 This as described in [iTIP] and would be modified just like PUBLISH 4314 above. The CS MAY automaticly send out REFRESH replies via iMIP or 4315 CAP if able, then METHOD:DELETE the REFRESH. But only if there are 4316 no other pending scheduled entries for this calendar that may effect 4317 what REFRESH would send back. If the CS is not able to reply to the 4318 REFRESH request then it is left in the scheduling queue until the 4319 CUA and CU processes the queue. At the point where there are no 4320 outstanding scheduled command that would effect the reply results, 4321 the CS may then automaticly send the reply to the REFRESH request. 4323 7.2.2.8 COUNTER 4325 Arguments: 4327 Data: data as described below 4329 Result: 4331 7.2.2.9 DECLINECOUNTER 4333 Arguments: 4335 Data: data as described below 4337 Result: 4339 7.2.3 iTIP Examples 4341 The following examples describe scenarios for the handling of 4342 incoming iTIP data. An appropriate sort-order for the handling of 4343 incoming iTIP is by UID, Recurrence-id, sequence, dtstamp. This 4344 processing may be optimized, for instance, REFRESHs could be 4345 processed last. 4347 As an update to [iTIP], data with the "COUNTER" method should be 4348 processed even if the Sequence number is stale. 4350 7.2.3.1 Sending and Receiving an iTIP request 4352 In this example A invites B and C to a meeting, B accepts the meeting 4353 and C rejects it. The calendars for A, B and C are relcal1, relcal2 4354 and relcal3 respectively, and are all on the same server, 4355 "cal.foo.com". A lot of these described actions are performed by the 4356 CUAs and not the users themselves, the CUAs are called A-c, B-c and 4357 C-c respectively. 4359 A wishes to create a meeting with B and C, so A-c uses CAP to send 4360 the following iTIP request to relcal2 and relcal3, while logged in to 4361 "cal.foo.com". 4363 BEGIN:VCAP 4364 VERSION:2.1 4366 CMDID:xhj-dd 4367 BEGIN:VCOMMAND 4368 METHOD:REQUEST 4369 TARGET:cap://cal.foo.com/relcal2 4370 TARGET:relcal3 4371 BEGIN:VEVENT 4372 UID:abcd12345 4373 DTSTART:19990307T180000Z 4374 DTEND:19990307T190000Z 4375 ORGANIZER:cap://cal.foo.com/relcal1 4376 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- 4377 ACTION:cap://cal.foo.com/relcal2 4378 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- 4379 ACTION:cap://cal.foo.com/relcal3 4380 SUMMARY:Important Meeting 4381 END:VEVENT 4382 END:VCOMMAND 4383 END:VCAP 4385 An incoming event (indicated by the value of the "METHOD" property) 4386 then appears in relcal2 and relcal3, with the following data: 4388 BEGIN:VEVENT 4389 METHOD:REQUEST 4390 UID:abcd12345 4391 DTSTART:19990307T180000Z 4392 DTEND:19990307T190000Z 4393 ORGANIZER:cap://cal.foo.com/relcal1 4394 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c 4395 om/relcal2 4396 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c 4397 om/relcal3 4398 SUMMARY:Important Meeting 4399 END:VEVENT 4401 B-c and C-c must search for such incoming events, they do so using 4402 the following CAP search: 4404 BEGIN:VCAP 4405 VERSION:2.1 4406 BEGIN:VCOMMAND 4407 METHOD:READ 4408 CMDID:xhr-de 4409 TARGET:relcal2 4410 # or TARGET:relcal3 4411 BEGIN:VCOMMAND 4412 BEGIN:VQUERY 4413 QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST'; 4414 END:VQUERY 4415 END:VCOMMAND 4416 END:VCOMMAND 4417 END:VCAP 4419 In response to this search they get the above event. B-c and C-c 4420 must then crack open the VEVENT, find the UID and determine if there 4421 is already an event on their calendar with that UID. To do this they 4422 use the following search: 4424 BEGIN:VCAP 4425 VERSION:2.1 4426 BEGIN:VCOMMAND 4427 METHOD:READ 4428 CMDID:xhr-df 4429 TARGET:relcal2 4431 BEGIN:VCOMMAND 4432 BEGIN:VQUERY 4433 QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' AND 4434 METHOD = 'CREATE' 4435 END:VQUERY 4436 END:VCOMMAND 4437 END:VCOMMAND 4438 END:VCAP 4440 We assume that the event is not already in their relcal2 or relcal3. 4442 B-c prompts B who decides to accept the meeting request, and B-c 4443 creates a copy of the event in relcal2, with the "PARTSTAT" parameter 4444 set to ACCEPTED. B-c also sends this copy to the Organizer at 4445 relcal1 as an iTIP REPLY, preserving the CMDID: 4447 BEGIN:VCAP 4448 VERSION:2.1 4449 CMDID:xhj-dd 4450 METHOD:REPLY 4451 TARGET:cap://cal.foo.com/relcal1 4452 BEGIN:VEVENT 4453 UID:abcd12345 4454 DTSTART:19990307T180000Z 4455 DTEND:19990307T190000Z 4456 ORGANIZER:cap://cal.foo.com/relcal1 4457 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 4458 SUMMARY:Important Meeting 4459 END:VEVENT 4460 END:VCAP 4462 C, on the other hand, decides to decline the meeting, and C-c sends a 4463 reply to the Organizer to that effect, as follows: 4465 BEGIN:VCAP 4466 VERSION:2.1 4467 CMDID:xhj-dd 4468 METHOD:REPLY 4469 TARGET:cap://cal.foo.com/relcal1 4470 BEGIN:VEVENT 4471 UID:abcd12345 4472 DTSTART:19990307T180000Z 4473 DTEND:19990307T190000Z 4474 ORGANIZER:cap://cal.foo.com/relcal1 4475 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 4476 SUMMARY:Important Meeting 4477 END:VEVENT 4478 END:VCAP 4480 It is preferable that C-c store the event in relcal3 even though it 4481 has been declined. Storing the event in relcal3 allows subsequent 4482 iTIP messages to be interpreted correctly. The "PARTSTAT" parameter 4483 indicates that the event was refused. 4485 After receiving the replies from relcal2 and relcal3, A-c updates the 4486 version of the event in relcal1 to indicate the new participation 4487 status: 4489 BEGIN:VEVENT 4490 METHOD:REQUEST 4491 UID:abcd12345 4492 DTSTART:19990307T180000Z 4493 DTEND:19990307T190000Z 4494 ORGANIZER:cap://cal.foo.com/relcal1 4495 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 4496 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 4497 SUMMARY:Important Meeting 4498 END:VEVENT 4500 A-c then sends a new iTIP request to relcal2 only, indicating the 4501 updated information. 4503 7.2.3.2 Handling an iTIP refresh 4505 A little bit later, C is thinking about accepting the event in the 4506 previous example, but first wants to check the current state of the 4507 event. To find the current state C-c uses the iTIP "REFRESH" method, 4508 sending the following to relcal1: 4510 BEGIN:VCAP 4511 VERSION:2.1 4512 CMDID:xud-pn 4513 METHOD:REFRESH 4514 TARGET:cap://cal.foo.com/relcal1 4515 BEGIN:VEVENT 4516 UID:abcd12345 4517 ORGANIZER:cap://cal.foo.com/relcal1 4518 ATTENDEE:cap://cal.foo.com/relcal3 4519 DTSTAMP:19990306T202333Z 4520 END:VEVENT 4521 END:VCAP 4523 A-c finds the refresh as an incoming iTIP, and searches for the 4524 corresponding event. Having found the event (with no changes since 4525 the last example) A-c then verifies that relcal3 is in fact an 4526 Attendee of the event and is thus allowed to request a refresh. (In 4527 the case of a published event things are more complicated.) A-c 4528 packages the event up as an iTIP request and sends it to relcal3: 4530 BEGIN:VCAP 4531 VERSION:2.1 4532 CMDID: xud-pn 4533 METHOD:REQUEST 4534 TARGET:cap://cal.foo.com/relcal3 4535 BEGIN:VEVENT 4536 UID:abcd12345 4537 DTSTART:19990307T180000Z 4538 DTEND:19990307T190000Z 4539 ORGANIZER:cap://cal.foo.com/relcal1 4540 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 4541 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 4542 SUMMARY:Important Meeting 4543 SEQUENCE:0 4544 DTSTAMP:19990306T204333Z 4545 END:VEVENT 4546 END:VCAP 4548 7.2.3.3 Sending and accepting an iTIP counter 4550 Having received the latest copy of the event C wishes to propose a 4551 venue for the event, using an iTIP COUNTER. To do this C-c sends the 4552 following to relcal1: 4554 BEGIN:VCAP 4555 VERSION:2.1 4556 CMDID:zzykjjk 4557 METHOD:COUNTER 4558 TARGET:cap://cal.foo.com/relcal1 4559 BEGIN:VEVENT 4560 UID:abcd12345 4561 DTSTART:19990307T180000Z 4562 DTEND:19990307T190000Z 4563 ORGANIZER:cap://cal.foo.com/relcal1 4564 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 4565 SUMMARY:Important Meeting 4566 LOCATION:La Belle Province 4567 COMMENT:My favorite restaurant, I'll definitely go if it's 4568 there. 4569 END:VEVENT 4570 END:VCAP 4572 Having sent the information to relcal1, C-c shouldn't store the new 4573 details in relcal3. If C-c updated the version in relcal3 and 4574 relcal1 did not reply to the counter, then relcal3 would have 4575 incorrect information. Instead C-c preserves the correct information 4576 and waits for a response from relcal1. A CUA implementation may wish 4577 to preserve this information itself, externally to the CS. 4579 In order to receive an iTIP counter A-c follows the same search as 4580 for other iTIP data, first find the incoming message, next find any 4581 matching events in the calendar store. 4583 Having found the matching event, A reviews the proposed changes and 4584 decides to accept the COUNTER. To do this, A-c modifies the version 4585 in relcal1 (bumping the sequence number) to: 4587 BEGIN:VEVENT 4588 METHOD:CREATE 4589 UID:abcd12345 4590 DTSTART:19990307T180000Z 4591 DTEND:19990307T190000Z 4592 ORGANIZER:cap://cal.foo.com/relcal1 4593 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 4595 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 4596 SUMMARY:Important Meeting 4597 LOCATION:La Belle Province 4598 SEQUENCE:1 4599 END:VEVENT 4601 A-c then sends the updated version as a request to both relcal2 and 4602 relcal3: 4604 BEGIN:VCAP 4605 VERSION:2.1 4606 CMDID:xup-po 4607 METHOD:REQUEST 4608 TARGET:cap://cal.foo.com/relcal2 4609 TARGET:cap://cal.foo.com/relcal3 4610 BEGIN:VEVENT 4611 UID:abcd12345 4612 DTSTART:19990307T180000Z 4613 DTEND:19990307T190000Z 4614 ORGANIZER:cap://cal.foo.com/relcal1 4615 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- 4616 ACTION:cap://cal.foo.com/relcal2 4617 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- 4618 ACTION:cap://cal.foo.com/relcal3 4619 SUMMARY:Important Meeting 4620 LOCATION:La Belle Province 4621 SEQUENCE:1 4622 DTSTAMP:19990307T054339Z 4623 END:VEVENT 4624 END:VCAP 4626 7.2.3.4 Declining an iTIP counter 4628 B does not like the new location and also counters the event, B-c 4629 sends the following iTIP: 4631 BEGIN:VCAP 4632 VERSION:2.1 4633 CMDID:xim-ef 4634 METHOD:COUNTER 4635 TARGET:cap://cal.foo.com/relcal1 4636 BEGIN:VEVENT 4637 UID:abcd12345 4638 DTSTART:19990307T180000Z 4639 DTEND:19990307T190000Z 4640 ORGANIZER:cap://cal.foo.com/relcal1 4641 ATTENDEE:cap://cal.foo.com/relcal2 4642 SUMMARY:Important Meeting 4643 LOCATION:Au Coin Dor=E9 4644 END:VEVENT 4645 END:VCAP 4647 However, C does not accept the counter, and C-c replies with a 4648 decline counter: 4650 BEGIN:VCAP 4651 VERSION:2.1 4652 CMDID:xim-ef 4653 METHOD:DECLINE-COUNTER 4654 TARGET:cap://cal.foo.com/relcal2 4655 BEGIN:VEVENT 4656 DTSTAMP:19990307T093245Z 4657 UID:abcd12345 4658 ORGANIZER:cap://cal.foo.com/relcal1 4659 SEQUENCE:1 4660 END:VEVENT 4661 END:VCAP 4663 CUA-b MUST keep the original information when sending the counter, 4664 and there is no problem when no information is returned in the 4665 DECLINE-COUNTER. 4667 8. Response Codes 4669 Numeric response codes are returned at both the transfer and 4670 application layer. The same set of codes is used in both cases. 4672 [EDITORS NOTE: Do we want to use the same set of codes?] 4674 The format of these codes is described in [iCAL], and extend in 4675 [iTIP] and [iMIP]. The following describes new codes added to this 4676 set. 4678 At the application layer response codes are returned as the value of 4679 a "REQUEST-STATUS" property. The value type of this property is 4680 modified from that defined in [iCAL], to make the accompanying text 4681 optional. 4683 Code Params Description 4684 -------------------------------------------------------------- 4685 2.0 [CMDID] varies 4686 Success, The parameters vary with the 4687 operation and are specified. 4689 2.0.1 [CMDID] Success, send data, terminate with 4690 >CRLF>.>CRLF> 4692 2.0.2 [CMDID] A reply is pending. It could not be com- 4693 pleted in the specified amount of time. 4694 The server awaits a CONTINUE or ABORT 4695 command. If can optionally be followed 4696 by a CMDID. If the SENDDATA object con- 4697 tained a CMDID, then the CS MUST append 4698 the CMDID to the 2.0.2 reply for that 4699 object. 4701 2.0.3 [CMDID] In response to the client issuing an 4702 ABORT command, this reply code indicates 4703 that any command currently underway was 4704 successfully aborted. If can optionally 4705 be followed by a CMDID. If the SENDDATA 4706 object contained a CMDID, then the CS 4707 MUST append the CMDID to the 2.0.2 reply 4708 for that object. 4710 2.0.6 [CMDID] An operation is being attempted on a 4711 re-mote server. This response indicates 4712 that the server has not yet been con- 4713 tacted but an attempt will be made to 4714 contact it after the command has been 4715 sent. 4717 3.1.4 [CMDID] Capability not supported. 4719 4.1 [CMDID] Calendar store access denied. 4721 6. 1 [CMDID] Authenticate failure: unsupported au- 4722 thentication mechanism, credentials re- 4723 jected. 4725 6.2 [CMDID] Sender aborted authentication, authenti- 4726 cation exchange cancelled. 4728 6.3 [CMDID] Attempt to create or modify an event 4729 such that it would overlap another event 4730 in either of the following two circum- 4731 stances: 4733 (a) One of the events has a TRANSP 4734 property set to OPAQUE-NOCONFLICT or 4735 TRANSPARENT-NOCONFLICT. 4737 (b) The calendar's ALLOW-CONFLICT 4738 property is set to NO. 4740 6.XXX [CMDID] [EDITORS NOTE: More are in this memo - 4741 add here TODO] 4743 7.0 [CMDID] A timeout has occurred. The server was 4744 unable to complete the operation in the 4745 requested time. 4747 8.0 [CMDID] A failure has occurred in the Receiver 4748 that prevents the operation from 4749 succeeding. 4751 8.1 [CMDID] Sent when a session cannot be 4752 established because the CAP Server is too 4753 busy. 4755 8.2 [CMDID] Used to signal that an ICAL object has 4756 exceeded the server's size limit 4758 8.3 [CMDID] A DATETIME value was too large to be 4759 represented on this Calendar. 4761 8.4 [CMDID] A DATETIME value was too far in the past 4762 to be represented on this Calendar. 4764 8.5 [CMDID] An attempt was made to create a new 4765 object but the unique id specified is 4766 already in use. 4768 9.0 [CMDID] An unrecognized command was received. 4770 10.1 [CMDID] 4771 Accompanied by an alternate address. The 4772 RECIPIENT specified should be contacted at 4773 the given alternate address. The 4774 referral address MUST follow the reply 4775 code. 4777 10.2 The server is shutting down. 4779 10.4 The operation has not be performed 4780 because it would cause the resources 4781 (memory, disk,CPU, etc) to exceed the 4782 allocated quota. 4784 10.5 [CMDID] The ITIP message has been queued too too 4785 long. Delivery has been aborted. 4786 -------------------------------------------------------------- 4788 8.1 Examples 4790 8.1.1 Authentication Examples 4792 8.1.1.1 Login Using Kerberos V4 4794 8.1.1.2 Error Scenarios 4796 8.2 Read Examples 4798 8.2.1 Read From A Single Calendar 4800 In this example bill@example.com reads a day's worth of events from 4801 cap://cal.example.com/opaqueid99. 4803 C: SENDDATA 4804 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4805 C: 4806 C: BEGIN:VCAP 4807 C: VERSION:2.1 4808 C: BEGIN:VCOMMAND 4809 C: METHOD:READ 4810 C: CMDID:xyz12345 4811 C: TARGET:cap://cal.example.com/opaqueid99 4812 C: BEGIN:VQUERY 4813 C: QUERY:SELECT DTSTART,DTEND,SUMMARY, UID FROM VEVENT 4814 WHERE DTEND >= '19990714T080000Z' 4815 AND DTSTART <= '19990715T080000Z' 4816 C: END:VQUERY 4817 C: END:VCOMMAND 4818 C: END:VCAP 4819 C: . 4820 # this response code means that the transport successfully 4821 # delivered the data. 4822 S: 2.0 ; got the request OK ; really 4823 S: . 4824 S: Content-type:text/calendar; Method=RESPONSE; 4825 S: Optinfo=VERSION:2.1 4826 S: Content-Transfer-Encoding: 7bit 4827 S: 4828 S: BEGIN:VCAP 4829 S: VERSION:2.1 4830 S: METHOD:RESPONSE 4831 S: TARGET:cap://cal.example.com/opaqueid99 4832 S: CMDID:xyz12345 4833 S: REQUEST-STATUS:2.0 4834 S: BEGIN:VEVENT 4835 S: DTSTART:19990714T200000Z 4836 S: DTEND:19990714T210000Z 4837 S: UID:000444888929922 4838 S: SUMMARY:Blah bla 4839 S: END:VEVENT 4840 S: BEGIN:VEVENT 4841 S: UID:0034848098038888989443 4842 S: SUMMARY:meeting 4843 S: DTEND:19990714T233000Z 4844 S: DTSTART:19990714T223000Z 4845 S: END:VEVENT 4846 S: END:VCAP 4847 S: . 4849 8.2.2 Read From Multiple Calendars 4851 In this example bill@example.com reads a day's worth of events from 4852 cap://cal.example.com/opaqueid101 and 4853 cap://cal.example.com/opaqueid103 4855 C: SENDDATA 4856 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4857 C: 4859 C: BEGIN:VCAP 4860 C: VERSION:2.1 4861 C: BEGIN:VCOMMAND 4862 C: METHOD:READ 4863 C: CMDID:xyz12346 4864 C: TARGET:cap://cal.example.com/opaqueid101 4865 C: TARGET:opaqueid103 4866 C: BEGIN:VQUERY 4867 C: VSCOPE:VEVENT 4869 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT 4870 C: WHERE DTEND >= 19990714T080000Z AND 4871 C: DTSTART <= 19990715T080000Z 4872 C: END:VQUERY 4873 C: END:VCOMMAND 4874 C: END:VCAP 4875 C: . 4876 S: 2.0 4877 S: . 4878 S: Content-Type:multipart/mixed; 4879 S: boundary="--FEE3790DC7E35189CA67" 4880 S: 4881 S: ----FEE3790DC7E35189CA67 4882 S: Content-type:text/calendar; Method=RESPONSE; 4883 S: Optinfo=VERSION:2.1 4884 S: Content-Transfer-Encoding: 7bit 4885 S: 4886 S: BEGIN:VCAP 4887 S: VERSION:2.1 4888 S: METHOD:RESPONSE 4889 S: TARGET:cap://cal.example.com/opaqueid103 4890 S: CMDID:xyz12346 4891 S: REQUEST-STATUS:2.0 4892 S: BEGIN:VEVENT 4893 S: UID:0034848098038888989443 4894 S: SUMMARY:meeting 4895 S: DTEND:19990714T233000Z 4896 S: DTSTART:19990714T223000Z 4897 S: END:VEVENT 4898 S: END:VCAP 4899 S: 4900 S: ----FEE3790DC7E35189CA67CE2C 4901 S: Content-type:text/calendar; Method=RESPONSE; 4902 S: Optinfo=VERSION:2.1 4903 S: Content-Transfer-Encoding: 7bit 4904 S: 4905 S: BEGIN:VCAP 4906 S: VERSION:2.1 4907 S: METHOD:RESPONSE 4908 S: TARGET:cap://cal.example.com/opaqueid101 4909 S: CMDID:xyz12346 4910 S: REQUEST-STATUS:4.1 ; access denied 4911 S: END:VCAP 4912 S: 4913 S: ----FEE3790DC7E35189CA67CE2C 4914 S: . 4916 8.2.3 Timeouts 4918 In this example bill@example.com attempts to read a calendar but the 4919 latency time he supplies is not sufficient for the server to complete 4920 the command. 4922 C: SENDDATA 3 4923 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4924 C: 4925 C: BEGIN:VCAP 4926 C: VERSION:2.1 4927 C: BEGIN:VCOMMAND 4928 C: METHOD:READ 4929 C: CMDID:xyz12346 4930 C: TARGET:cap://cal.example.com/opaqueid101 4931 C: TARGET:opaqueid103 4932 C: BEGIN:VQUERY 4933 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT 4934 C: WHERE DTEND >= '19990714T080000Z' AND 4935 C: DTSTART <= '19990715T080000Z' 4936 C: END:VQUERY 4937 C: END:VCOMMAND 4938 C: END:VCALENDAR 4939 C: . 4940 S: 7.0 ; xyz12346 4941 S: . 4942 S: . 4944 If Bill wants to continue and give the server more time he would 4945 issue a CONTINUE command: 4947 C: CONTINUE 10 ; xyz12346 4949 If Bill wants to abort the command and not wait any further he would 4950 issue an ABORT command: 4952 C: ABORT ; xyz12346 4953 S: 2.0 4954 S: . 4955 S: . 4957 8.2.4 Using Parent and Children Properties 4959 8.2.5 Query VEVENT.DTSTART and VALARM.DTSTART 4960 9. Implementation Issues 4962 1. What are the minimum component properties set required to create 4963 a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and 4964 UID. 4966 [EDITORS NOTE (dr): They MUST be the same as for iTIP] 4968 2. What is the state of all undefined properties? PROPOSAL: Not 4969 defined. So a query will not return them, if they are selected. 4971 [EDITORS NOTE (dr): Many have default values, a CS may return the 4972 default values?] 4974 10. Properties 4976 [EDITORS NOTE: These extensions/changes to iCalendar need to be 4977 reformatted to conform to the IANA registration process defined in 4978 section 7 of [iCAL].] 4980 10.1 Calendar Store Properties 4982 The following are properties of the calendar store. 4984 Name Read Value Description 4985 Only Type 4986 -------------------------------------------------------------- 4987 CALMASTER N URI The email address for a 4988 Responsible person. MUST be a 4989 mailto URL. 4991 CSID Y URI The CSID of this calendar 4992 store. If not specified, it is 4993 the same as the hostname or 4994 virtual host name. 4996 DEFAULT_VCARS N TEXT A multivalued property 4997 Containing the default VCARs 4998 for newly created top level 4999 calendars. Each entry is a 5000 CARID It MUST include at a 5001 minimum 5002 READBUSYTIMEINFO,REQUESTONLY, 5003 UPDATEPARTSTATUS, and 5004 DEFAULTOWNER. 5006 MAXDATE Y DATE-TIME The date/time in the future 5007 beyond which the server cannot 5008 represent. If not specified, 5009 then 99991231T235959 will be 5010 assumed. 5012 MINDATE Y DATE-TIME The date/time in the past prior 5013 To which the server cannot 5014 represent. If not specified, 5015 then 00000101T000000 will be 5016 assumed. 5018 CURRENT_DATETIME Y DATE-TIME Current server time. This is 5019 returned as a local time and 5020 TZID. 5022 RECUR_ACCEPTED Y BOOLEAN Boolean value will be set to 5023 TRUE if the server will accept 5024 recurrence rules. It will be 5025 set to FALSE if the server will 5026 not accept recurrence rules. If 5027 not specified a CUA MUST assume 5028 TRUE. 5030 RECUR_EXPAND Y BOOLEAN If set to TRUE, the CS supports 5031 The expansion of recurrence 5032 rules. If set to FALSE, the CS 5033 is incapable of expanding 5034 recurrence rules. If not 5035 specified a CUA MUST assume 5036 TRUE. 5038 RECUR_LIMIT Y INTEGER This numeric value describes 5039 How the server handles 5040 unbounded recurrences. The 5041 value is only valid if 5042 RECURRENCE is TRUE. If the 5043 value is 0 it means that the 5044 server supports unbounded 5045 recurrence rules. If it is non- 5046 zero, it is a positive integer 5047 indicating the number of 5048 instances that will be created 5049 when the server expands an 5050 unbounded recurrence rule when 5051 fetched from the CS. A CUA MUST 5052 query for date ranges when this 5053 value is zero. 5055 VERSION Y TEXT The version of the CS. The 5056 Default and the only currently 5057 Supported version is "2.0" to 5058 match the [iCAL] VERSION. 5060 10.2 Calendar Properties 5062 Name Read Value Description 5063 Only Type 5064 -------------------------------------------------------------- 5065 ALLOW-CONFLICTS N BOOLEAN This boolean value indicates 5066 Whether or not the calendar 5067 supports event conflicts. That 5068 is, whether or not any of the 5069 events in the calendar can 5070 overlap. If not specified the 5071 default value is TRUE meaning 5072 that conflicts are allowed. 5074 CALSCALE N TEXT The CALSCALE for this calendar. 5075 If not specified the default is 5076 GREGORIAN. 5078 CHARSET N TEXT The default charset for 5079 Localized strings in this 5080 calendar. If not specified, the 5081 default is UTF-8. 5083 CHILDREN Y TEXT The list of sub-calendars 5084 Belonging to this calendar. An 5085 empty list means no children. 5086 The results may be a comma 5087 separated list of children. 5088 Each entry returned is a CALID. 5089 The default is an empty list. 5091 CREATED Y DATE-TIME The timestamp of the calendar's 5092 create date. 5094 DEFAULT_VCAR N TEXT The default VCARs for newly 5095 Created top level calendars. 5096 This is a CARID. The default 5097 value is the value of 5098 DEFAULT_VCAR in the CALSTORE 5099 table. 5101 LANGUAGE N TEXT The default language for 5102 localizable strings in this 5103 calendar. There is no default. 5104 This value MUST NOT be empty. 5106 LAST-MODIFIED N DATE-TIME The timestamp when the 5107 Properties of the calendar were 5108 last updated. Default is the 5109 same as CREATED. 5111 NAME N TEXT The display name for this 5112 calendar. It is a localizable 5113 string. If not provided, an 5114 empty value will be returned. 5116 OWNERS N URI A multi-instanced property 5117 indicating the calendar owner. 5118 Each entry returned will be a 5119 UPN. There must be at least one 5120 owner. 5122 PARENT N URI The CALID of this calendars 5123 Parent maintained by a CAP 5124 server. An empty value means 5125 the calendar is the top level 5126 parent. The default value is no 5127 parent. 5129 RELCALID N URI A unique name for the calendar. 5130 There is no default value and 5131 This value MUST NOT be empty. 5133 TOMBSTONE N BOOLEAN TRUE indicator that this 5134 Calendar has been marked as 5135 deleted. The default value is 5136 FALSE. 5138 TZID N TEXT The id of the timezone 5139 Associated with this calendar. 5140 See TZID in [iCAL]. The default 5141 value is GMT. 5143 11. Security Considerations 5145 For the mandatory SASL mechanism that CAP specifies, the mechanism 5146 support is: 5148 MUST authentication 5150 MUST authorization 5152 MAY impersonation 5154 12. CAP Item Registration 5156 This section provides the process for registration of new or modified 5157 CAP entities. 5159 12.1 Registration of New and Modified CAP Entities 5161 New CAP entities are registered by the publication of an IETF Request 5162 for Comment (RFC). Changes to a CAP item are registered by the 5163 publication of a revision of the RFC defining the method. 5165 12.2 Registration of New Entities 5167 This section defines procedures by which new entities (i.e., 5168 components, properties, parameters, enumerated values or restriction 5169 tables) for a CAP item can be registered with the IANA. 5171 Non-standard, experimental entities can be used by bilateral 5172 agreement, provided the associated properties names follow the "X-" 5173 convention. Such non-standard and experimental entities are non-IANA 5174 entities and need not be registered using this process. 5176 The procedures defined here are designed to allow public comment and 5177 review of new CAP entities, while posing only a small impediment to 5178 the definition of new properties. 5180 Registration of a new CAP item is accomplished by the following 5181 steps. 5183 12.2.1 Define the Item 5185 A CAP item is defined by completing the following template. 5187 To: ietf-calendar@imc.org 5188 Subject: Registration of CAP item XXX 5189 Item name: 5190 Item purpose: 5191 Description: 5192 CAP terminology changes: 5193 CAP data model changes: 5194 CAP system model changes: 5195 Conformance considerations: 5196 Format definition: 5197 Examples: 5199 The meaning of each field in the template is as follows. 5201 Item name: The name of the item. 5203 Item purpose: The purpose of the item (e.g., Extends the CAP 5204 command set to poll for notifications, etc.). Give a short but 5205 clear description. 5207 Description: Any special notes about the item, how it is to be 5208 used, etc. 5210 CAP terminology changes: Any change or additions to the existing 5211 CAP terminology needs to be specified. 5213 CAP data model changes: Any of the valid property parameters for 5214 the property needs to be specified. 5216 CAP system model changes: 5218 Conformance: A clear summary of how and where this CAP item 5219 extension MUST, MAY, SHOULD or can be used. Any changes or impact 5220 to the existing conformance definition for CAP should be 5221 explained. The impact to implementations conforming to the 5222 existing CAP specification should be clearly described. 5224 Format definition: The ABNF for each element of the CAP item needs 5225 to be specified. 5227 Examples: One or more examples of instances of the CAP item and 5228 each of its usage scenarios needs to be specified. 5230 12.2.2 Post the item definition 5232 The item description MUST be posted to the new item discussion list, 5233 ietf-calendar@imc.org. 5235 12.2.3 Allow a comment period 5237 Discussion on the new item MUST be allowed to take place on the list 5238 for a minimum of two weeks. Consensus MUST be reached on the 5239 property before proceeding to the next step. 5241 12.2.4 Submit the proposal for approval 5243 Once the two-week comment period has elapsed, and the proposer is 5244 convinced consensus has been reached on the proposal, the 5245 registration application should be submitted to the Method Reviewer 5246 for approval. The Method Reviewer is appointed by the Application 5247 Area Directors and can either accept or reject the proposal 5248 registration. An accepted registration should be passed on by the 5249 Method Reviewer to the IANA for inclusion in the official IANA method 5250 registry. The registration can be rejected for any of the following 5251 reasons. 1) Insufficient comment period; 2) Consensus not reached; 5252 3) Technical deficiencies raised on the list or elsewhere have not 5253 been addressed. The Method Reviewers decision to reject a proposal 5254 can be appealed by the proposer to the IESG, or the objections raised 5255 can be addressed by the proposer and the proposal resubmitted. 5257 [EDITORS NOTE: John Stracke to review any updates] 5259 12.3 Property Change Control 5261 Existing CAP entities can be changed using the same process by which 5262 they were registered. 5264 1. Define the change 5266 2. Post the change 5268 3. Allow a comment period 5270 4. Submit the proposal for approval 5272 Note that the original author or any other interested party can 5273 propose a change to an existing CAP object, but that such changes 5274 should only be proposed when there are serious omissions or errors in 5275 the published memo. The Method Reviewer can object to a change if it 5276 is not backward compatible, but is not required to do so. 5278 CAP objects definitions can never be deleted from the IANA registry, 5279 but objects which are no longer believed to be useful can be declared 5280 OBSOLETE by adding this text to their "Item purpose" field. 5282 13. IANA Considerations 5284 This memo defines IANA registered extensions to the attributes 5285 defined by iCalendar, as defined in [iCAL], and [iTIP], as defined in 5286 [VCARD]. 5288 [EDITORS NOTE (DR): RFC2426 - is vCard. This needs more explanation. 5289 What does vCARD have todo with this?] 5291 IANA registration proposals for iCalendar and iTIP are to be mailed 5292 to the registration agent for the "text/calendar" [MIME] content- 5293 type, using the format defined in 5294 section 7 of [iCAL]. 5296 Authors' Addresses 5298 Steve Mansour 5299 Netscape, iPlanet 5300 501 E Middlfield Road 5301 Mountain View, CA 94043 5302 US 5304 Phone: +1-408-276-4268 5305 EMail: sman@netscape.com 5307 Doug Royer 5309 EMail: Doug@royer.com 5311 George Babics 5312 Steltor 5313 2000 Peel Street 5314 Montreal, Quebec H3A 2W5 5315 CA 5317 Phone: +1-514-733-8500 x4201 5318 Fax: +1-514-733-8878 5319 EMail: georgeb@steltor.com 5320 Paul Hill 5321 Massachusetts Institute of Technology 5322 W92-172 5323 77 Massachusetts Avenue 5324 Cambridge, MA 02139 5325 US 5327 Phone: +1-617-253-0124 5328 Fax: +1-617-258-8736 5329 EMail: phb@mit.edu 5331 Appendix A. Acknowledegements 5333 The following have individuals were major contributors in the 5334 drafting and discussion of this memo: 5336 Harald Alvestrand, Mario Bonin, Andre Courtemanche, Dave Crocker, 5337 Pat Egen, Gilles Fortin, Jeff Hodges, Alex Hoppman, Bruce Kahn, 5338 Lisa Lippert, David Madeo, Bob Mahoney, Bob Morgan, Pete O'Leary, 5339 Richard Shusterman, Tony Small, John Stracke, Mark Wahl, Alexander 5340 Taler. 5342 Appendix B. Bibliography 5344 [MIME] N. Borenstein and N. Freed, "MIME (Multipurpose Internet 5345 Mail Extensions) Part One: Mechanisms for Internet Draft UTF-825 5346 July 1996 5348 Specifying and Describing the Format of Internet Message Bodies", 5349 RFC 1521, Bellcore, Innosoft, September 1993. 5351 [TLS] Dierks, Allen, "The TLS Protocol", RFC 2246, January 1999 5353 [RFC2119] TODO... 5355 [SASL] RFC2222 TODO... 5357 [URL] Berners-Lee, Fielding, Masinter, "Uniform Resource 5358 Identifiers 5360 (URI): Generic Syntax", RFC 2396, August 1998. 5362 [iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling 5363 Core Object Specification (iCalendar)", RFC 2445, November 1998 5365 [iTIP] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- 5366 Independent Interoperability Protocol (iTIP)", RFC 2446, November 5367 1998 5369 [iMIP] Dawson, Mansour, Silverberg, "iCalendar Message-Based 5370 Interoperability Protocol (iMIP)", RFC 2445, November 1998 5372 [SQL] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka ANSI 5373 X3.135-1992, aka FiPS PUB 127-2 5375 [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 5376 to ISO/IEC 9075: 1992, also adopted as Amendment 1 to ANSI 5377 X3.135.1992 5379 [UNICODE] The Unicode Consortium, "The Unicode Standard - 5381 Worldwide Character Encoding -- Version 1.0", Addison-Wesley, 5382 Volume 1, 1991, Volume 2, 1992. UTF-8 is described in Unicode 5383 Technical Report #4. 5385 [US-ASCII] Coded Character Set--7-bit American Standard Code for 5386 Information Interchange, ANSI X3.4-1986. 5388 [VCARD] RFC.... TODO 5390 Full Copyright Statement 5392 Copyright (C) The Internet Society (2001). All Rights Reserved. 5394 This document and translations of it may be copied and furnished to 5395 others, and derivative works that comment on or otherwise explain it 5396 or assist in its implementation may be prepared, copied, published 5397 and distributed, in whole or in part, without restriction of any 5398 kind, provided that the above copyright notice and this paragraph are 5399 included on all such copies and derivative works. However, this 5400 document itself may not be modified in any way, such as by removing 5401 the copyright notice or references to the Internet Society or other 5402 Internet organizations, except as needed for the purpose of 5403 developing Internet standards in which case the procedures for 5404 copyrights defined in the Internet Standards process must be 5405 followed, or as required to translate it into languages other than 5406 English. 5408 The limited permissions granted above are perpetual and will not be 5409 revoked by the Internet Society or its successors or assigns. 5411 This document and the information contained herein is provided on an 5412 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 5413 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 5414 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 5415 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 5416 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5418 Acknowledgement 5420 Funding for the RFC Editor function is currently provided by the 5421 Internet Society.