idnits 2.17.1 draft-ietf-calsch-cap-09.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 38 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 161 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 369: '... is, "events MUST BE scheduled in ...' RFC 2119 keyword, line 423: '... These extensions MUST start with "x-"...' RFC 2119 keyword, line 454: '...flict, the Realm SHOULD be postfixed w...' RFC 2119 keyword, line 459: '...endar store. It MUST BE unique within...' RFC 2119 keyword, line 481: '...ess. A CU's UPN MUST never be an e-ma...' (253 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 302 has weird spacing: '...hat has been ...' == Line 354 has weird spacing: '...able to diffe...' == Line 486 has weird spacing: '...lm. In it's ...' == Line 801 has weird spacing: '... for that U...' == Line 1923 has weird spacing: '...roperty woul...' == (8 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: Purpose: The "ABORT" command is sent to request that the named or only in process command be aborted. Latency MUST not be supplied with the "ABORT" command. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2002) is 7844 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 5307 looks like a reference -- Missing reference section? 'BEEP' on line 5375 looks like a reference -- Missing reference section? 'RFCWORDS' on line 5412 looks like a reference -- Missing reference section? 'GUIDE' on line 5390 looks like a reference -- Missing reference section? 'URL' on line 5435 looks like a reference -- Missing reference section? 'URI' on line 5431 looks like a reference -- Missing reference section? 'URLGUIDE' on line 5427 looks like a reference -- Missing reference section? 'MIME' on line 5407 looks like a reference -- Missing reference section? 'CAP' on line 1299 looks like a reference -- Missing reference section? 'BEEPTCP' on line 5379 looks like a reference -- Missing reference section? 'X509CRL' on line 5439 looks like a reference -- Missing reference section? 'SQL92' on line 5420 looks like a reference -- Missing reference section? 'SQLCOM' on line 5423 looks like a reference -- Missing reference section? 'NOT' on line 1900 looks like a reference -- Missing reference section? 'CHARREG' on line 5382 looks like a reference -- Missing reference section? 'CHARPOL' on line 5386 looks like a reference -- Missing reference section? 'SASL' on line 5416 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Royer 3 Internet-Draft INET-Consulting 4 Expires: May 4, 2003 G. Babics 5 Oracle 6 P. Hill 7 Massachusetts Institute of 8 Technology 9 S. Mansour 10 AOL/Netscape 11 November 3, 2002 13 Calendar Access Protocol (CAP) 14 draft-ietf-calsch-cap-09.txt 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 http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 4, 2003. 39 Copyright Notice 41 Copyright (C) The Internet Society (2002). All Rights Reserved. 43 Abstract 45 The Calendar Access Protocol (CAP) is an Internet protocol described 46 in this memo that permits a Calendar User (CU) to utilize a Calendar 47 User Agent (CUA) to access an [iCAL] based Calendar Store (CS). 49 The CAP definition is based on requirements identified by the 50 Internet Engineering Task Force (IETF) Calendaring and Scheduling 51 (CALSCH) Working Group. More information about the IETF CALSCH 52 Working Group activities can be found on the IMC web site at http:// 53 www.imc.org/ietf-calendar and at the IETF web site at http:// 54 www.ietf.org/html.charters/calsch-charter.html [1]. Refer to the 55 references within this memo for further information on how to access 56 these various documents. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 61 1.1 Formatting Conventions . . . . . . . . . . . . . . . . . 5 62 1.2 Related Documents . . . . . . . . . . . . . . . . . . . 6 63 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . 7 64 2. Additions to iCalendar . . . . . . . . . . . . . . . . . 12 65 2.1 New Value Types (summary) . . . . . . . . . . . . . . . 13 66 2.1.1 New Parameters (summary) . . . . . . . . . . . . . . . . 14 67 2.1.2 New Properties (summary) . . . . . . . . . . . . . . . . 15 68 2.1.3 New Components (summary) . . . . . . . . . . . . . . . . 17 69 2.2 Relationship of RFC-2446 (ITIP) and CAP . . . . . . . . 18 70 3. CAP Design . . . . . . . . . . . . . . . . . . . . . . . 20 71 3.1 System Model . . . . . . . . . . . . . . . . . . . . . . 20 72 3.2 Calendar Store Object Model . . . . . . . . . . . . . . 20 73 3.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 21 74 3.3.1 Use of BEEP, MIME and iCalendar . . . . . . . . . . . . 22 75 4. Security Model . . . . . . . . . . . . . . . . . . . . . 24 76 4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 24 77 4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . . . 24 78 4.1.2 Anonymous Users and Authentication . . . . . . . . . . . 25 79 4.1.3 User Groups . . . . . . . . . . . . . . . . . . . . . . 25 80 4.2 Access Rights . . . . . . . . . . . . . . . . . . . . . 26 81 4.2.1 Access Control and NOCONFLICT . . . . . . . . . . . . . 26 82 4.2.2 Calendar Access Right (VCAR) . . . . . . . . . . . . . . 26 83 4.2.3 Predefined VCARs . . . . . . . . . . . . . . . . . . . . 27 84 4.2.4 Decreed VCARs . . . . . . . . . . . . . . . . . . . . . 28 85 4.3 CAP Session Identity . . . . . . . . . . . . . . . . . . 29 86 5. CAP URL and Calendar Address . . . . . . . . . . . . . . 31 87 6. New Value Types . . . . . . . . . . . . . . . . . . . . 33 88 6.1 Property Value Data Types . . . . . . . . . . . . . . . 33 89 6.1.1 CAL-QUERY Value Type . . . . . . . . . . . . . . . . . . 33 90 6.1.1.1 [NOT] CAL-OWNERS() . . . . . . . . . . . . . . . . . . . 38 91 6.1.1.2 CURRENT-TARGET() . . . . . . . . . . . . . . . . . . . . 39 92 6.1.1.3 PARAM() . . . . . . . . . . . . . . . . . . . . . . . . 39 93 6.1.1.4 SELF() . . . . . . . . . . . . . . . . . . . . . . . . . 39 94 6.1.1.5 STATE() . . . . . . . . . . . . . . . . . . . . . . . . 40 95 6.1.1.6 Ordering of Results . . . . . . . . . . . . . . . . . . 40 96 6.1.1.7 Date sorting order . . . . . . . . . . . . . . . . . . . 40 97 6.1.1.8 Use of single quote . . . . . . . . . . . . . . . . . . 41 98 6.1.1.9 Comparing DATE and DATE-TIME values . . . . . . . . . . 41 99 6.1.1.10 DTEND and DURATION . . . . . . . . . . . . . . . . . . . 42 100 6.1.1.11 [NOT] LIKE . . . . . . . . . . . . . . . . . . . . . . . 44 101 6.1.1.12 Empty vs. NULL . . . . . . . . . . . . . . . . . . . . . 45 102 6.1.1.13 [NOT] IN . . . . . . . . . . . . . . . . . . . . . . . . 45 103 6.1.1.14 DATE-TIME and TIME values in a WHEN clause . . . . . . . 46 104 6.1.1.15 Multiple contained components . . . . . . . . . . . . . 47 105 6.1.1.16 Example, Query by UID . . . . . . . . . . . . . . . . . 47 106 6.1.1.17 Query by Date-Time range . . . . . . . . . . . . . . . . 48 107 6.1.1.18 Query for all Unprocessed Entries . . . . . . . . . . . 48 108 6.1.1.19 Query with Subset of Properties by Date/Time . . . . . . 49 109 6.1.1.20 Query with Components and Alarms In A Range . . . . . . 49 110 6.1.2 UPN Value Type . . . . . . . . . . . . . . . . . . . . . 50 111 6.1.3 UPN-FILTER Value . . . . . . . . . . . . . . . . . . . . 51 112 7. New Parameters . . . . . . . . . . . . . . . . . . . . . 53 113 7.1 ENABLE Parameter . . . . . . . . . . . . . . . . . . . . 53 114 7.2 LOCAL Parameter . . . . . . . . . . . . . . . . . . . . 53 115 8. New Properties . . . . . . . . . . . . . . . . . . . . . 55 116 8.1 ALLOW-CONFLICT Property . . . . . . . . . . . . . . . . 55 117 8.2 ATT-COUNTER Property . . . . . . . . . . . . . . . . . . 55 118 8.3 CALID Property . . . . . . . . . . . . . . . . . . . . . 56 119 8.4 CALMASTER Property . . . . . . . . . . . . . . . . . . . 57 120 8.5 CARID Property . . . . . . . . . . . . . . . . . . . . . 57 121 8.6 CSID Property . . . . . . . . . . . . . . . . . . . . . 58 122 8.7 DECREED Property . . . . . . . . . . . . . . . . . . . . 59 123 8.8 DEFAULT-CHARSET Property . . . . . . . . . . . . . . . . 59 124 8.9 DEFAULT-LOCALE Property . . . . . . . . . . . . . . . . 60 125 8.10 DEFAULT-TZID Property . . . . . . . . . . . . . . . . . 61 126 8.11 DEFAULT-VCARS Property . . . . . . . . . . . . . . . . . 62 127 8.12 DENY Property . . . . . . . . . . . . . . . . . . . . . 63 128 8.13 EXPAND property . . . . . . . . . . . . . . . . . . . . 63 129 8.14 GRANT Property . . . . . . . . . . . . . . . . . . . . . 64 130 8.15 MAXDATE Property . . . . . . . . . . . . . . . . . . . . 65 131 8.16 MINDATE Property . . . . . . . . . . . . . . . . . . . . 65 132 8.17 MULTIPART Property . . . . . . . . . . . . . . . . . . . 66 133 8.18 NAME Property . . . . . . . . . . . . . . . . . . . . . 67 134 8.19 OWNER Property . . . . . . . . . . . . . . . . . . . . . 68 135 8.20 PERMISSION Property . . . . . . . . . . . . . . . . . . 69 136 8.21 QUERY property . . . . . . . . . . . . . . . . . . . . . 69 137 8.22 QUERYID property . . . . . . . . . . . . . . . . . . . . 70 138 8.23 REQUEST-STATUS property . . . . . . . . . . . . . . . . 71 139 8.24 RESTRICTION Property . . . . . . . . . . . . . . . . . . 72 140 8.25 SCOPE Property . . . . . . . . . . . . . . . . . . . . . 73 141 8.26 TARGET Property . . . . . . . . . . . . . . . . . . . . 73 142 8.27 TRANSP Property . . . . . . . . . . . . . . . . . . . . 74 143 9. New Components . . . . . . . . . . . . . . . . . . . . . 76 144 9.1 VAGENDA Component . . . . . . . . . . . . . . . . . . . 76 145 9.2 VCALSTORE Component . . . . . . . . . . . . . . . . . . 78 146 9.3 VCAR Component . . . . . . . . . . . . . . . . . . . . . 81 147 9.4 VRIGHT Component . . . . . . . . . . . . . . . . . . . . 84 148 9.5 VREPLY Component . . . . . . . . . . . . . . . . . . . . 85 149 9.6 VQUERY Component . . . . . . . . . . . . . . . . . . . . 85 150 10. Commands and Responses . . . . . . . . . . . . . . . . . 87 151 10.1 CAP Commands (CMD) . . . . . . . . . . . . . . . . . . . 87 152 10.1.1 Bounded Latency . . . . . . . . . . . . . . . . . . . . 88 153 10.1.2 ABORT Command . . . . . . . . . . . . . . . . . . . . . 91 154 10.1.3 CONTINUE Command . . . . . . . . . . . . . . . . . . . . 92 155 10.1.4 CREATE Command . . . . . . . . . . . . . . . . . . . . . 93 156 10.1.5 DELETE Command . . . . . . . . . . . . . . . . . . . . . 99 157 10.2 GENERATE-UID Command . . . . . . . . . . . . . . . . . . 102 158 10.3 GET-CAPABILITY Command . . . . . . . . . . . . . . . . . 104 159 10.4 IDENTIFY Command . . . . . . . . . . . . . . . . . . . . 108 160 10.5 MODIFY Command . . . . . . . . . . . . . . . . . . . . . 111 161 10.6 MOVE Command . . . . . . . . . . . . . . . . . . . . . . 115 162 10.7 REPLY Response to a Command . . . . . . . . . . . . . . 118 163 10.8 SEARCH Command . . . . . . . . . . . . . . . . . . . . . 119 164 10.9 SET-LOCALE Command . . . . . . . . . . . . . . . . . . . 122 165 10.10 TIMEOUT Command . . . . . . . . . . . . . . . . . . . . 124 166 10.11 Response Codes . . . . . . . . . . . . . . . . . . . . . 125 167 11. Object Registration . . . . . . . . . . . . . . . . . . 128 168 11.1 Registration of New and Modified Entities . . . . . . . 128 169 11.2 Post the item definition . . . . . . . . . . . . . . . . 128 170 11.3 Allow a comment period . . . . . . . . . . . . . . . . . 128 171 11.4 Release a new RFC . . . . . . . . . . . . . . . . . . . 128 172 12. BEEP and CAP . . . . . . . . . . . . . . . . . . . . . . 129 173 12.1 BEEP Profile Registration . . . . . . . . . . . . . . . 129 174 12.2 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 129 175 13. IANA Considerations . . . . . . . . . . . . . . . . . . 130 176 14. Security Considerations . . . . . . . . . . . . . . . . 131 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . 132 178 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . 134 179 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . 135 180 Full Copyright Statement . . . . . . . . . . . . . . . . 137 182 1. Introduction 184 This document specifies how a Calendar CUA interacts with a CS to 185 manage calendar information. In particular, it specifies how to 186 query, create, modify, and delete iCalendar components (e.g., events, 187 to-dos, or daily journal entries). It further specifies how to 188 search for available busy time information. Synchronization with 189 CUAs is not covered. 191 CAP is specified as a BEEP "profile". As such, many aspects of the 192 protocol (e.g., authentication and privacy) are provided within 193 [BEEP]. The protocol data units leverage the standard iCalendar 194 format [iCAL] to convey calendar related information. 196 CAP can also be used to store and fetch [iTIP] objects and when those 197 objects are used in this memo, they mean exactly the same as defined 198 in [iTIP]. When iCalendar objects are transfered between the CUA and 199 a CS, some additional properties and parameters may be added and the 200 CUA is responsible for correctly generating iCalendar objects to non 201 CAP processes. 203 The definition of new components, properties, parameter's, and value 204 types are broken into two parts. The first part summarizes and 205 defined the new objects. The second part provides the detail and any 206 ABNF for those objects. 208 1.1 Formatting Conventions 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 212 document are to be interpreted as described in [RFCWORDS]. 214 Calendaring and scheduling roles are referred to in quoted-strings of 215 text with the first character of each word in upper case. For 216 example, "Organizer" refers to a role of a "Calendar User" (CU) 217 within the protocol defined by [iTIP]. Calendar components defined 218 by [iCAL] are referred to with capitalized, quoted-strings of text. 219 All iCalendar components should start with the letter "V". For 220 example, "VEVENT" refers to the event calendar component, "VTODO" 221 refers to the to-do component and "VJOURNAL" refers to the daily 222 journal component. 224 Scheduling methods defined by [iTIP], are referred to with 225 capitalized, quoted-strings of text. For example, "REPLY" refers to 226 the method for replying to a "REQUEST". 228 CAP commands are referred to by upper-case, quoted-strings of text, 229 followed by the word "command". For example, "CREATE" command refers 230 to the command for creating a calendar entry, "SEARCH" command refers 231 to the command for reading calendar components. CAP Commands are 232 named using the "CMD" property. 234 Properties defined by this memo are referred to with capitalized, 235 quoted-strings of text, followed by the word "property". For 236 example, "ATTENDEE" property refers to the iCalendar property used to 237 convey the calendar address that has been invited to a "VEVENT" or 238 "VTODO" component. 240 Property parameters defined by this memo are referred to with 241 capitalized, quoted-strings of text, followed by the word 242 "parameter". For example, "PARTSTAT" parameter refers to the 243 iCalendar property parameter used to specify the participation status 244 of an attendee. Enumerated values defined by this memo are referred 245 to with capitalized text, either alone or followed by the word 246 "value". 248 Object states defined by this memo are referred to with capitalized, 249 quoted-strings of text, followed by the word "state". For example, 250 "BOOKED" state refers to an object in the booked state. 252 Within a query, the different parts are referred to as a "clause" and 253 its value as "clause value" and the clause name will be in uppercase 254 enclosed in quotes. Example, The "SELECT" clause or if the "SELECT" 255 clause value contains ... 257 In tables, the quoted-string text is specified without quotes in 258 order to minimize the table length. 260 1.2 Related Documents 262 Implementers will need to be familiar with several other memos that, 263 along with this one, describe the Internet calendaring and scheduling 264 standards. These documents are: 266 [iCAL] - (RFC2445) Which specifies the objects, data types, 267 properties and property parameters used in the protocols, along 268 with the methods for representing and encoding them. 270 [iTIP] - (RFC2446) Which specifies an interoperability protocol for 271 scheduling between different installations. 273 [iMIP] - (RFC2447) Which specifies the Internet email binding for 274 [iTIP]. 276 [GUIDE] - (RFC3283), a guide to implementers and describes the 277 elements of a calendaring system, how they interact with each 278 other, how they interact with end users, and how the standards and 279 protocols are used. 281 This memo does not attempt to repeat the specification of concepts 282 and definitions from these other memos. Where possible, references 283 are made to the memo that provides for the specification of these 284 concepts and definitions. 286 1.3 Definitions 288 BOOKED - An obect in the calendar store has one of three conceptual 289 states. It is "UNPROCESSED" state, "BOOKED" state or marked as 290 "DELETED" state. How the implementation stores the state of any 291 object is not a protocol issues and is not discussed. An object 292 can be said to be booked, unprocessed, or marked for delete. 294 1. An "UNPROCESSED" state scheduling object has been stored in 295 the calendar store but has not been acted on by a CU or CUA. 296 All scheduled entries are [iTIP] objects. All [iTIP] objects 297 in the store are not in the "BOOKED" state. To retrieve any 298 [iTIP] object, simply do a query asking for any objects that 299 were stored in the "UNPROCESSED" state. 301 2. A "BOOKED" state entry is stored with the "CREATE" command. 302 It is an object that has been acted on by a CU or CUA and 303 there has been a decision to store an object. To retrieve any 304 booked object, simply do a query asking for any objects that 305 were stored in the "BOOKED" state. 307 3. A "DELETED" state entry is created by sending a "DELETE" 308 command with the "OPTION" parameter value set to "MARK". To 309 retrieve any deleted object, simply do a query asking for any 310 objects that were stored in the "DELETED" state. By default 311 objects marked for delete are not returned. The CUA must 312 specifically ask for marked for delete objects. You can not 313 ask for components in the "DELETED" state and in other states 314 in the same "VQUERY" component, as there would be no way to 315 distinguish between them in the reply. 317 Calendar - A collection of logically related objects or entities 318 each of which may be associated with a calendar date and possibly 319 time of day. These entities can include calendar properties or 320 components. In addition, a calendar might be related to other 321 calendars with the "RELATED-TO" property. A calendar is 322 identified by its unique calendar identifier. The [iCAL] defines 323 the initial calendar properties, calendar components and 324 properties that make up the contents of a calendar. 326 Calendar Access Protocol (CAP) - The standard Internet protocol that 327 permits a CUA to access and manipulate calendars residing on a 328 Calendar Store. (this memo) 330 Calendar Access Rights (VCAR) - The mechanism for specifying the CAP 331 operations ("PERMISSION") that a particular calendar user ("UPN") 332 is granted or denied permission to perform on a given calendar 333 object ("SCOPE"). The calendar access rights are specified with a 334 "VCAR" component. 336 Calendar Address - Also See Calendar URL - they are one in the same 337 for CAP addresses. The calendar address can also be the value to 338 the "ATTENDEE" and "ORGANIZER" properties as defined in [iCAL]. 340 Calendar URL - A calendar URL is a URL defined in this memo that 341 specifies the address of a CS or Calendar. 343 Component- Any object that conforms to the iCalendar object format 344 and that is either defined in an internet draft, registered with 345 IANA, or is an experimental object that is prefixed with "x-". 346 Some types of components include calendars, events, to-dos, 347 journals, alarms, and time zones. A component consists of 348 properties and possibly other contained components. For example, 349 an event may contain an alarm component. 351 Container - This is a generic name for VCALSTORE or VAGENDA. 353 Properties - An attribute of a particular component. Some 354 properties are applicable to different types of components. For 355 example, the "DTSTART" property is applicable to the "VEVENT", 356 "VTODO", and "VJOURNAL" components. Other components are 357 applicable only to an individual type of calendar component. For 358 example, the "TZURL" property may only be applicable to the 359 "VTIMEZONE" components. 361 Calendar Identifier (CalID) - A globally unique identifier 362 associated with a calendar. Calendars reside within a CS. See 363 Qualified Calendar Identifier and Relative Calendar Identifier. 364 All CalIDs start with "cap:". 366 Calendar Policy - A CAP operational restriction on the access or 367 manipulation of a calendar. These may be outside of the scope of 368 the CAP protocol. An example of an implementation or site policy 369 is, "events MUST BE scheduled in unit intervals of one hour". 371 Calendar Property - An attribute of a calendar ("VAGENDA"). The 372 attribute applies to the calendar, as a whole. For example, the 373 "CALSCALE" property specifies the calendar scale (e.g., the 374 "GREGORIAN" value) for the all entries within the calendar. 376 Calendar Store (CS) - The data and service model definition for a 377 Calendar Store as defined in this memo. This memo does not 378 specify how the CS is implemented. 380 Calendar Server - An implementation of a Calendar Store (CS) that 381 manages one or more calendars. 383 Calendar Store Identifier (CSID) - The globally unique identifier 384 for an individual CS. A CSID consists of the host and port 385 portions of a "Common Internet Scheme Syntax" part of a URL, as 386 defined by [URL]. The CSID excludes any reference to a specific 387 calendar. 389 Calendar Store Components - Components maintained in a CS specify a 390 grouping of calendar store-wide information. 392 Calendar Store Properties - Properties maintained in a Calendar 393 Store calendar store-wide information. 395 Calendar User (CU) - An entity (often biological) that uses a 396 calendaring system. 398 Calendar User Agent (CUA) - The client application that a CU 399 utilizes to access and manipulate a calendar. 401 CAP Session - An open communication channel between a CUA and a 402 Calendar Server. If the CAP session is authenticated, the CU is 403 "authenticated" and it is an "authenticated CAP session". 405 Contained Component / Contained Properties - A component or property 406 that is contained inside of another component. A "VALARM" 407 component for example may be contained inside of a "VEVENT" 408 component. And a "TRIGGER" property could be a contained property 409 of a "VALARM" component. 411 Delegate - A CU (sometimes called the delegatee) who has been 412 assigned participation in a scheduled component (e.g., VEVENT) by 413 one of the attendees in the scheduled component (sometimes called 414 the delegator). An example of a delegate is a team member told to 415 go to a particular meeting in place of another Attendee who is 416 unable to attend. 418 Designate - A CU who is authorized to act on behalf of another CU. 419 An example of a designate is an assistant. 421 Experiential - The CUA and CS may implement experimental extensions 422 to the protocol. They also might have experimental components, 423 properties, and parameters. These extensions MUST start with "x-" 424 (or "X-") and should include a vendor prefix (such as "x-myvendor- 425 "). There is no guarantee that these experimental extensions will 426 interoperate with other implementations. There is no guarantee 427 that they will not interact in unpredictable ways with other 428 vendor experimental extensions. Implementations should limit 429 sending those extensions to other implementations. 431 Object - A generic name for any component, property, parameter, or 432 value type to be used in iCalendar. 434 Overlapped Booking - A policy which indicates whether or not 435 components with a "TRANSP" property not set to "TRANSPARENT- 436 NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap one another. 437 When the policy is applied to a calendar it indicates whether or 438 not the time span of any component (VEVENT, VTODO, ...) in the 439 calendar can overlap the time span of any other component in the 440 same calendar. When applied to an individual object, it indicates 441 whether or not any other component's time span can overlap that 442 individual component. If the CS does not allow overlapped 443 booking, then the CS is unwilling to allow any overlapped bookings 444 within any calendar in the CS. 446 Owner - One or more CUs or UGs that are listed in the "OWNER" 447 property in a calendar. There can be more than one owner. The " 449 Qualified Calendar Identifier (Qualified CalID) - A CalID in which 450 both the scheme and csid of the CAP URI are present. 452 Realm - A collection of calendar user accounts, identified by a 453 string. The name of the Realm is only used in UPNs. In order to 454 avoid namespace conflict, the Realm SHOULD be postfixed with an 455 appropriate DNS domain name. (e.g., the foobar Realm could be 456 called foobar.example.com). 458 Relative Calendar Identifier (Relative CalID) - An identifier for an 459 individual calendar in a calendar store. It MUST BE unique within 460 a calendar store. A Relative CalID consists of the "URL path" of 461 the "Common Internet Scheme Syntax" portion of a URL, as defined 462 by [URI] and [URLGUIDE]. 464 Session Identity - A UPN associated with a CAP session. A session 465 gains an identity after successful authentication. The identity 466 is used in combination with VCAR to determine access to data in 467 the CS. 469 User Group (UG) - A collection of Calendar Users and/or User Groups. 470 These groups are expanded by the CS and may reside either locally 471 or in an external database or directory. The group membership may 472 be fixed or dynamic over time. 474 Username - A name which denotes a Calendar User within a Realm. 475 This is part of a UPN. 477 User Principal Name (UPN) - A unique identifier that denotes a CU or 478 a group of CU. A UPN is a RFC 822 compliant email address, with 479 exceptions listed below, and in most cases it is deliverable to 480 the CU. In some cases it is identical to the CU's well known 481 email address. A CU's UPN MUST never be an e-mail address that is 482 deliverable to a different person as there is no requirement that 483 a person's UPN MUST BE their e-mail address. A UPN is formatted 484 as a user name followed by "@" followed by a Realm in the form of 485 a valid, and unique, DNS domain name. The user name MUST BE 486 unique within the Realm. In it's simplest form it looks like 487 "user@example.com". 489 In certain cases a UPN will not be RFC 822 compliant. When 490 anonymous authentication is used, or anonymous authorization is 491 being defined, the special UPN "@" will be used. When 492 authentication MUST BE used, but unique identity MUST BE obscured, 493 a UPN of the form @DNS-domain-name may be used. For example, 494 "@example.com". 496 2. Additions to iCalendar 498 Several new components, properties, parameters, and value types are 499 added in CAP. This section summarizes those new objects. 501 This memo extends the properties that can go into 'calprops' as 502 defined in [iCAL] section 4.6 page 51 to allow [iTIP] objects 503 transmitted between a CAP aware CUA and the CS to contain the 504 "TARGET" and "CMD" properties. This memo does not address how a CUA 505 transmits [iTIP] or [iMIP] objects to non CAP programs. 507 calprops = 2*( 509 ; 'prodid' and 'version' are both REQUIRED, 510 ; but MUST NOT occur more than once. 511 ; 512 prodid /version / 514 ; These are optional, but MUST NOT occur 515 ; more than once. 516 ; 517 calscale / 518 method / 519 cmd / 521 ; These are optional, and may occur more 522 ; than once. 523 ; 524 target / 525 iana-prop / 526 x-prop 528 Another change is that the 'component' part of the 'icalbody' ABNF as 529 described in [iCAL] section 4.6 is optional when sending a command as 530 shown in the following updated ABNF: 532 icalbody = calprops component 534 ; If the "VCALENDAR" component contains the "CMD" 535 ; component then the 'component' is optional: 536 ; 537 / calprops ; Which MUST include a "CMD" property 539 In addition a problem exists with the control of "VALARM" components 540 and their "TRIGGER" properties. A CU may wish to set their own alarm 541 (local alarms) on components. These local alarms are not to be 542 forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property 543 and the "ENABLE" parameter. So for the protocol between a CUA and a 544 CS, the following changes apply to the CAP protocol from [iCAL] 545 section "4.6.6" page 67: 547 alarmc = "BEGIN" ":" "VALARM" CRLF 548 alarm-seq 549 iana-prop 550 (audioprop / dispprop / emailprop / procprop) 551 "END" ":" "VALARM" CRLF 553 alarm-seq = "SEQUENCE" alarmseqparam ":" integer CRLF 555 alarmseqparam = *( ";" xparam) 556 / ";" local-param 558 The CUA adds a "SEQUENCE" property to each "VALARM" component as it 559 books the component. This property along with the "LOCAL" and 560 "ENABLE" parameters allow the CUA to uniquely identify any VALARM in 561 any component. The CUA should remove those before forwarding to non 562 CAP aware CUAs (including [iMIP] CUAs). 564 In addition, if a CUA wished to ignore a "TRIGGER" property in a 565 "VALARM" component that was supplied to it by the "Organizer", the 566 CUA needs a common way to tag that trigger as disabled. So for the 567 protocol between a CUA and a CS, the following is a modification to 568 [iCAL] section "4.8.6.3" page 127: 570 trigger = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs) 572 Section 7.1 and Section 7.2. 574 These additions will be transmitted between a CS and a CAP aware CUA. 575 So the "VERSION" value will remain at "2.0" as no existing [iTIP] or 576 [iMIP] implementation will be effected. 578 2.1 New Value Types (summary) 580 UPN The UPN value type is text value type restricted to only UPN 581 values. (Section 6.1.2) 583 UPN-FILTER Like the UPN value type, but also includes filter rules 584 that allow wildcards. (Section 6.1.3) 586 CALQUERY The "CAL-QUERY" (Section 6.1.1) value type is a query syntax 587 that is used by the CUA to specify the rules that apply to a CAP 588 command. In the case of "SEARCH" command the query language is 589 used to fetch objects from the CS. When used with the "DELETED" 590 command, the selected objects are deleted from the CS. "CAL- 591 QUERY" value type can also be used with "MOVE" and "MODIFY" 592 commands. 594 2.1.1 New Parameters (summary) 596 ENABLE - 598 The "ENABLE" parameter in CAP is used to tag a "TRIGGER" property 599 in a component as disabled or enabled. This is used when a 600 scheduling request arrives and the CU wishes to ignore the trigger 601 time included. (Section 7.1). 603 Formal Definition: The "ENABLE" parameter is defined by the 604 following notation: 606 enable-param = "ENABLE" "=" ("TRUE" / "FALSE") 608 LOCAL - 610 The "LOCAL" parameter in CAP is used to tag a "SEQUENCE" property 611 in a "VALARM" component to signify that a VALARM is local or to be 612 distributed. (Section 7.2). 614 For example, when inviting others to an event, the "Organizer's" 615 booked "VEVENT" component might contain "VALARM" components, and 616 those "VALARM" component might be 'alarm be 5 minutes before the 617 meeting'. However other "Attendees" may have to set their own 618 "VALARM" components for the same event (assuming they reply that 619 they will be attending). So, by tagging the "VALARM" component as 620 local the CUA MUST never forward those local "VALARM" components 621 to other CS's or CUAs. 623 The CUA can not simply delete any "VALARM components where the CU 624 is not the "Organizer". If it did, any [iTIP] "COUNTER" method 625 would result in the "Organizer" thinking that the "Attendee" 626 wished to also counter with removing those "VALARM" components. 627 And in addition, any update to an existing component would re- 628 create those "VALARM" components in the "Attendees" CS. 630 Formal Definition: The "LOCAL" parameter is defined by the 631 following notation: 633 local-param = "LOCAL" "=" ("TRUE" / "FALSE") 635 2.1.2 New Properties (summary) 637 ALLOW-CONFLICT - Some entries in a calendar might not be valid if 638 other entries were allowed to overlap the same time span. Renting 639 a car for example. It would not make sense to allow two 640 reservations for the same car at the same time. The "ALLOW- 641 CONFLICT" property takes a boolean value. If FALSE, then 642 conflicts are not allowed. (Section 8.1) 644 ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" 645 method, there needs to be a way to remember who sent the COUNTER. 646 The ATT-COUNTER property MUST BE added to all "COUNTER" [iTIP] 647 components by the CUA before storing in a CS. (Section 8.2) 649 CSID - Each CS needs its own unique identifier. The "CSID" property 650 is the official unique identifier for the CS. If the BEEP 651 'serverName' attribute was supplied in the BEEP 'start' message, 652 then the CSID will be mapped to the virtual host name supplied and 653 the host name part of the CSID MUST BE the same as the 654 'serverName' value. This allows one CS implementation to service 655 multiple virtual hosts. CS's are not required to support virtual 656 hosting. If a CS does not support virtual hosting then it must 657 ignore the BEEP 'serverName' attribute. (Section 8.6) 659 CALID - Each calendar within a CS needs to be uniquely identifiable. 660 The "CALID" property identifies a unique calendar within a CS. It 661 can be a full CALID or a relative CALID. (Section 8.3) 663 CALMASTER - The "CALMASTER" property specifies the contact 664 information for the CS. (Section 8.4) 666 CARID - Access rights can be saved and fetched by unique ID - the 667 "CARID" property. (Section 8.5) 669 CMD - The CAP commands, as well as replies are transmitted using the 670 "CMD" property. (Section 10.1) 672 DECREED - Some access rights are not changeable by the CUA. When 673 that is the case, the "DECREED" property value in the "VCAR" 674 component will be TRUE. (Section 8.7) 676 DEFAULT-CHARSET - The list of charsets supported by the CS. The 677 first entry MUST BE the default for the CS. (Section 8.8) 679 DEFAULT-LOCALE - The list of locales supported by the CS. The first 680 entry in the list is the default locale. (Section 8.9) 682 DEFAULT-TZID - This is the list of known timezones supported. The 683 first entry is the default. (Section 8.10) 685 DEFAULT-VCARS - A list of the "CARID" properties that will be used 686 to create new calendars. (Section 8.11) 688 DENY - The UPNs listed in the "DENY" property of a "VCAR" component 689 will denied access as described in the "VRIGHT" component. 690 (Section 8.12) 692 EXPAND - This property tells the CS if the query reply should expand 693 components into multiple instances. The default is FALSE. 694 (Section 8.13) 696 GRANT - The UPNs listed in the "GRANT" property of a "VCAR" 697 component will allowed access as described in the "VRIGHT" 698 component. (Section 8.14) 700 MAXDATE - The maximum date supported by the CS. (Section 8.15) 702 MINDATE - The minimum date supported by the CS. (Section 8.16) 704 MULTIPART - Passed in the capability messages to indicate which MIME 705 multipart types the sender supports. (Section 8.17) 707 NAME - Several storeable components such as "VCAR" and "VQUERY" may 708 have the "NAME" property contained in them to describe in various 709 locals the purpose of the component. Components may have multiple 710 "NAME" properties each with a unique "LANGUAGE" parameter. 711 (Section 8.18) 713 OWNER - Each calendar has at least one "OWNER" property. (xref 714 target="OWNER"/>) Related to the "CAL-OWNERS()" (Section 6.1.1.1) 715 query clause. 717 PERMISSION - This property specifies the permission being granted or 718 denied. Examples are the "SEARCH" and "MODIFY" values. (Section 719 8.20) 721 QUERY - Used to hold the CAL-QUERY (Section 8.21) for the component. 723 QUERYID - A unique id for a stored query. (Section 8.22) 724 REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to 725 include new error numbers. (Section 8.23) 727 RESTRICTION - In the final check when granting calendar access 728 requests, the CS test the results to the value of the 729 "RESTRICTION" property in the corresponding "VRIGHT" component to 730 determine if the access meets that restriction. (Section 8.24) 732 SCOPE - The "SCOPE" property is used in "VRIGHT"s component to 733 select the subset of data that may be acted upon when checking 734 access rights. (Section 8.25) 736 TARGET - The new "VCALENDAR" component property "TARGET" (Section 737 8.26) is used to specify which calendar(s) will be the subject of 738 the CAP command. 740 TRANSP - This is a modification the [iCAL] "TRANSP" property and it 741 allows more values. The new values are related to conflict 742 control. (Section 8.27) 744 2.1.3 New Components (summary) 746 VAGENDA - CAP allows the fetching and storing of the entire contents 747 of a calendar. The "VCALENDAR" component is not sufficient to 748 encapsulate all of the needed data that describes a calendar. The 749 "VAGENDA" component is the encapsulating object for an entire 750 calendar. (Section 9.1) 752 VCALSTORE - Each CS contains one or more calendars (VAGENDAs), the 753 "VCALSTORE" component is the encapsulating object that can hold 754 all of the "VAGENDA" components along with any components and 755 properties that are unique to the store level. (Section 9.2) 757 VCAR - Calendar Access Rights are specified and encapsulated in the 758 new iCalendar "VCAR" (Section 9.3) component. The "VCAR" 759 component holds some new properties and at least one "VRIGHT" 760 component. 762 VRIGHT - (Section 9.4) This component encapsulates a set of 763 instructions to the CS that define the rights or restrictions 764 needed. 766 VREPLY - (Section 9.5) This component encapsulates a set of data 767 that can consist of an arbitrary amounts of properties and 768 components. Its contents is dependent on the command that was 769 issued. 771 VQUERY - The search operation makes use of a new component, called 772 "VQUERY" (Section 9.6) and a new value type "CAL-QUERY" (Section 773 6.1.1). The "VQUERY" component is used to fetch objects from the 774 CS. 776 2.2 Relationship of RFC-2446 (ITIP) and CAP 778 [iTIP] describes scheduling methods which result in indirect 779 manipulation of components. In CAP, the "CREATE" command is used to 780 deposit entities into the store. Other CAP commands such as 781 "DELETE", "MODIFY" and "MOVE" command values provide direct 782 manipulation of components. In the CAP calendar store model, 783 scheduling messages are conceptually kept separate from other 784 components by their state. 786 All scheduling operations and are as define in [iTIP]. This memo 787 makes no changes to any of the workflow described in [iTIP]. In this 788 memo referring to the presence of the "METHOD" property in an object 789 is the same as saying an [iTIP] object. 791 A CUA may create a "BOOKED" state object by depositing a iCalendar 792 object into the store. This is done by depositing an object that 793 does not have a "METHOD" property. The CS then knows to set the 794 state of the object to the "BOOKED" state. If the object has a 795 "METHOD" property then the object is stored in the "UNPROCESSED" 796 state. 798 If existing "UNPROCESSED" state objects exist in the CS for the same 799 UID then a CUA may wish to consolidate the objects in to one "BOOKED" 800 state object. The CUA would fetch the "UNPROCESSED" state objects 801 for that UID and process them in the CUA as described in [iTIP]. 802 Then if the CUA wished to book the UID, the CUA would issue a 803 "CREATE" command to create the new "BOOKED" state object in the CS, 804 followed by a "DELETE" command to remove any related old [iTIP] 805 objects from the CS. And it might also involve having the CUA send 806 some [iMIP] objects or contacting other CS's and performing CAP 807 operations on those CSs. 809 The CUA could also decide not to book the object. In which case the 810 "UNPROCESSED" state objects could be removed from the CS or the CUA 811 could set those object to the marked for delete state. The CUA could 812 also ignore objects for later processing. 814 The marked for delete state is used to keep the object around so that 815 the CUA can process duplicate requests automatically. If a duplicate 816 [iTIP] object is deposited into the CS and there exists identical 817 marked for delete objects, then a CUA acting on behalf of the "OWNER" 818 can silently drop those duplicate entries. 820 Another purpose for the marked for delete state is so that when a CU 821 decides they do not wish to have the object show in their calendar, 822 the CUA can book the object; changing the "PARTSTAT" parameter to 823 "DECLINED" in the "ATTENDEE" property that corresponds to their UPN. 824 Perform an [iTIP] processing such as sending back a decline. Then 825 mark that object as marked for delete. Their CUA might be 826 configurable to automatically drop any updates for that object 827 knowing the CU has already declined. 829 When synchronizing with multiple CUAs, the marked for delete state 830 could be used to inform the synchronization process that an object is 831 to be deleted. How synchronization is done is not specified in this 832 memo. 834 Several "UNPROCESSED" state entries can be in the CS for the same 835 UID. However once consolidated, then only one object exists in the 836 CS and that is the booked object. The others MUST BE removed, or 837 have their state changed to "DELETED". 839 There MUST NOT BE more than one "BOOKED" state object in a calendar 840 for the same "UID". The "ADD" method value may create multiple 841 objects all in the "BOOKED" state for the same UID, however for the 842 purpose of this memo, they are the same object that simply have 843 multiple "VCALENDAR" components. 845 For example, if you were on vacation, you could have receive a 846 "REQUEST" method to attend a meeting and several updates to that 847 meeting. Your CUA would have to issue "SEARCH" commands to find them 848 in the CS using CAP, process them, determine what the final state of 849 the object from a possible combination of user input and programmed 850 logic. Then the CUA would instruct the CS to create a new booked 851 object from the consolidated results. Finally, the CUA could do a 852 "DELETE" command to remove the related "UNPROCESSED" state objects. 853 See [iTIP] for details on resolving multiple [iTIP] scheduling 854 entries. 856 3. CAP Design 858 3.1 System Model 860 The system model describes the high level components of a calendar 861 system and how they interact with each other. 863 CAP is used by a CUA to send commands to and receive responses from a 864 CS. 866 The CUA prepares a [MIME] encapsulated command, sends it to the CS, 867 and receives a [MIME] encapsulated response. The calendaring related 868 information within these messages are represented by iCalendar 869 objects. In addition the "GET-CAPABIBILITY" command can be sent from 870 the CS to the CUA. 872 There are two distinct protocols in operation to accomplish this 873 exchange. [BEEP] is the transport protocol is used to move these 874 encapsulations between a CUA and a CS. CAP's [BEEP] profile defines 875 the application protocol where the content and semantics of the 876 messages sent between the CUA and the CS are specified. 878 3.2 Calendar Store Object Model 880 [iCAL] describes components such as events, todos, alarms, and 881 timezones. [CAP] requires additional object infrastructure. In 882 particular, detailed definitions of the containers for events and 883 todos (calendars), access control objects, and a query language. 885 The conceptual model for a calendar store is shown below. The 886 calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s, 887 "VTIMEZONE"s, "VAGENDA"s and calendar store properties. 889 Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, 890 "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar 891 properties. 893 The component "VCALSTORE" is used to denote the a root of the 894 calendar store and contains all of the calendars. 896 Calendar Store 898 VCALSTORE 899 | 900 +-- properties 901 +-- VCARs 902 +-- VQUERYs 903 +-- VTIMEZONEs 904 +-- VAGENDA 905 | | 906 | +--properties 907 | +--VEVENTs 908 | | | 909 | | +--VALARMs 910 | +--VTODOs 911 | | | 912 | | +--VALARMs 913 | +--VJOURNALs 914 | +--VCARs 915 | +--VTIMEZONEs 916 | +--VQUERYs 917 | +--VFREEBUSYs 918 | | 919 | | ... 920 . 921 . 922 +-- VAGENDA 923 . . 924 . . 925 . . 927 Calendars within a Calendar Store are identified by their unique 928 Relative CALID. 930 3.3 Protocol Model 932 CAP uses beep as the transport and authentication protocol. 934 The initial charset MUST BE UTF-8 for the session in an unknown 935 locale. If the CS supplied the BEEP 'localize' attribute in the BEEP 936 'greeting' then the CUA may tell the CS to switch locales for the 937 session by issuing the "SET-LOCALE" CAP command and supplying one of 938 the locales supplied by the BEEP 'localize' attribute. If supplied 939 the first locale supplied in the BEEP 'localize' attribute MUST BE 940 the default locale of the CS. The locale is switched only after a 941 successful reply. 943 The "DEFAULT-CHARSET" property of the CS contains the list of 944 charsets supported by the CS with the first value being the default 945 for new calendars. If the CUA wishes to switch to one of those 946 charsets for the session, the CUA issues the "SET-LOCALE" command. 947 The CUA would have to first perform a "GET-CAPABILITY" command on the 948 CS to get the list of charsets supported by the CS. The charset is 949 switched only after a successful reply. 951 The CUA may switch locales and charsets as needed. There is no 952 requirement that a CS support multiple locales or charsets. 954 3.3.1 Use of BEEP, MIME and iCalendar 956 CAP uses the BEEP application protocol over TCP. (refer to [BEEP] 957 and [BEEPTCP] for more information). The default port that the 958 Calendar Server listens for connections is on user port 1026. 960 The BEEP data exchanged in CAP is a iCalendar MIME content that fully 961 conforms to [iCAL] iCalendar format. 963 This example tells the CS to generate and return 10 UIDs to be used 964 by the CUA. (Note throughout this memo, 'C:' refers to what the CUA 965 sends, 'S:' refers to what the CS sends, 'I:' refers to what the 966 initiator sends, and 'L:' refers to what the listener sends. Where 967 initiator and responder are used as defined in [BEEP].) 969 C: MSG 1 2 . 432 62 970 C: Content-Type: text/calendar 971 C: 972 C: BEGIN:VCALENDAR 973 C: VERSION:2.0 974 C: PRODID:-//someone's prodid 975 C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID 976 C: END:VCALENDAR 978 NOTE: The following examples will not include the BEEP header and 979 footer information. Only the iCalendar objects that are sent between 980 the CUA and CS will be shown as the BEEP payload boundaries are 981 independent of CAP. 983 The commands listed below are used to manipulate or access the data 984 on the calendar store: 986 ABORT - Sent to halt the processing of any command except ABORT. 987 (Section 10.1.2) 989 CONTINUE - Sent to continue processing a command that has had its 990 specified timeout time reached. (Section 10.1.3) 992 CREATE - Create a new object on the CS. This can be implied for 993 [iTIP] objects. Initiated by the CUA only. (Section 10.1.4) 995 SET-LOCALE - Tell the CS to use any named locale and charset 996 supplied. Initiated by the CUA only. (Section 10.9) 998 DELETE - Delete objects from the CS. Initiated by the CUA only. 999 Can also be used to mark a object for deletion. (Section 10.1.5) 1001 GENERATE-UID - Generate one or more unique ids. Initiated by the 1002 CUA only. (Section 10.2) 1004 GET-CAPABILITY - Query the capabilities the other end point of the 1005 session. (Section 10.3) 1007 IDENTIFY - Set a new identity for the session. Initiated by the CUA 1008 only. (Section 10.4) 1010 MODIFY - Modify components. Initiated by the CUA only. (Section 1011 10.5) 1013 MOVE - Move components to another container. Initiated by the CUA 1014 only. (Section 10.6) 1016 REPLY - When replying to a command, the "CMD" value will be set to 1017 "REPLY" so that it will not be confused with a new command. 1018 (Section 10.7) 1020 SEARCH - Search for components. Initiated by the CUA only. 1021 (Section 10.8) 1023 TIMEOUT - Sent when a specified amount of time has lapsed and a 1024 command has not finished. (Section 10.10) 1026 4. Security Model 1028 The BEEP transport performs all session authentication. 1030 4.1 Calendar User and UPNs 1032 A CU is an entity that can be authenticated. It is represented in 1033 CAP as a UPN, which is a key part of access rights. The UPN 1034 representation is independent of the authentication mechanism used 1035 during a particular CUA/CS interaction. This is because UPNs are 1036 used within VCARs. If the UPN were dependent on the authentication 1037 mechanism, a VCAR could not be consistently evaluated. A CU may use 1038 one mechanism while using one CUA but the same CU may use a different 1039 authentication mechanism when using a different CUA, or while 1040 connecting from a different location. 1042 The user may also have multiple UPNs for various purposes. 1044 Note that the immutability of the user's UPN may be achieved by using 1045 SASL's authorization identity feature. (The transmitted 1046 authorization identity may be different than the identity in the 1047 client's authentication credentials.) [SASL, section 3]. This also 1048 permits a CU to authenticate using their own credentials, yet request 1049 the access privileges of the identity for which they are proxying 1050 SASL. Also, the form of authentication identity supplied by a 1051 service like TLS may not correspond to the UPNs used to express a 1052 server's access rights, requiring a server specific mapping to be 1053 done. The method by which a server determines a UPN, based on the 1054 authentication credentials supplied by a client, is implementation 1055 specific. See [BEEP] for authentication details; [BEEP] relies on 1056 SASL. 1058 4.1.1 UPNs and Certificates 1060 When using X.509 certificates for purposes of CAP authentication, the 1061 UPN should appear in the certificate. Unfortunately there is no 1062 single correct guideline for which field should contain the UPN. 1064 From RFC-2459, section 4.1.2.6 (Subject): 1066 If subject naming information is present only in the subjectAlt- 1067 Name extension (e.g., a key bound only to an email address or 1068 URI), then the subject name MUST be an empty sequence and the 1069 subjectAltName extension MUST BE critical. 1071 Implementations of this specification MAY use these comparison 1072 rules to process unfamiliar attribute types (i.e., for name 1073 chaining). This allows implementations to process certificates 1074 with unfamiliar attributes in the subject name. 1076 In addition, legacy implementations exist where an RFC 822 name is 1077 embedded in the subject distinguished name as an EmailAddress 1078 attribute. The attribute value for EmailAddress is of type 1079 IA5String to permit inclusion of the character '@', which is not 1080 part of the PrintableString character set. EmailAddress attribute 1081 values are not case sensitive (e.g., "fanfeedback@redsox.com" is 1082 the same as "FANFEEDBACK@REDSOX.COM"). 1084 Conforming implementations generating new certificates with 1085 electronic mail addresses MUST use the rfc822Name in the subject 1086 alternative name field (see sec. 4.2.1.7 of [X509CRL]) to 1087 describe such identities. Simultaneous inclusion of the 1088 EmailAddress attribute in the subject distinguished name to 1089 support legacy implementations is deprecated but permitted. 1091 Since no single method of including the UPN in the certificate will 1092 work in all cases, CAP implementations MUST support the ability to 1093 configure what the mapping will be by the CS administrator. 1094 Implementations MAY support multiple mapping definitions, for 1095 example, the UPN may be found in either the subject alternative name 1096 field, or the UPN may be embedded in the subject distinguished name 1097 as an EmailAddress attribute. 1099 Note: If a CS or CUA is validating data received via [iMIP], if the 1100 "ORGANIZER" or "ATTENDEE" properties said (e.g.) "ATTENDEE;CN=Joe 1101 Random User:MAILTO:juser@example.com" then the email address should 1102 be checked against the UPN. This is so the "ATTENDEE" property 1103 cannot be changed to something misleading like "ATTENDEE;CN=Joe 1104 Rictus User:MAILTO:jrictus@example.com" and have it pass validation. 1105 Note that it is the email addresses that miscompare, the CN 1106 miscompare is irrelevant. 1108 4.1.2 Anonymous Users and Authentication 1110 Anonymous access is often desirable. For example an organization may 1111 publish calendar information that does not require any access control 1112 for viewing or login. Conversely, a user may wish to view 1113 unrestricted calendar information without revealing their identity. 1115 4.1.3 User Groups 1117 A User Group is used to represent a collection of CUs or other UGs 1118 that can be referenced in VCARs. A UG is represented in CAP as a 1119 UPN. The CUA cannot distinguish between a UPN that represents a CU 1120 or a UG. 1122 UGs are expanded as necessary by the CS. The CS MAY expand a UG 1123 (including nested UGs) to obtain a list of unique CUs. Duplicate 1124 UPNs are filtered during expansion. 1126 How the UG expansion is maintained across commands is implementation 1127 specific. A UG may reference a static list of members, or it may 1128 represent a dynamic list. Operations SHOULD recognize changes to UG 1129 membership. 1131 CAP does not define commands or methods for managing UGs. 1133 4.2 Access Rights 1135 Access rights are used to grant or deny access to calendars, 1136 components, properties, and parameters in a CS to a CU. CAP defines 1137 a new component type called a Calendar Access Right (VCAR). 1138 Specifically, a "VCAR" component grants, or denies, UPNs the right to 1139 search and write components, properties, and parameters on calendars 1140 within a CS. 1142 The "VCAR" component model does not put any restriction on the 1143 sequence in which the object and access rights are created. That is, 1144 an object associated with a particular "VCAR" component might be 1145 created before or after the actual "VCAR" component is defined. In 1146 addition, the "VCAR" and "VEVENT" components might be created in the 1147 same iCalendar object and passed together in a single object. 1149 All rights MUST BE denied unless specifically granted. 1151 If two rights specified in "VCAR" components are in conflict, the 1152 right that denies access always takes precedence over the right that 1153 grants access. Any attempt to create a "VCAR" component that 1154 conflicts with an immutable "VCAR" components must fail. 1156 4.2.1 Access Control and NOCONFLICT 1158 The "TRANSP" property can take on values "TRANSPARENT-NOCONFLICT" and 1159 "OPAQUE-NOCONFLICT" that prohibit other components from overlapping 1160 it. This setting overrides access. The "ALLOW-CONFLICT" CS, 1161 Calendar or component setting may also prevent overlap, returning an 1162 error code "6.3". 1164 4.2.2 Calendar Access Right (VCAR) 1166 Access rights within CAP are specified with the "VCAR" component, 1167 "RIGHTS" value type and the "GRANT", "DENY" and "CARID" properties. 1169 Properties within an iCalendar object are unordered. This also is 1170 the case for the "VCAR" component properties. 1172 4.2.3 Predefined VCARs 1174 Predefined calendar access CARIDs that MUST BE implemented are: 1176 CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules that 1177 allow UPNs to search "VFREEBUSY" components. An example 1178 definition for this VCAR is: 1180 BEGIN:VCAR 1181 CARID:READBUSYTIMEINFO 1182 BEGIN:VRIGHT 1183 GRANT:* 1184 PERMISSION:SEARCH 1185 SCOPE:SELECT * FROM VFREEBUSY 1186 END:VRIGHT 1187 END:VCAR 1189 CARID:REQUESTONLY - Specifies the "GRANT" and "DENY" rules to UPNs 1190 other than the owner of the calendar the ability to write new 1191 objects with the property "METHOD" property set to the "REQUEST" 1192 value. This CARID allows the owner to specify which UPNs are 1193 allowed to make scheduling requests. An example definition for 1194 this VCAR is: 1196 BEGIN:VCAR 1197 CARID:REQUESTONLY 1198 BEGIN:VRIGHT 1199 GRANT:NON CAL-OWNERS() 1200 PERMISSION:CREATE 1201 RESTRICTION:SELECT VEVENT FROM VAGENDA WHERE METHOD = 'REQUEST' 1202 RESTRICTION:SELECT VTODO FROM VAGENDA WHERE METHOD = 'REQUEST' 1203 RESTRICTION:SELECT VJOURNAL FROM VAGENDA WHERE METHOD = 'REQUEST' 1204 END:VRIGHT 1205 END:VCAR 1207 CARID:UPDATEPARTSTATUS - Grants to authenticated users the right to 1208 modify the instances of the "ATTENDEE" property set to one of 1209 their calendar addresses in any components for any booked 1210 component containing a "ATTENDEE" property. This allows (or 1211 denies) a CU the ability to update their own participation status 1212 in a calendar where they might not otherwise have "MODIFY" command 1213 access. They are not allowed to change the "ATTENDEE" property 1214 value. An example definition for this VCAR is (This example only 1215 effects the "VEVENT" components): 1217 BEGIN:VCAR 1218 CARID:UPDATEPARTSTATUS 1219 BEGIN:VRIGHT 1220 GRANT:* 1221 PERMISSION:MODIFY 1222 SCOPE:SELECT ATTENDEE FROM VEVENT 1223 WHERE ATTENDEE = SELF() 1224 AND ORGANIZER = CURRENT-TARGET() 1225 AND STATE() = 'BOOKED' 1226 RESTRICTION:SELECT * FROM VEVENT 1227 WHERE ATTENDEE = SELF() 1228 END:VRIGHT 1229 END:VCAR 1231 CARID:DEFAULTOWNER - Grants to any owner the permission they have 1232 for the target. An example definition for this VCAR is: 1234 BEGIN:VCAR 1235 CARID:DEFAULTOWNER 1236 BEGIN:VRIGHT 1237 GRANT:CAL-OWNERS() 1238 PERMISSION:* 1239 SCOPE:SELECT * FROM VAGENDA 1240 END:VRIGHT 1241 END:VCAR 1243 4.2.4 Decreed VCARs 1245 A CS MAY choose to implement and allow persistent immutable VCARs 1246 that may be configured by the CS administrator. A reply from the CS 1247 may dynamically create "VCAR" components that are decreed depending 1248 on the implementation. To the CUA any "VCAR" component with the 1249 "DECREED" property set to "TRUE" can not be changed by the currently 1250 authenticated UPN, and depending on the implementation and other 1251 "VCAR" components; might not be able to be changed by any UPN using 1252 CAP, and never when the CUA gets a "DECREED:TRUE" VCAR. 1254 When a user attempts to modify or override a decreed "VCAR" component 1255 rules an error will be returned indicating that the user has 1256 insufficient authorization to perform the operation. The reply to 1257 the CUA MUST BE the same as if a non-decreed VCAR caused the failure. 1259 The CAP protocol does not define the semantics used to initially 1260 create a decreed VCAR. This administrative task is outside the scope 1261 of the CAP protocol. 1263 For example; an implementation or a CS administrator may wish to 1264 define a VCAR that will always allow the calendar owners to have full 1265 access to their own calendars. 1267 Decreed "VCAR" components MUST BE readable by the calendar owner in 1268 standard "VCAR" component format. 1270 4.3 CAP Session Identity 1272 A BEEP session has an associated set of authentication credentials, 1273 from which is derived a UPN. This UPN is the identity of the CAP 1274 session, and is used to determine access rights for the session. 1276 The CUA may change the identity of a CAP session by calling the 1277 "IDENTIFY" command. The Calendar Server only permits the operation 1278 if the session's authentication credentials are good for the 1279 requested identity. The method of checking this permission is 1280 implementation dependent, but may be thought of as a mapping from 1281 authentication credentials to UPNs. The "IDENTIFY" command allows a 1282 single set of authentication credentials to choose from multiple 1283 identities, and allows multiple sets of authentication credentials to 1284 assume the same identity. 1286 For anonymous access the identity of the session is "@". A UPN with 1287 a null Username and null Realm is anonymous. A UPN with a null 1288 Username, but non-null Realm, such as "@foo.com" may be used to mean 1289 any identity from that Realm, which is useful to grant access rights 1290 to all users in a given Realm. A UPN with a non-null Username and 1291 null Realm, such as "bob@" could be a security risk and MUST NOT be 1292 used. 1294 Since the UPN includes Realm information it may be used to govern 1295 calendar store access rights across Realms. However, governing 1296 access rights across Realms is only useful if login access is 1297 available. This could be done through a trusted server relationship 1298 or a temporary account. Note that trusted server relationships are 1299 outside the scope of [CAP]. 1301 The "IDENTIFY" command also provides for a weak group implementation. 1302 By allowing multiple sets of authentication credentials belonging to 1303 different users to identify as the same UPN, that UPN essentially 1304 identifies a group of people, and may be used for group calendar 1305 ownership, or the granting of access rights to a group. 1307 5. CAP URL and Calendar Address 1309 The CAP URL scheme is used to designate calendar stores and calendars 1310 accessible using the CAP protocol. 1312 The CAP URL scheme conform to the generic URL syntax, defined in RFC 1313 2396, and follows the Guidelines for URL Schemes, set forth in RFC 1314 2718. 1316 A CAP URL begins with the protocol prefix "cap" and is defined by the 1317 following grammar. 1319 capurl = "cap://" csid [ "/" relcalid ] 1320 csid = hostport ; As defined in Section 3.2.2 of RFC 2396 1321 relcalid = *uric ; As defined in Section 2 of RFC 2396 1323 A 'relcalid' is an identifier that uniquely identifies a calendar on 1324 a particular calendar store. There is no implied structure in a 1325 Relative CALID. It may refer to the calendar of a user or of a 1326 resource such as a conference room. It MUST BE unique within the 1327 calendar store. 1329 Examples: 1331 cap://cal.example.com 1332 cap://cal.example.com/Company/Holidays 1333 cap://cal.example.com/abcd1234Usr 1335 Relative CAP URLs are permitted and are resolved according to the 1336 rules defined in Section 5 of RFC 2396. 1338 Examples of valid relative CAP URLs: 1340 opqaueXzz123String 1341 UserName/Personal 1343 A Calendar addresses can be described as qualified or relative CAP 1344 URLs. 1346 For a user currently authenticated to the CS on cal.example.com, 1347 these two example calendar addresses refer to the same calendar: 1349 cap://cal.example.com/abcd1234USR 1350 abcd1234USR 1352 6. New Value Types 1354 The following sections contains new components, properties, 1355 parameters, and value definitions. 1357 The purpose of these is to extend the iCalendar objects in a 1358 compatible way so that existing iCalendar "VERSION" property "2.0" 1359 value parsers can still parse the objects without modification. 1361 6.1 Property Value Data Types 1363 6.1.1 CAL-QUERY Value Type 1365 Subject: Registration of text/calendar MIME value type CAL-QUERY 1367 Value Name: CAL-QUERY 1369 Value Type Purpose: This value type is used to identify values and 1370 contains query statements targeted at locating those values. 1372 This is based on [SQL92] and [SQLCOM]. 1374 1. For the purpose of a query, all components should be handled as 1375 tables, and the properties of those components, should be handled 1376 as columns. 1378 2. All VAGENDAs and CS's look like tables for the purpose of a 1379 QUERY. And all of their properties look like columns in those 1380 tables. 1382 3. You CAN NOT do any cross component-type joins. And that means 1383 you can ONLY have one component, OR one "VAGENDA" component OR 1384 one "VCALSTORE" component in the "FROM" clause. 1386 4. Everything in the "SELECT" clause and "WHERE" clauses in MUST BE 1387 from the same component type, or "VAGENDA" component OR 1388 "VCALSTORE" component in the "FROM" clause. 1390 5. When multiple "QUERY" properties are supplied in a single 1391 "VQUERY" component, the results returned are the same as the 1392 results returned for multiple "VQUERY" components having each a 1393 single "QUERY" property and the results are return in the same 1394 order as the "VQUERY" properties were specified in the original 1395 command. 1397 6. The '.' is used to separate the table name (component) and column 1398 name (property or component) when selecting a property that is 1399 contained inside of a component that is targeted in the TARGET 1400 property. 1402 7. A contained component without a '.' is not the same as 1403 "component-name.*". If given as "component-name" (no dot) the 1404 encapsulating BEGIN/END statement will be supplied for 1405 "component-name".: 1407 In this example the '.' is used to separate the "TRIGGER" property 1408 from its contained component (VALARM). Which is contained in any 1409 "VEVENT" component in the selected "TARGET" property value (a 1410 relcalid). All "TRIGGER" properties in any "VEVENT" component in 1411 relcalid would be returned. 1413 TARGET:relcalid 1414 QUERY:SELECT VALARM.TRIGGER FROM VEVENT 1416 SELECT VALARM FROM VEVENT WHERE UID = "123" 1418 This return one BEGIN/END "VALARM" component for each 1419 "VALARM" component in the matching "VEVENT" component. 1420 As there is no '.' (dot) in the VALARM after the SELECT above: 1422 BEGIN:VALARM 1423 TRIGGER;RELATED=END:PT5M 1424 REPEAT:4 1425 ... 1426 END:VALARM 1427 BEGIN:VALARM 1428 TRIGGER;RELATED=START:PT5M 1429 DURATION:PT10M 1430 ... 1431 END:VALARM 1432 ... 1433 ... 1435 If provided as "component-name.*", then only the properties and any 1436 contained components will be returned: 1438 SELECT VALARM.* FROM VEVENT WHERE UID = "123" 1440 Will return all of the properties in each "VALARM" component 1441 in the matching "VEVENT" component: 1443 TRIGGER;RELATED=END:PT5M 1444 REPEAT:4 1445 ... 1446 TRIGGER;RELATED=START:PT5M 1447 DURATION:PT10M 1448 ... 1449 ... 1451 (a) SELECT FROM VEVENT 1453 (b) SELECT VALARM FROM VEVENT 1455 (c) SELECT VALARM.* FROM VEVENT 1457 (d) SELECT * FROM VEVENT 1459 (e) SELECT * FROM VEVENT WHERE 1460 VALARM.TRIGGER < '20020201T000000Z' 1461 AND VALARM.TRIGGER > '20020101T000000Z' 1463 Note: 1464 (a) Selects all instances of 1465 from all "VEVENT" components. 1467 (b) and (c) Select all "VALARM" components from all 1468 "VEVENT" components. (b) would return then in 1469 BEGIN/END VALARM tags. (c) would return all 1470 of the properties without BEGIN/END VALARM tags. 1472 (d) Selects every property and every component 1473 that is in any "VEVENT" component. 1475 (e) Selects all properties and all contained 1476 components in all "VEVENT" components that have a "VALARM" 1477 component with a "TRIGGER" property value between 1478 the provided dates and times. 1480 NOT VALID: 1482 (f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT 1483 (g) SELECT DTSTART,UID FROM VEVENT WHERE 1484 VTODO.SUMMERY = "Fix typo in CAP" 1486 Note: (f) Is NOT valid because it contains 1487 two '.' characters in the "SELECT" clause. 1489 (g) Is NOT valid because it mixes VEVENT 1490 and VTODO properties in the same VQUERY. 1492 Formal Definition: The value type is defined by the following 1493 notation: 1495 cal-query = "SELECT" SP cap-val SP 1496 "FROM" SP comp-name SP 1497 "WHERE" SP cap-expr 1499 / "SELECT" SP cap-cols SP 1500 "FROM" SP comp-name 1502 cap-val = cap-cols / param 1503 / ( cap-val "," cap-val ) 1505 ; NOTE: there is NO space around the "," on 1506 ; the next line 1507 cap-cols = cap-col / ( cap-cols "," cap-col) 1508 / "*" 1510 ; A 'cap-col' is: 1511 ; 1512 ; Any property name ('cap-prop') found in the component 1513 ; named in the 'comp-name' used in the "FROM" clause. 1514 ; 1515 ; SELECT ORGANIZER FROM VEVENT ... 1516 ; 1517 ; OR 1518 ; 1519 ; A component name ('comp-name') of an existing component 1520 ; contained inside of the 'comp-name' used in the "FROM" 1521 ; clause. 1522 ; 1523 ; SELECT VALARM FROM VEVENT ... 1524 ; 1525 ; OR 1526 ; 1527 ; A component name ('comp-name') of an existing 1528 ; component contained inside of the 'comp-name' used 1529 ; in the "FROM" clause folowed by a property 1530 ; name ('cap-prop') to be selected from that component. 1531 ; (comp-name "." cap-prop) 1532 ; 1533 ; SELECT VALARM.TRIGGER FROM VEVENT ... 1535 cap-col = comp-name 1536 / comp-name "." cap-prop 1538 comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" 1539 / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" 1540 / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" 1541 / x-comp / iana-comp 1543 cap-prop = ; A property that may be in the 'cap-comp' named 1544 ; in the "SELECT" clause. 1546 cap-expr = "(" cap-expr ")" 1547 / cap-term 1549 cap-term = cap-expr SP cap-logical SP cap-expr 1550 / cap-factor 1552 cap-logical= "AND" / "OR" 1554 cap-factor = cap-colval SP cap-oper SP col-value 1555 / cap-colval SP "NOT LIKE" SP col-value 1556 / cap-colval SP "LIKE" SP col-value 1557 / cap-colval SP "IS NULL" 1558 / cap-colval SP "IS NOT NULL" 1559 / col-value SP "NOT IN" cap-colval" 1560 / col-value SP "IN" cap-colval" 1561 / "STATE()" "=" ( "BOOKED" 1562 / "UNPROCESSED" 1563 / "DELETED" ) 1565 cap-colval = cap-col / param 1567 param = "PARAM(" cap-col "," cap-param ")" 1569 cap-param = ; Any parameter that may be contained in the cap-col 1570 ; in the supplied PARAM() function 1572 col-value = col-literal 1573 / "SELF()" 1574 / "CAL-OWNERS()" 1575 / "CAL-OWNERS(" cal-address ")" 1576 / "CURRENT-TARGET()" 1578 cal-address = ; A CALID as define by CAP 1580 col-literal = "'" literal-data "'" 1582 literal-data = ; Any data that matches the value type of the 1583 ; column that is being compared. That is you can 1584 ; not compare PRIORITY to "some string" because 1585 ; PRIORITY has a value type of integer. If it is 1586 ; not preceded by the LIKE element, any '%' and '_' 1587 ; characters in the literal data are not treated as 1588 ; wildcard characters and do not have to be backslash 1589 ; escaped. 1590 ; 1591 ; OR 1592 ; 1593 ; If the literal-data is preceded by the LIKE 1594 ; element it may also contain the '%' and '_' 1595 ; wildcard characters. And if the literal data 1596 ; that is comparing contains any '%' or '_' 1597 ; characters, they MUST BE backslash escaped as 1598 ; described in the notes below in order for them not 1599 ; to be treated as wildcard characters. 1601 cap-oper = "=" 1602 / "!=" 1603 / "<" 1604 / ">" 1605 / "<=" 1606 / ">=" 1608 SP = ; A single white space ascii character 1609 ; (value in HEX %x20). 1611 x-comp = ; As defined in RFC 2445 section 4.6 1613 iana-comp = ; As defined in RFC 2445 section 4.6 1615 6.1.1.1 [NOT] CAL-OWNERS() 1617 This function returns the list of "OWNER" properties for the named 1618 calendar when used in the "SELECT" clause. 1620 If called as 'CAL-OWNERS()', it is equivalent to the comma separated 1621 list of all of the owners of the calendar that match the provided 1622 "TARGET" property value. If the target is a "VCALSTORE", it returns 1623 the "CALMASTER" property. 1625 If called as 'CAL-OWNERS(cal-address)', then it is the equivalent to 1626 the comma separated list of owners for the named calendar id. If 1627 'cal-address' is a CS, it returns the "CALMASTER" property. 1629 If used in the in the "WHERE" clause it then returns true if the 1630 currently authenticated UPN is an owner of the currently selected 1631 object matched in the provided "TARGET" property. Used in a CAL- 1632 QUERY "WHERE" clause and in the UPN-FILTER. 1634 6.1.1.2 CURRENT-TARGET() 1636 Is equivalent to the value of the "TARGET" property in the current 1637 command. Used in a CAL-QUERY "WHERE" clause. 1639 6.1.1.3 PARAM() 1641 Used in a CAL-QUERY. Returns the value of the named parameter from 1642 the named property. If there are multiple properties in the object, 1643 then PARAM() returns a comma separated list of parameter values. If 1644 needed each value can be quoted or contain backslash escaped 1645 contents. 1647 When used in a "SELECT" clause, it returns the entire property and 1648 all of that propertiies parameters (the result is not limited to the 1649 supplied parameter). If the property does not contain the named 1650 parameter, then the property is not returned (It could however be 1651 returned as a result of another "SELECT" clause value.) If multiple 1652 properties of the supplied name have the named parameter, all 1653 properties with that named parameter are returned. 1655 When used in the "WHERE" clause, a match is true when the parameter 1656 value is "IN" or "LIKE" compare clause according to the supplied 1657 WHERE values. If multiple named properties contain the named 1658 parameter, then each parameter value is compared to the condition and 1659 if any match, then the results would be true for that condition the 1660 same as if only one had existed. 1662 6.1.1.4 SELF() 1664 Used in a CAL-QUERY "WHERE" clause. Returns the UPN of the currently 1665 authenticated UPN. 1667 6.1.1.5 STATE() 1669 Returns one of three values, 'BOOKED', 'UNPROCESSED', or 'DELETED' 1670 depending on the state of the object. Used in a CAL-QUERY "WHERE" 1671 clause. 1673 6.1.1.6 Ordering of Results 1675 Sorting will take place in the order the columns are supplied in the 1676 QUERY command. The CS MUST sort at least the first column. The CS 1677 MAY sort additional columns. 1679 Float and integer values MUST BE sorted by their numeric value. This 1680 means the result of a sort on an integer value type will be: 1682 1, 2, 100, 1000 1684 and not 1686 1, 100, 1000, 2 1688 This means the result of a sort on an float value type will be: 1690 1.1, 2.23, 100.332, 1000.12 1692 and not 1694 1.1, 100.332, 1000.12, 2.23 1696 Date and date time values will be sorted by their equivalent value in 1697 UTC. No matter what the returned time zone in the result set 1698 returns. This is so that if multiple components are returned each in 1699 a unique time zone, the results will be sorted in UTC. This does not 1700 mean the values MUST BE converted to UTC in the data returned to the 1701 CUA. It means the CS must do the sort in UTC. 1703 All other values are sorted according to the locale sorting order as 1704 specified in the command. Or the calendar locale if known, or the CS 1705 locale if the calendar does not have any locale set. And the locale 1706 to use for the sort is determined in that order. 1708 6.1.1.7 Date sorting order 1710 If the cap-cols is only "*" and nothing else and the result set has a 1711 DTSTART, then: 1713 If EXPAND=FALSE sorting will be by the "DTSTART" property value 1714 ascending as if it were in UTC. 1716 If EXPAND=TRUE sorting will be by the "RECURRENCE-ID" property value 1717 ascending as if it were in UTC. 1719 If one or more "DTSTART" or "RECURRENCE-ID" property values in 1720 multiple components have exactly the same value, the order for those 1721 matching components is unspecified. 1723 If the selected component(s) do not contain a "DTSTART" property or a 1724 "RECURRENCE-ID" property, then the order is unspecified. 1726 If an instance does not have a "RECURRENCE-ID" property and the query 1727 compares "RECURRENCE-ID" properties (comparing a RECURRENCE-ID to the 1728 date or date/time of a single instance object), then the CS MUST 1729 compare the "DTSTART" property value as if it were a "RECURRENCE-ID" 1730 even for single instance objects that do not contain a "RECURRENCE- 1731 ID" property. 1733 A component with a DATE and no TIME value is returned before objects 1734 with both a DATE and TIME value when the dates of those two (or more) 1735 objects are the same, sorted by date. 1737 6.1.1.8 Use of single quote 1739 All literal values are surrounded by single quotes ('), not double 1740 quotes ("), and not without any quotes. If the value contains quotes 1741 or any other ESCAPED-CHAR, they MUST BE backslash escaped as 1742 described in section "4.3.11 Text" of RFC2445. Any "LIKE" clause 1743 wildcard characters that are part of any literal data that is 1744 preceded by a "LIKE" clause and is not intended to mean wildcard 1745 search, MUST BE escaped as described in note (7) below. 1747 6.1.1.9 Comparing DATE and DATE-TIME values 1749 When comparing "DATE-TIME" values to "DATE" values and when comparing 1750 "DATE" values to "DATE-TIME" values, the result will be true if the 1751 "DATE" value is on the same day as the "DATE-TIME" value. And they 1752 are compared in UTC no matter what time zone the data may actual have 1753 been stored in. 1755 VALUE-1 VALUE-2 Compare Results 1757 20020304 20020304T123456 TRUE 1758 (in UTC-3) (in UTC-3) 1760 20020304 20020304T003456 FALSE 1761 (in UTC) (in UTC-4) 1763 20020304T003456Z 20020205T003456 FALSE 1764 (in UTC-0) (in UTC-7) 1766 When the "DATE" value or "DATE-TIME" value is not associated with a 1767 time zone, then the CS will compare the value assuming that the no 1768 time zone values are in the calendars default time zone. 1770 When comparing "DATE" values and "DATE-TIME" values with the "LIKE" 1771 clause the comparison will be done as if the value is a RFC2445 DATE 1772 or DATE-TIME string value. 1774 LIKE '2002%' will match anything in the year 2002. 1776 LIKE '200201%' will match anything in January 2002. 1778 LIKE '%T000000' will match anything at midnight. 1780 LIKE '____01__T%' will match anything for any year or 1781 time that is in January. 1782 (Four '_', '01', two '_' 'T%'). 1784 Using a "LIKE" clause value of "%00%, would return any value that 1785 contained two consecutive zeros. 1787 All comparisons will be done in UTC. 1789 6.1.1.10 DTEND and DURATION 1791 When a "QUERY" property value contains a "DTEND" value, then the CS 1792 MUST also evaluate any existing "DURATION" property value and 1793 determine if it has an effective end time that matches the "QUERY" 1794 property supplied "DTEND" value or any range of values supplied by 1795 the "QUERY" property. 1797 When a "QUERY" property contains a "DURATION" value, then the CS MUST 1798 also evaluate any existing "DTEND" property values and determine if 1799 they have an effective duration that matches the "QUERY" property 1800 value supplied "DURATION" value or any range of values supplied by 1801 the "QUERY" property. 1803 As "DTEND" value is the first time that is excluded from a components 1804 time range, any "DURATION" value supplied by the "QUERY" poperty 1805 value that is exactly one second less than the "DTEND" property value 1806 MUST match the QUERY. And if the "DURATION" property value ends 1807 exactly at the computed DTEND it MUST NOT match. 1809 Any "DTEND" value supplied by the "QUERY" property that is exactly 1810 one second more than an end time computed from a DURATION MUST match 1811 the QUERY. Any end time that is computed from a DURATION that 1812 exactly matches the supplied DTEND MUST NOT match. 1814 Given a meeting room reserved with a component that contains (date- 1815 time-example-1): 1817 DTSTART:20020127T000000Z 1818 DTEND:20020127T010000Z 1820 The reservation is really from: 1822 January 27th, 2002 00:00:00 1823 To: 1825 January 27th, 2002,00:59:59 1827 Given another meeting room reserved with a component that contains 1828 (date-time-example-2): 1830 DTSTART:20020127T000000Z 1831 DURATION:P59M59S 1833 The reservation is really from: 1835 January 27th, 2002 00:00:00 1837 To: 1839 January 27th, 2002,00:59:59 1841 A QUERY that contains: 1843 ... VEVENT.DTSTART = '20020127T00000Z' 1844 AND VEVENT.DTEND = '20020127T010000Z' 1846 MUST match both (date-time-example-1) and (date-time-example-2) 1848 A QUERY that contains: 1850 ... VEVENT.DTSTART = '20020127T00000Z' 1851 AND DURATION = 'P59M59S' 1853 MUST match both (date-time-example-1) and (date-time-example-2) 1855 6.1.1.11 [NOT] LIKE 1857 The pattern matching characters are the '%' that matches zero or more 1858 characters, and '_' that matches exactly one character (where 1859 character does not always mean octet). 1861 "LIKE" clause pattern matches always cover the entire string. To 1862 match a pattern anywhere within a string, the pattern must start and 1863 end with a percent sign. 1865 To match a '%' or '_' in the data and not have it interpreted as a 1866 wildcard character, they MUST BE backslash escaped. That is to 1867 search for a '%' or '_' in the string: 1869 LIKE '%\%%' Matches any string with a '%' in it. 1870 LIKE '%\_%' Matches any string with a '_' in it. 1872 Strings compared using the "LIKE" clause MUST BE performed using case 1873 in-sensitive comparisons when the locale allows. (Example: in US- 1874 ASCII the compare assumes 'a' = 'A'). 1876 If the "LIKE" clause is preceded by 'NOT' then there is a match when 1877 the string compare fails. 1879 Some property values (such as the 'recur' value type), contain commas 1880 and are not multi valued. The CS must understand the objects being 1881 compared and understand how to determine how any multi valued or 1882 multi instances properties or parameter values are separated, quoted, 1883 and backslash escaped and perform the comparisons as if each value 1884 existed by itself and not quoted or backslash escaped when comparing 1885 using the IN element. 1887 See related examples in Section 6.1.1.13 1889 6.1.1.12 Empty vs. NULL 1891 When used in a CAL-QUERY value, "NULL" means that the property or 1892 parameter is not present in the object. 1894 If the property (or parameter) exists, but has no value then "NULL" 1895 MUST NOT match. 1897 If the property (or parameter) exists, but has no value then it 1898 matches the empty string '' (quote quote). 1900 6.1.1.13 [NOT] IN 1902 This is similar to the "LIKE" clause, except it does value matching 1903 and not string comparison matches. 1905 Some iCalendar objects can be multi instance and multi valued. The 1906 "IN" clause will return a match if the literal value supplied as part 1907 of the "IN" clause is contained in the value of any instance of the 1908 named property or parameter, or is in any of the multiple values in 1909 the named property or parameter. Unlike the "LIKE" clause, the '%' 1910 and '_' matching characters are not used with the "IN" clause and 1911 have no special meaning. 1913 BEGIN:A-COMPONENT 1914 a property:value1,value2 One property, two values. 1915 b property:"value1,value2" One property, one value. 1916 c property:parameter=1,2:x One parameter, two values. 1917 d property:parameter="1,2",3:y One parameter, one value. 1918 e property:parameter=",":z One parameter, one value. 1919 f property:x,y,z One property, three values 1920 END:A-COMPONENT 1922 'value1' IN property would match (a) only. 1923 'value1,value2' IN property would match (b) only. 1924 'value%' IN property would NOT match any. 1925 ',' IN property would NOT match any. 1926 '%,%' IN property would NOT match any. 1927 'x' IN property would match (f) and (c). 1928 '2' IN parameter would match (c) only. 1929 '1,2' IN parameter would match (d) only. 1930 ',' IN parameter would match (e) only. 1931 '%,%' IN parameter would NOT match any. 1933 property LIKE 'value1%' would match (a) and (b). 1934 property LIKE 'value%' would match (a) and (b). 1935 property LIKE 'x' would match (f) and (c). 1936 parameter LIKE '1%' would match (c) and (d). 1937 parameter LIKE '%2%' would match (c) and (d). 1938 parameter LIKE ',' would match (e) only. 1940 Some property values (such as the "RECUR" value type), contain commas 1941 and are not multi valued. The CS must understand the objects being 1942 compared and understand how to determine how any multi valued or 1943 multi instances properties or parameter values are separated, quoted, 1944 and backslash escaped and perform the comparisons as if each value 1945 existed by itself and not quoted or backslash escaped when comparing 1946 using the IN element. 1948 If the "IN" clause is preceded by 'NOT' then there is a match when 1949 the value does not exist in the property or parameter value. 1951 6.1.1.14 DATE-TIME and TIME values in a WHEN clause 1953 All "DATE-TIME" and "TIME" literal values supplied in a "WHEN" clause 1954 MUST BE terminated with 'Z'. That means that the CUA MUST supply the 1955 values in UTC. 1957 Valid: 1959 WHERE alarm.TRIGGER < '20020201T000000Z' 1960 AND alarm.TRIGGER > '20020101T000000Z' 1962 Not valid and it is a syntax error and the CS MUST reject the QUERY. 1964 WHERE alarm.TRIGGER < '20020201T000000' 1965 AND alarm.TRIGGER > '20020101T000000' 1967 6.1.1.15 Multiple contained components 1969 All comparisons MUST BE done from the same instance of a contained 1970 component or property and repeated for each instance. As in the 1971 following example that uses a "VALARM" component contained in a 1972 "VEVENT" component . If any instance of a "VALARM" component in any 1973 "VEVENT" component matches the query and the rest of the query is 1974 satisfied, then the "UID", "SUMMARY", and "DESCRIPTION" properties 1975 from all "VEVENT" components will be returned. If there were two 1976 "VALARM" components in a "VEVENT" component, then both "VALARM" 1977 components are tested and in this example only when the "VEVENT" 1978 component state is booked: 1980 BEGIN:VQUERY 1981 EXPAND:TRUE 1982 QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT 1983 WHERE VALARM.TRIGGER >= '20000101T030405Z' 1984 AND VALARM.TRIGGER <= '20001231T235959Z' 1985 AND STATE() = 'BOOKED' 1986 END:VQUERY 1988 6.1.1.16 Example, Query by UID 1990 The following example would match the entire content of a "VEVENT" or 1991 "VTODO" component with the "UID" property equal to "uid123" and not 1992 expand any multiple instances of the component. If the CUA does not 1993 know if "uid123" was a "VEVENT", "VTODO", "VJOURNAL", or any other 1994 component, then all components that the CUA supports MUST BE supplied 1995 in a QUERY property. This example assumes the CUA is only interested 1996 in "VTODO" and "VEVENT" components. 1998 If the results were empty it could also mean that "uid123" was a 1999 property in a component other than a VTODO or VEVENT. 2001 BEGIN:VQUERY 2002 QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' 2003 QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' 2004 END:VQUERY 2006 6.1.1.17 Query by Date-Time range 2008 This query selects the entire content of every booked "VEVENT" 2009 component that has an instance greater than or equal to July 1st, 2010 2000 00:00:00 UTC and less than or equal to July 31st, 2000 23:59:59 2011 UTC. This includes single instance "VEVENT" components that do no 2012 explicitly contain a "RECURRENCE-ID" property. 2014 BEGIN:VQUERY 2015 EXPAND:TRUE 2016 QUERY:SELECT * FROM VEVENT 2017 WHERE RECURRENCE-ID >= '20000801T000000Z' 2018 AND RECURRENCE-ID <= '20000831T235959Z' 2019 AND STATE() = 'BOOKED' 2020 END:VQUERY 2022 6.1.1.18 Query for all Unprocessed Entries 2024 The following example selects the entire contents of all non-booked 2025 "VTODO" and "VEVENT" components in the "UNPROCESSED" state. The 2026 default for the "EXPAND" property is FALSE, so the recurrence rules 2027 will not be expanded. 2029 BEGIN:VQUERY 2030 QUERYID:Fetch VEVENT and VTODO iTIP components 2031 QUERY:SELECT * FROM VEVENT WHERE 2032 STATE() = 'UNPROCESSED' 2033 QUERY:SELECT * FROM VTODO WHERE 2034 STATE() = 'UNPROCESSED' 2035 END:VQUERY 2037 The following example fetches all "VEVENT" and "VTODO" components in 2038 the "BOOKED" state. 2040 BEGIN:VQUERY 2041 QUERYID:Fetch All Booked VEVENT and VTODO components 2042 QUERY:SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' 2043 QUERY:SELECT * FROM VTODO WHERE STATE() = 'BOOKED' 2044 END:VQUERY 2046 The following fetches the "UID" property for all "VEVENT" and 2047 "fVTODO" components that have been marked for delete. 2049 BEGIN:VQUERY 2050 QUERYID:Fetch UIDs of marked for delete VEVENTs and VTODOs 2051 QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETE' 2052 QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETE' 2053 END:VQUERY 2055 In the examples above they were bunched into groups of similar 2056 queries. They could be performed all at once by having all of the 2057 "QUERY" properties in one BEGIN/END "VQUERY" component. The replies 2058 MUST BE in the same order as the supplied "QUERY" properties. 2060 6.1.1.19 Query with Subset of Properties by Date/Time 2062 In this example only the named properties will be selected and all 2063 booked and non-booked components will be selected that have a 2064 "DTSTART" value from February 1st to February 10th 2000 (in UTC). 2066 BEGIN:VQUERY 2067 QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT 2068 WHERE DTSTART >= '20000201T000000Z' 2069 AND DTSTART <= '20000210T235959Z' 2070 END:VQUERY 2072 6.1.1.20 Query with Components and Alarms In A Range 2074 This example fetches all booked "VEVENT" components with an alarm 2075 that triggers within the specified time range. In this case only the 2076 "UID", "SUMMARY", and "DESCRIPTION" properties will be selected for 2077 all booked "VEVENTS" components that have an alarm between the two 2078 date-times supplied. 2080 BEGIN:VQUERY 2081 EXPAND:TRUE 2082 QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT 2083 WHERE VALARM.TRIGGER >= '20000101T030405Z' 2084 AND VALARM.TRIGGER <= '20001231T235959Z' 2085 AND STATE() = 'BOOKED' 2086 END:VQUERY 2088 6.1.2 UPN Value Type 2090 Value Name: UPN 2092 Purpose: This value type is used to identify values that contain user 2093 principal name of CU or group of CU. 2095 Formal Definition: The value type is defined by the following 2096 notation: 2098 upn = "@" 2099 / [ dot-atom-text ] "@" dot-atom-text 2101 ; dot-atom-text is defined in RFC 2822 2103 Description: This data type is an identifier that denotes a CU or a 2104 group of CU. 2106 Example: 2108 The following is a UPN for a CU: 2110 jdoe@acme.com 2112 The following is a UPN for a group of CU: 2114 staff@acme.com 2116 The following is a UPN for an anonymous CU belonging to a specific 2117 realm: 2119 @acme.com 2121 The following is a UPN for an anonymous CU: 2123 @ 2125 6.1.3 UPN-FILTER Value 2127 Value Name: UPN-FILTER 2129 Purpose: This value type is used to identify values that contain a 2130 user principal name filter. 2132 Formal Definition: The value type is defined by the following 2133 notation: 2135 ; NOTE: "CAL-OWNERS(cal-address)" 2136 ; and "NOT CAL-OWNERS(cal-addres)" 2137 ; are both NOT allowed below. 2138 ; 2139 upn-filter = "CAL-OWNERS()" / 2141 "NOT CAL-OWNERS()" / 2142 "*" / 2143 [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) 2145 ; dot-atom-text is defined in RFC 2822 2147 Description: The value is used to match user principal names (UPNs). 2148 For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.19. 2150 * Matches all UPNs. 2152 @ Matches the UPN of anonymous CUs 2153 belonging to the null realm 2155 @* Matches the UPN of anonymous CUs 2156 belonging to any non-null realm 2158 @realm Matches the UPN of anonymous CUs 2159 belonging to the specified realm. 2161 *@* Matches the UPN of non-anonymous CUs 2162 belonging to any non-null realm 2164 *@realm Matches the UPN of non-anonymous CUs 2165 belonging to the specified realm 2167 user@realm Matches the UPN of the specified CU 2168 belonging to the specified realm 2170 user@* Not allowed. 2172 Example: The following are examples of this value type: 2174 DENY:NON CAL-OWNERS() 2176 7. New Parameters 2178 7.1 ENABLE Parameter 2180 Parameter Name: ENABLE 2182 Purpose: This parameter indicates whether or not the "TRIGGER" 2183 property in a "VALARM" component should be ignored. 2185 Value Type: BOOLEAN 2187 Conformance: This property can be specified in the "TRIGGER" 2188 properties. 2190 Description: When a non owner sends an [iTIP] "REQUEST" to a calendar 2191 that object might contain a "VALARM" component. The owner may wish 2192 to have local control over their own CUA and when or how alarms are 2193 triggered. 2195 A CUA may add the "ENABLE" parameter to any "TRIGGER" property before 2196 booking the component. If the "ENABLE" parameter is set to "FALSE", 2197 then the alarm will be ignored by the CUA. If set to "TRUE", or if 2198 the "ENABLE" property is not in the "TRIGGER" property, the alarm is 2199 enabled. The CUA should remove the "ENABLE" parameter before 2200 forwarding the component to a non-cap CUA. 2202 Formal Definition: The property is defined by the following notation: 2204 enable-param = "ENABLE" "=" boolean 2206 Example: The following is an example of this property for a "VAGENDA" 2207 component: 2209 TRIGGER;ENABLE=FALSE;RELATED=END:PT5M 2211 7.2 LOCAL Parameter 2213 Parameter Name: LOCAL 2215 Purpose: Indicates if the "VALARM" component should be exported to 2216 any non-organizer calendar. 2218 Value Type: BOOLEAN 2219 Conformance: This parameter can be specified in the "SEQUENCE" 2220 properties in a "VALARM" component. 2222 Description: When a non owner sends an [iTIP] "REQUEST" to a calendar 2223 that object might contain a "VALARM" component. The owner may wish 2224 to have local control over their own CUA and when or how alarms are 2225 triggered. 2227 A CUA may add the "LOCAL" parameter to the "SEQUENCE" property before 2228 booking the component. If the "LOCAL" parameter is set to "FALSE", 2229 then the alarm MUST NOT be forwarded to any non organizer calendar. 2230 If set to "TRUE", or of the "LOCAL" property is not in the "SEQUENCE" 2231 property, the alarm is global. The CUA should remove the "LOCAL" 2232 parameter before forwarding the component to a non-cap CUA and to non 2233 organizer calendars. 2235 Formal Definition: The property is defined by the following notation: 2237 local-param = "LOCAL" "=" boolean 2239 Example: The following is an example of this property for a "VAGENDA" 2240 component: 2242 SEQUENCE;LOCAL=TRUE:4 2244 8. New Properties 2246 8.1 ALLOW-CONFLICT Property 2248 Property Name: ALLOW-CONFLICT 2250 Purpose: This property indicates whether or not the calendar and CS 2251 supports component conflicts. That is, whether or not any of the 2252 components in the calendar can overlap. 2254 Value Type: BOOLEAN 2256 Property Parameters: Non-standard property parameters can be 2257 specified on this property. 2259 Conformance: This property can be specified in "VAGENDA" and 2260 "VCALSTORE" component. 2262 Description: This property is used to indicate whether components may 2263 conflict. That is, if their expanded instances may share the same 2264 time or overlap the same time periods. If it has a value of TRUE, 2265 then conflicts are allowed. If FALSE, the no two components may 2266 conflict. 2268 If FALSE in the "VCALSTORE" component, then all "VAGENDA" component 2269 "ALLOW-CONFLICT" property values MUST BE false in the CS. 2271 Formal Definition: The property is defined by the following notation: 2273 allow-conflict = "ALLOW-CONFLICT" 2274 *(";" xparam) ":" boolean CRLF 2276 Example: The following is an example of this property for a "VAGENDA" 2277 component: 2279 ALLOW-CONFLICT:FALSE 2281 8.2 ATT-COUNTER Property 2283 Property Name: ATT-COUNTER 2285 Property Parameters: Non-standard property parameters can be 2286 specified on this property. 2288 Conformance: This property MUST be specified in an iCalendar object 2289 that specifies counter proposal to a group scheduled calendar entity. 2290 When storing a "METHOD" property with the "COUNTER" method, there 2291 needs to be a way to remember who sent the COUNTER. The ATT-COUNTER 2292 property MUST BE added to all "COUNTER" [iTIP] components by the CUA 2293 before storing in a CS. 2295 Description: This property is used to identify the CAL-ADDRESS of the 2296 entity that sent the "COUNTER" [iTIP] object. 2298 Formal Definition: The property is defined by the following notation: 2300 attcounter = "ATT-COUNTER" *(";" xparam) ":" cal-address CRLF 2302 Examples: 2304 ATT-COUNTER:cap:example.com/Doug 2305 ATT-COUNTER:mailto:Doug@Example.com 2307 8.3 CALID Property 2309 Property Name: CALID 2311 Property Parameters: Non-standard property parameters can be 2312 specified on this property. 2314 Conformance: This property can be specified in the "VAGENDA" 2315 component. 2317 Description: This property is used to specify a fully qualified 2318 calid. 2320 Formal Definition: The property is defined by the following notation: 2322 CALID = "CALID" *(";" xparam) ":" calid CRLF 2324 Example: 2326 CALID:cap://cal.example.com/sdfifgty4321 2328 8.4 CALMASTER Property 2330 Property Name: CALMASTER 2332 Purpose: The property specifies an e-mail address of a person 2333 responsible for the calendar store. 2335 Value Type: URI 2337 Property Parameters: Non-standard property parameters can be 2338 specified on this property. 2340 Conformance: The property can be specified in a "VCALSTORE" 2341 component. 2343 Description: The parameter value SHOULD BE a MAILTO URI as defined in 2344 [URL]. It MUST BE a contact URI such as a MAILTO URI and not a home 2345 page or file URI that describes how to contact the calmasters. 2347 Formal Definition: The property is defined by the following notation: 2349 calmaster = "CALMASTER" *(";" xparam) ":" uri CRLF 2351 uri = IANA registered uri and defined by RFC 2445 2353 Example: The following is an example of this property: 2355 CALMASTER:mailto:administrator@example.com 2357 8.5 CARID Property 2359 Property Name: CARID 2361 Purpose: This property specifies the identifier for an access right 2362 component. 2364 Value Type: TEXT 2366 Property Parameters: Non-standard property parameters can be 2367 specified on this property. 2369 Conformance: This property MUST BE specified once in a "VCAR" 2370 component. 2372 Description: This property is used in the "VCAR" component to specify 2373 an identifier. A "CARID" property value is unique per container. 2375 Formal Definition: The property is defined by the following notation: 2377 carid = "CARID" *(";" xparam) ":" text CRLF 2379 Example: The following are examples of this property: 2381 CARID:xyzzy-007 2382 CARID:User Rights 2384 8.6 CSID Property 2386 Property Name: CSID 2388 Purpose: The property specifies a the globally unique identifier for 2389 the calendar store. 2391 Value Type: URI 2393 Property Parameters: Non-standard property parameters can be 2394 specified on this property. 2396 Conformance: The property can be specified in a "VCALSTORE" 2397 component. 2399 Description: The identifier MUST BE globally unique. 2401 Formal Definition: The property is defined by the following notation: 2403 csid = "CSID" *(";" xparam) ":" capurl CRLF 2405 Example: The following is an example of this property: 2407 CSID:cap://calendar.example.com 2409 8.7 DECREED Property 2411 Property Name: DECREED 2413 Purpose: This property specifies if an access right calendar 2414 component is decreed or not. 2416 Value Type: BOOLEAN 2418 Property Parameters: Non-standard property parameters can be 2419 specified on this property. 2421 Conformance: This property MAY be specified once in a "VCAR" 2422 component. 2424 Description: This property is used in the "VCAR" component to specify 2425 whether the component is decreed or not. 2427 Formal Definition: The property is defined by the following notation: 2429 decreed = "DECREED" *(";" xparam) ":" boolean CRLF 2431 Example: The following is an example of this property: 2433 DECREED:TRUE 2435 8.8 DEFAULT-CHARSET Property 2437 Property Name: DEFAULT-CHARSET 2439 Purpose: This property indicates the default charset. 2441 Value Type: TEXT 2443 Property Parameters: Non-standard property parameters can be 2444 specified on this property. 2446 Conformance: This property can be specified in "VAGENDA" and 2447 "VCALSTORE" calendar component. 2449 Description: In a "VAGENDA" component, this property is used to 2450 indicate the charset of calendar. If not specified, the default is 2451 the first value in the "VCALSTORE" components "DEFAULT-CHARSET" 2452 property value list. The value MUST BE an IANA registered character 2453 set as defined in [CHARREG]. 2455 In a "VCALSTORE" component it is a comma separated list of charsets 2456 supported by the CS. The first entry is the default entry for all 2457 newly created "VAGENDA" components. The "UTF-8" value MUST BE in the 2458 "VCALSTORE" component "DEFAULT-CHARSET" property list. All compliant 2459 CAP implementations must support the "UTF-8" charset. 2461 If a charset name contains a comma (,), then that comma must be 2462 backslashed escaped in the value. 2464 Formal Definition: The property is defined by the following notation: 2466 default-charset = "DEFAULT-CHARSET" *(";" xparam) 2467 ":" text CRLF 2469 Example: The following is an example of this property for a "VAGENDA" 2470 component: 2472 DEFAULT-CHARSET:Shift_JIS,UTF-8 2474 8.9 DEFAULT-LOCALE Property 2476 Property Name: DEFAULT-LOCALE 2478 Purpose: This property specifies the default language for text 2479 values. 2481 Value Type: TEXT 2483 Property Parameters: Non-standard property parameters can be 2484 specified on this property. 2486 Conformance: This property can be specified in "VAGENDA" and 2487 "VCALSTORE" components. 2489 Description: In a "VAGENDA" component, the "DEFAULT-LOCALE" property 2490 is used to indicate the locale of the calendar. The full locale 2491 SHOULD be used. The default and minimum locale is POSIX (aka the 'C' 2492 locale). 2494 In a "VCALSTORE" component it is a comma separated list of locales 2495 supported by the CS. The first value in the list is the default for 2496 all newly created VAGENDAs. "POSIX" MUST BE in the list. 2498 Formal Definition: The property is defined by the following notation: 2500 default-locale = "DEFAULT-LOCALE" *(";" xparam) 2501 ":" language CRLF 2503 language = Text identifying a locale, as defined in [CHARPOL] 2505 Example: The following is an example of this property: 2507 DEFAULT-LOCALE:en-US.iso-8859-1,POSIX 2509 8.10 DEFAULT-TZID Property 2511 Property Name: DEFAULT-TZID 2513 Purpose: This property specifies the text value that specifies the 2514 default time zone for a calendar. 2516 Value Type: TEXT 2518 Property Parameters: Non-standard property parameters can be 2519 specified on this property. 2521 Conformance: This property may be specified once in a "VAGENDA" and 2522 "VCALSTORE" components. 2524 Description: In a "VAGENDA" component it is the value of the time 2525 zone for the calendar. This time zone is used when as the localtime 2526 for object that contain a date or date-time value without a time 2527 zone. 2529 In a "VCALSTORE" component it is a comma separated list of TZIDs 2530 known to the CS. Where "TZID" property values are the same as the 2531 "TZID" property as defined in [iCAL]. The first entry in the list is 2532 used as the default TZID for all newly created calendars. The list 2533 MUST contain at least "UTC". 2535 If a "TZID" property value contains a comma (,), the comma must be 2536 backslash escaped. 2538 Formal Definition: This property is defined by the following 2539 notation: 2541 default-tzid = "DEFAULT-TZID" *(";" xparam) 2542 ":" [tzidprefix] text CRLF 2544 Example: The following is an example of this property: 2546 DEFAULT-TZID:US/Eastern,UTC 2548 8.11 DEFAULT-VCARS Property 2550 Property Name: DEFAULT-VCARS 2552 Purpose: This property is used to specify the "CARID" property ids of 2553 the default "VCAR" components for newly created "VAGENDA" components. 2555 Value Type: TEXT 2557 Property Parameters: Non-standard property parameters can be 2558 specified on this property. 2560 Conformance: This property MUST BE specified in "VCALSTORE" calendar 2561 component and MUST at least specify the following values: 2562 "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and 2563 "DEFAULTOWNER". 2565 Description: This property is used in the "VCALSTORE" component to 2566 specify the "CARID" value of the "VCAR" components that MUST BE 2567 copied into now "VAGENDA" components at creation time by the CS. All 2568 "DEFAULT-VCAR" values must have "VCARS" components stored in the 2569 "VCALSTORE". 2571 Formal Definition: The property is defined by the following notation: 2573 def-vcars = "DEFAULT-VCARS" *(";" xparam) ":" text 2574 *( "," text ) CRLF 2576 Example: The following is an example of this property: 2578 DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY, 2579 UPDATEPARTSTATUS,DEFAULTOWNER 2581 8.12 DENY Property 2583 Property Name: DENY 2585 Purpose: This property identifies the UPN(s) being denied access in 2586 the "VRIGHT" component. 2588 Value Type: UPN-FILTER 2590 Property Parameters: Non-standard property parameters can be 2591 specified on this property. 2593 Conformance: This property can be specified in "VRIGHT" components. 2595 Description: This property is used in the "VRIGHT" component to 2596 define the CU or UG being denied access. 2598 Formal Definition: The property is defined by the following notation: 2600 deny = "DENY" *(";" xparam) ":" upn-filter CRLF 2602 Example: The following are examples of this property: 2604 DENY:* 2606 DENY:bob@example.com 2608 8.13 EXPAND property 2610 Property Name: EXPAND 2612 Purpose: This property is to notify the CS if it should or should not 2613 expand any component with recurrence rules into multiple instances in 2614 a query reply. 2616 Value Type: BOOLEAN 2618 Property Parameters: Non-standard property parameters can be 2619 specified on this property. 2621 Conformance: This property can be specified in "VQUERY" components. 2623 Description: If a CUA wishes to see all of the instances of a 2624 recurring component the CUA sets EXPAND=TRUE in the "VQUERY" 2625 component. If not specified, the default is FALSE. 2627 Formal Definition: The property is defined by the following notation: 2629 expand = "EXPAND" *(";" xparam) ":" ("TRUE" / "FALSE") CRLF 2631 Example: The following are examples of this property: 2633 EXPAND:FALSE 2634 EXPAND:TRUE 2636 8.14 GRANT Property 2638 Property Name: GRANT 2640 Purpose: This property identifies the UPN(s) being granted access in 2641 the "VRIGHT" component. 2643 Value Type: UPN-FILTER 2645 Property Parameters: Non-standard property parameters can be 2646 specified on this property. 2648 Conformance: This property can be specified in "VRIGHT" calendar 2649 components. 2651 Description: This property is used in the "VRIGHT" component to 2652 specify the CU or UG being granted access. 2654 Formal Definition: The property is defined by the following notation: 2656 grant = "GRANT" *(";" xparam) ":" upn-filter CRLF 2658 Example: The following are examples of this property: 2660 GRANT:* 2662 GRANT:bob@example.com 2664 8.15 MAXDATE Property 2666 Property Name: MAXDATE 2668 Purpose: This property specifies the date/time in the future beyond 2669 which the CS cannot represent. 2671 Value Type: DATE-TIME 2673 Property Parameters: Non-standard property parameters can be 2674 specified on this property. 2676 Conformance: The property can be specified in the "VCALSTORE" 2677 component. 2679 Description: The date and time MUST BE a UTC value and end with 'Z'. 2681 Formal Definition: The property is defined by the following notation: 2683 maxdate = "MAXDATE" *(";" xparam) ":" date-time CRLF 2685 Example: The following is an example of this property: 2687 MAXDATE:20990101T000000Z 2689 8.16 MINDATE Property 2691 Property Name: MINDATE 2693 Purpose: This property specifies the date/time in the past prior to 2694 which the server cannot represent. 2696 Value Type: DATE-TIME 2698 Property Parameters: Non-standard property parameters can be 2699 specified on this property. 2701 Conformance: The property can be specified in the "VCALSTORE" 2702 component. 2704 Description: The date and time MUST BE a UTC value and end with 'Z'. 2706 Formal Definition: The property is defined by the following notation: 2708 mindate = "MINDATE" *(";" xparam) ":" date-time CRLF 2710 Example: The following is an example of this property: 2712 MINDATE:19710101T000000Z 2714 8.17 MULTIPART Property 2716 Property Name: MULTIPART 2718 Purpose: This property provides a comma separated list of supported 2719 MIME multipart types supported by the sender. 2721 Value Type: TEXT 2723 Property Parameters: Non-standard property parameters can be 2724 specified on this property. 2726 Conformance: This property can be specified in a component. 2728 Description: This property is used in the in the "GET-CAPABILITY" 2729 comamnd reply to indicated the MIME multipart types supported. A CS 2730 and CUS SHOULD support all registered MIME multipart types. 2732 Formal Definition: The property is defined by the following notation: 2734 name = "MULTIPART" nameparam ":" text CRLF 2736 nameparam = *( 2737 ; the following is optional, 2738 ; and MAY occur more than once 2740 ( ";" xparam ) 2741 ) 2743 Example: The following is an example of this property: 2745 MULTIPART:related,alternate,mixed 2747 8.18 NAME Property 2749 Property Name: NAME 2751 Purpose: This property provides a localizable display name for a 2752 component. 2754 Value Type: TEXT 2756 Property Parameters: Non-standard property parameters can be 2757 specified on this property. 2759 Conformance: This property can be specified in a component. 2761 Description: This property is used in the in component to specify a 2762 localizable display name. If more than one "NAME" properties are in 2763 a component, then they MUST have unique "LANG" parameters. If the 2764 "LANG" parameter is not supplied, then it defaults to the "VAGENDA" 2765 default if the component is in a "VAGENDA", or the "VCALSTORE" 2766 default if the component is stored at the "VCALSTORE" level. 2768 Formal Definition: The property is defined by the following notation: 2770 name = "NAME" nameparam ":" text CRLF 2772 nameparam = *( 2773 ; the following is optional, 2774 ; but MUST NOT occur more than once 2776 ( ";" languageparam ) / 2778 ; the following is optional, 2779 ; and MAY occur more than once 2781 ( ";" xparam ) 2782 ) 2784 languageparam = ; As defined in [iCAL]. 2786 Example: The following is an example of this property: 2788 NAME:Restrict Guests From Creating VALARMs On VEVENTs 2790 8.19 OWNER Property 2792 Property Name: OWNER 2794 Purpose: The property specifies an owner of the component. 2796 Value Type: UPN 2798 Property Parameters: Non-standard, alternate text representation and 2799 language property parameters can be specified on this property. 2801 Conformance: The property MUST BE specified at in a "VAGENDA" 2802 component. 2804 Description: A multi-instanced property indicating the calendar 2805 owner. 2807 Formal Definition: The property is defined by the following notation: 2809 owner = "OWNER" *(";" xparam) ":" upn CRLF 2811 Example: The following is an example of this property: 2813 OWNER:jsmith@acme.com 2814 OWNER:jdoe@acme.com 2816 8.20 PERMISSION Property 2818 Property Name: PERMISSION 2820 Purpose: This property defines a permission that is granted or denied 2821 in a "VRIGHT" component. 2823 Value Type: TEXT 2825 Property Parameters: Non-standard property parameters can be 2826 specified on this property. 2828 Conformance: This property can be specified in "VRIGHT" components. 2830 Description: This property is used in the "VRIGHT" component to 2831 define a permission that is granted or denied. 2833 Formal Definition: The property is defined by the following notation: 2835 perm = "PERMISSION" *(";" xparam) ":" permvalue CRLF 2837 permvalue = ( "SEARCH" / "CREATE" / "DELETE" / "MODIFY" / all ) 2839 all = "*" 2841 Example: The following is an example of this property: 2843 PERMISSION:SEARCH 2845 8.21 QUERY property 2847 Property Name: QUERY 2849 Purpose: Specifies the query for the component. 2851 Value Type: CAL-QUERY 2853 Property Parameters: Non-standard property parameters can be 2854 specified on this property. 2856 Conformance: This property can be specified in "VQUERY" components. 2858 Description: A "QUERY" is used to specify the "CAL-QUERY" (Section 2859 6.1.1 for the query. 2861 Formal Definition: The property is defined by the following notation: 2863 query = "QUERY" *(";" xparam) ":" cal-query CRLF 2865 Example: The following is an example of this property: 2867 QUERY:SELECT * FROM VEVENT 2869 8.22 QUERYID property 2871 Property Name: QUERYID 2873 Purpose: Specifies a unique ID for a query in the targeted container. 2875 Value Type: TEXT 2877 Property Parameters: Non-standard property parameters are specified 2878 on this property. 2880 Conformance: This property can be specified in "VQUERY" components. 2882 Description: A "QUERYID" property is used to specify the unique id 2883 for a stored query. A "QUERYID" property value is unique per 2884 container. 2886 Formal Definition: The property is defined by the following notation: 2888 queryid = "QUERYID" *(";" xparam) ":" text CRLF 2890 Example: The following are examples of this property: 2892 QUERYID:Any Text String 2893 QUERYID:fetchUnProcessed 2895 8.23 REQUEST-STATUS property 2897 This description is a revision of the "REQUEST-STATUS" property for 2898 VCALENDAR version 2.0. The 'statdesc' is optional and the 'extdata' 2899 may be included when 'statdesc' is not provided. 2901 rstatus = "REQUEST-STATUS" rstatparam ":" 2902 statcode ";" *(statdesc ) ";" *(extdata) 2904 rstatparam = *( 2905 ; the following is optional, 2906 ; but MUST NOT occur more than once 2908 (";" languageparm) / 2910 ; the following is optional, 2911 ; and MAY occur more than once 2913 (";" xparam) 2915 ) 2917 statcode = 1*DIGIT *("." 1*DIGIT) 2918 ;Hierarchical, numeric return status code 2920 statdesc = text 2921 ;An optional textual status description, content is 2922 ;decided by the implementor. May be empty. 2924 extdata = text 2925 ; Textual exception data. For example, the offending 2926 ; property name and value or complete property line. 2928 Example: The following are some possible examples of this property. 2929 The COMMA and SEMICOLON separator characters in the property value 2930 are BACKSLASH character escaped because they appear in a text value. 2932 REQUEST-STATUS:2.0;Success 2934 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 2936 REQUEST-STATUS:2.8; Success\, repeating VEVENT ignored. Scheduled 2937 as a single VEVENT.;RRULE:FREQ=WEEKLY;INTERVAL=2 2939 REQUEST-STATUS:4.1;Time conflict. Date/time is busy. 2941 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: 2942 MAILTO:jsmith@example.com 2944 REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@example.com 2946 REQUEST-STATUS:10.4;Help! That really shouldn't have happened. 2948 8.24 RESTRICTION Property 2950 Property Name: RESTRICTION 2952 Purpose: This property defines restrictions on the result value of 2953 new or existing components. 2955 Value Type: CAL-QUERY 2957 Property Parameters: Non-standard property parameters can be 2958 specified on this property. 2960 Conformance: This property can be specified in "VRIGHT" components, 2961 but only when the "PERMISSION" property is set to "CREATE", "MODIFY", 2962 or "*" property value. 2964 Description: This property is used in the "VRIGHT" component to 2965 define restrictions on the components that can be written (i.e., by 2966 using the "CREATE" or "MOVE" commands) as well as on the values that 2967 may take existent calendar store properties, calendar properties, 2968 components, and properties (i.e., by using the "MODIFY" command). 2969 Accepted values MUST match any specified "RESTRICTION" property 2970 values. 2972 Formal Definition: The property is defined by the following notation: 2974 restrict = "RESTRICTION" *(";" xparam) ":" cal-query CRLF 2975 Example: The following are examples of this property: 2977 RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' 2979 RESTRICTION:SELECT * FROM VEVENT WHERE 2980 SELF() IN ORGANIZER 2982 RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN 2983 CATEGORIES 2985 8.25 SCOPE Property 2987 Property Name: SCOPE 2989 Purpose: This property identifies the objects in the CS to which the 2990 access rights applies. 2992 Value Type: CAL-QUERY 2994 Property Parameters: Non-standard property parameters can be 2995 specified on this property. 2997 Conformance: This property can be specified in "VRIGHT" components. 2999 Description: This property is used in the "VRIGHT" component to 3000 define the set of objects subject to the access right being defined. 3002 Formal Definition: The property is defined by the following notation: 3004 scope = "SCOPE" *(";" xparam) ":" cal-query CRLF 3006 Example: The following is an example of this property: 3008 SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' 3010 8.26 TARGET Property 3012 Property Name: TARGET 3014 Purpose: This property defines the container that the command that is 3015 issued will act upon. Its value is a capurl as defined in Section 5. 3016 The "TARGET" property MUST BE supplied when the CUA sends a command 3017 to the CS. 3019 Value Type: URI 3021 Property Parameters: Non-standard property parameters can be 3022 specified on this property. 3024 Conformance: This property can be specified in a command component. 3026 Description: This property value is used to specify the container 3027 that the command will effect. When used in a command, the command 3028 will be performed on the container which has a capurl matching the 3029 value. 3031 Formal Definition: The property is specified by the following 3032 notation: 3034 target = "TARGET" *(";" xparam) ":" capurl CRLF 3036 The following is an example of this property: 3038 TARGET:cap://mycal.example.com 3039 TARGET:SomeRelCalid 3041 8.27 TRANSP Property 3043 Property Name: TRANSP 3045 Purpose: This property defines whether an component is transparent or 3046 not to busy time searches. This is a modification to [iCAL] "TRANSP" 3047 property in that it adds some values. 3049 Value Type: TEXT 3051 Property Parameters: Non-standard property parameters can be 3052 specified on this property. 3054 Conformance: This property can be specified in a component. 3056 Description: Time Transparency is the characteristic of an object 3057 that determines whether it appears to consume time on a calendar. 3058 Objects that consume actual time for the individual or resource 3059 associated with the calendar SHOULD be recorded as "OPAQUE", allowing 3060 them to be detected by free-busy time searches. Other objects, which 3061 do not take up the individual's (or resource's) time SHOULD be 3062 recorded as "TRANSPARENT", making them invisible to free-busy time 3063 searches. 3065 Formal Definition: The property is specified by the following 3066 notation: 3068 transp = "TRANSP" *(";" xparam) ":" transvalue CRLF 3070 transvalue 3071 = "OPAQUE" ;Blocks or opaque on busy time searches. 3072 / "TRANSPARENT" ;Transparent on busy time searches. 3074 / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time 3075 ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects 3076 ; can overlap it. 3078 / "OPAQUE-NOCONFLICT" ; Opaque on busy time 3079 ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects 3080 ; can overlap it. 3081 ; 3082 ;Default value is OPAQUE 3084 The following is an example of this property for an object that is 3085 opaque or blocks on free/busy time searches plus no other object can 3086 overlap it: 3088 TRANSP:OPAQUE-NOCONFLICT 3090 9. New Components 3092 9.1 VAGENDA Component 3094 Component Name: VAGENDA 3096 Purpose: Provide a grouping of properties that defines an agenda. 3098 Formal Definition: There are two formats of the "VAGENDA" component. 3099 (1) When it is being created, and (2) how it exists in the 3100 "VCALSTORE" component. A "VAGENDA" component in a "VCALSTORE" 3101 component is defined by the following notation table and ABNF 3102 notation. 3104 The following is a summary of the properties of a calendar. 3106 Name Read Description 3107 Only 3108 ------------------------------------------------------------------ 3109 ALLOW-CONFLICT N This boolean value indicates whether or not 3110 the calendar supports object conflicts. That 3111 is, whether or not any of the components in 3112 the calendar can have a time overlap. MUST BE 3113 FALSE if VCALSTORE ALLOW-CONFLICT is FALSE. 3115 CALID N A unique identifier within the VCALSTORE for 3116 the calendar. MUST NOT BE empty. MUST BE a 3117 relative calid in a VAGENDA. 3119 CALSCALE N The CALSCALE for this calendar. MUST BE from 3120 the VCALSTORE CALSCALE list. The default is 3121 the first entry in the VCALSTORE CALSCALE list. 3123 CREATED Y timestamp of the calendar's create date. 3125 DEFAULT-CHARSET N The charset for this calendar. MUST BE from 3126 the VCALSTORE DEFAULT-CHARSET list. If empty 3127 then it is the first entry in the VCALSTORE 3128 DEFAULT-CHARSET list. 3130 DEFAULT-LOCALE 3131 N The locale for this calendar. MUST BE from 3132 the VCALSTORE DEFAULT-LOCALE list. If empty 3133 then it is the first entry in the VCALSTORE 3134 DEFAULT-CHARSET list. 3136 DEFAULT-TZID N The id of the timezone associated with this 3137 calendar. If empty it is the first entry 3138 in VCALSTORE DEFAULT-TZID. 3140 LAST-MODIFIED Y The timestamp when the properties of the 3141 calendar were last updated. 3143 NAME N Optional display name for this calendar. It 3144 is a localizable string. May be multiple 3145 instance and no two instances may have the 3146 same LANG parameter. All instances MUST have 3147 the LANG parameter. 3149 OWNER N A multi-instanced property indicating the 3150 calendar owner. Each entry returned will be a 3151 UPN. There MUST BE at least one owner. 3153 RELATED-TO N An optional multi-instance property indicating 3154 any relationship to other CALIDs and their CALIDs. 3156 agenda = "BEGIN" ":" "VAGENDA" CRLF 3157 agendaprop 3158 "END" ":" "VAGENDA" CRLF 3160 agendaprop = *( 3161 ; The following MUST occur exactly once. 3162 ; 3163 allow-conflict / calid / calscale / created 3164 / default-charset / default-locale 3165 / default-tzid / last-modified / 3167 ; The following MUST occur at least once. 3168 ; and the value MUST NOT be empty. 3170 / owner 3172 ; The following are optional, 3173 ; and MAY occur more than once. 3175 / name / related-to / iana-token / x-prop / x-comp 3176 ) 3178 When creating a VAGENDA, use the following notation: 3180 agendac = "BEGIN" ":" "VAGENDA" CRLF 3181 agendacprop 3182 "END" ":" "VAGENDA" CRLF 3184 agendacprop = *( 3185 ; The following MUST occur exactly once. 3186 ; 3187 allow-conflict / calid / calscale 3188 / default-charset / default-locale 3189 / default-tzid / 3191 ; The following MUST occur at least once. 3192 ; and the value MUST NOT be empty. 3193 ; 3194 / owner 3196 ; The following are optional, 3197 ; and MAY occur more than once. 3198 ; 3199 / name / related-to / iana-token / x-prop / x-comp 3200 ) 3202 To fetch all of the properties from the targeted "VAGENDA" component. 3203 This does not fetch any components: 3205 SELECT * FROM VAGENDA 3207 To fetch all of the properties from the targeted VAGENDA and all of 3208 the contained components, use the special '*.*' value: 3210 SELECT *.* FROM VAGENDA 3212 9.2 VCALSTORE Component 3214 Component Name: VCALSTORE 3216 Purpose: Provide a grouping of properties that defines a calendar 3217 store. 3219 Formal Definition: A "VCALSTORE" component is defined by the 3220 following table and ABNF notation. The creation of a "VCALSTORE" 3221 component is an administrative task and not part of the CAP protocol. 3223 The following is a summary of the properties of the calendar store. 3225 Name Read Description 3226 Only 3227 ------------------------------------------------------------------- 3228 ALLOW-CONFLICT Y This boolean value indicates Whether or not 3229 the VCALSTORE supports object conflicts. That 3230 is, whether or not any of the objects in any 3231 calendar can overlap. If FALSE, then the CS 3232 does not allow conflicts for any object in any 3233 calendar. How this property is set in the 3234 VCALSTORE is an administrative or implementation 3235 specific issue and is not covered in CAP. 3237 CALSCALE Y A comma separated list of CALSCALEs supported 3238 by this CS. All Calendar CALSCALE properties 3239 MUST BE from this list. MUST contain at least 3240 "GREGORIAN". The default for newly created 3241 calendars is the first entry. How this property 3242 is set in the VCALSTORE is an administrative 3243 or implementation specific issue and is not 3244 covered in CAP. 3246 CALMASTER N URL of contact address for person responsible. 3247 SHOULD BE mailto URL. MUST BE an IANA registered 3248 URL scheme. This is to allow external entities a 3249 contact point for the CS. 3251 CHILDREN N A multi instance property that lists all of the 3252 calendars in this VCALSTORE. The values are the 3253 relative CSID for each calendar. 3255 CREATED Y The timestamp of the CS creation time. 3257 CSID Y The CSID of this calendar store. MUST NOT be 3258 empty. How this property is set in the VCALSTORE 3259 is an administrative or implementation specific 3260 issue and is not covered in CAP. 3262 DEFAULT-CHARSET Y A comma separated lists of charsets supported 3263 by this CS. MUST contain at least "UTF-8". 3264 The first is the default for all newly created 3265 calendars. How this property is set in the 3266 VCALSTORE is an administrative or implementation 3267 specific issue and is not covered in CAP. 3269 DEFAULT-LOCALE Y A comma separated list of locales supported 3270 by this CS. MUST contain at least one entry. 3271 ("en_US" for example). The first is the default 3272 for all newly created calendars. There is 3273 no default for this property in the VCALSTORE. 3275 DEFAULT-VCARS N A multivalued property containing the CARID's for 3276 the default VCARs for newly created top level 3277 calendars. It MUST include at a minimum 3278 READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, 3279 and DEFAULTOWNER. 3281 DEFAULT-TZID N A comma separated list of TZID's supported by 3282 the CS. These will be known across all calendars. 3283 Calendar entries take precedence if they exist 3284 in both the CS and calendar. It MUST include at least 3285 UTC. First entry is default for all newly created 3286 calendars. 3288 LAST-MODIFIED Y The timestamp when the Properties of the CS 3289 were last updated or calendars were created 3290 or deleted. 3292 NAME N Optional, multi instance display names for 3293 this CS. It is a localizable string. May 3294 be multiple instance and no two instances may 3295 have the same LANG parameter. All instances 3296 MUST have the LANG parameter in the VCALSTORE. 3298 RELATED-TO N An optional multi-instance property indicating 3299 any relationship to other CSs and those CALIDs. 3301 calstorec = "BEGIN" ":" "VCALSTORE" CRLF 3302 calstoreprop 3303 "END" ":" "VCALSTORE" CRLF 3305 calstoreprop = *( 3307 ; the following MUST occur exactly once 3309 allow-conflict / calscale / calmaster 3310 / created / csid / default-charset 3311 / default-locale / default-vcars 3312 / default-tzid / last-modified 3314 ; the following are optional, 3315 ; and MAY occur more than once 3317 / children / name / related-to 3319 ) 3321 To fetch all of the properties from the targeted VCALSTORE and not 3322 fetch the calendars that it contains: 3324 SELECT * FROM VCALSTORE 3326 To fetch all of the properties from the targeted "VCALSTORE" 3327 component and all of the contained calendars and all of those 3328 calendars contained properties and components, use the special '*.*' 3329 value: 3331 SELECT *.* FROM VCALSTORE 3333 9.3 VCAR Component 3335 Component Name: VCAR 3337 Purpose: Provide a grouping of calendar access rights. 3339 Formal Definition: A "VCAR" component is defined by the following 3340 notation: 3342 carc = "BEGIN" ":" "VCAR" CRLF 3343 carprop 1*rightc 3344 "END" ":" "VCAR" CRLF 3346 carprop = 1*( 3348 ; 'carid' is REQUIRED, 3349 ; but MUST NOT occur more than once 3351 carid / 3353 ; the following are OPTIONAL, 3354 ; and MAY occur more than once 3356 name / x-prop / iana-prop 3357 ) 3359 Description: A "VCAR" component is a grouping of properties, and 3360 "VRIGHT" components, that represents access rights granted or denied 3361 to UPNs. 3363 The "CARID" property specifies the local identifier for the "VCAR" 3364 component. The "NAME" property specifies a localizable display name. 3366 Example: In the following example, the UPN "foo@example.com" is given 3367 search access to the "DTSTART" and "DTEND" VEVENT properties. No 3368 other access is specified: 3370 BEGIN:VCAR 3371 CARID:View Start and End Times 3372 NAME:View Start and End Times 3373 BEGIN:VRIGHT 3374 GRANT:foo@example.com 3375 PERMISSION:SEARCH 3376 SCOPE:SELECT DTSTART,DTEND FROM VEVENT 3377 END:VRIGHT 3378 END:VCAR 3380 In this example, all UPNs are given search access to "DTSTART" and 3381 "DTEND" properties of VEVENT components. "All CUs and UGs" are 3382 specified by the UPN value "*". Note that this enumerated UPN value 3383 is not in quotes: 3385 BEGIN:VCAR 3386 CARID:ViewStartEnd2 3387 NAME:View Start and End Times 2 3388 BEGIN:VRIGHT 3389 GRANT:* 3390 PERMISSION:SEARCH 3391 SCOPE:SELECT DTSTART,DTEND FROM VEVENT 3392 END:VRIGHT 3393 END:VCAR 3395 In these examples, full calendar access rights are given to the CAL- 3396 OWNERS(), and a hypothetical administrator is given access rights to 3397 specify calendar access rights. If no other rights are specified, 3398 only these two UPNs can specify calendar access rights: 3400 BEGIN:VCAR 3401 CARID:some-id-3 3402 NAME:Only OWNER or ADMIN Settable VCARs 3403 BEGIN:VRIGHT 3404 GRANT:CAL-OWNERS() 3405 PERMISSION:* 3406 SCOPE:SELECT * FROM VAGENDA 3407 END:VRIGHT 3408 BEGIN:VRIGHT 3409 GRANT:cal-admin@example.com 3410 PERMISSION:* 3411 SCOPE:SELECT * FROM VCAR 3412 RESTRICTION:SELECT * FROM VCAR 3413 END:VRIGHT 3414 END:VCAR 3416 In this example, rights to write, search, modify or delete calendar 3417 access rights are denied to all UPNs. This example would disable 3418 providing different access rights to the calendar store or calendar. 3419 This calendar access right should be specified with great care, as it 3420 removes the ability to change calendar access; even for the owner or 3421 administrator. It could be used by small devices that do not support 3422 the changing of any VCAR: 3424 BEGIN:VCAR 3425 CARID:VeryRestrictiveVCAR-2 3426 NAME:No CAR At All 3427 BEGIN:VRIGHT 3428 DENY:* 3429 PERMISSION:* 3430 SCOPE:SELECT * FROM VCAR 3431 END:VRIGHT 3432 END:VCAR 3434 9.4 VRIGHT Component 3436 Component Name: "VRIGHT" 3438 Purpose: Provide a grouping of properties that describe an access 3439 right (granted or denied). 3441 Formal Definition: A "VRIGHT" component is defined by the following 3442 notation: 3444 rightc = "BEGIN" ":" "VRIGHT" CRLF 3445 rightprop 3446 "END" ":" "VRIGHT" CRLF 3448 rightprop = 2*( 3450 ; either 'grant' or 'deny' MUST 3451 ; occur at least once 3452 ; and MAY occur more than once 3454 grant / deny / 3456 ; 'permission' MUST occur at least once 3457 ; and MAY occur more than once 3459 permission / 3461 ; the following are optional, 3462 ; and MAY occur more than once 3464 scope / restriction / x-prop / iana-prop 3466 ) 3468 Description: A "VRIGHT" component is a grouping of calendar access 3469 right properties. 3471 The "GRANT" property specifies the UPN that is being granted access. 3472 The "DENY" property specifies the UPN is being denied access. The 3473 "PERMISSION" property specifies the actual permission being set. The 3474 "SCOPE" property identifies the calendar store properties, calendar 3475 properties, components, or properties to which the access right 3476 applies. The "RESTRICTION" property specifies restriction on the 3477 value that may take calendar store properties, calendar properties, 3478 calendar components, and properties after a "CREATE" or "MODIFY" 3479 command. Values MUST match all the instances of the "RESTRICTION" 3480 property to be valid. 3482 9.5 VREPLY Component 3484 Component Name: "VREPLY" 3486 Purpose: Provide a grouping of arbitrary properties and components 3487 that are the data set result from an issued command. 3489 Formal Definition: A "VREPLY" component is defined by the following 3490 notation: 3492 replyc = "BEGIN" ":" "VREPLY" CRLF 3493 any-prop-or-comp 3494 "END" ":" "VREPLY" CRLF 3496 any-prop-or-comp = ; Zero or more iana or experimental 3497 ; properties and components, in any order. 3499 Description: Provide a grouping of arbitrary properties and 3500 components that are the data set result from an issued command. 3502 A query can return a predictable set of arbitrary properties and 3503 components. This component is used by query and other commands to 3504 return data that does not fit into any other component. It may 3505 contain any valid property or component, even if they are not 3506 registered. 3508 9.6 VQUERY Component 3510 Component Name: VQUERY 3512 Purpose: A component to specify what is to be fetched from a CS. 3514 Formal Definition: A "VQUERY" component is defined by the following 3515 notation: 3517 queryc = "BEGIN" ":" "VQUERY" CRLF 3518 queryprop 3519 "END" ":" "VCAR" CRLF 3521 queryprop = 1*( 3523 ; 'queryid' is OPTIONAL but MUST NOT occur 3524 ; more than once. If the "TARGET" property 3525 ; is supplied then the "QUERYID" property 3526 ; MUST BE supplied. 3527 ; 3528 queryid / target 3530 ; the following are OPTIONAL, and MAY occur 3531 ; more than once 3532 ; 3533 / name / x-prop / iana-prop 3535 ; the following MUST occur at least once. 3536 ; 3537 / query 3539 ) 3541 Description: A "VQUERY" contains properties that specify which 3542 properties and components the CS is requested to return during a 3543 SEARCH command. 3545 The "QUERYID" property specifies the local identifier for a stored 3546 "VQUERY" component. The "NAME" property specifies a localizable 3547 display name of a stored "VQUERY" component. Normally "NAME" and 3548 "QUERYID" properties are used when looking for a correct stored 3549 "VQUERY" component, or when storing a "VQUERY" component. 3551 For a search, if the "TARGET" property is supplied in a "VQUERY" 3552 component, then the CS is to search for the query in the calid 3553 supplied by the "TARGET" property value. 3555 For a create the "TARGET" property MUST NOT be supplied as the 3556 destination container is already supplied in the "TARGET" property of 3557 the "VCALENDAR" component. 3559 For examples, see Section 6.1.1. 3561 10. Commands and Responses 3563 CAP commands and responses are described in this section. 3565 10.1 CAP Commands (CMD) 3567 All commands are send using the CMD property. 3569 Property Name: CMD 3571 Purpose: The property defines the command to be sent. 3573 Value Type: TEXT 3575 Property Parameters: Non-standard, id, localize, latency, action or 3576 options. 3578 Conformance: This property is the method used to specify the commands 3579 to a CS and can exist in any object sent to the CS. 3581 Description: All of the command to the CS are supplied in this 3582 property. The "OPTIONS" parameter is overloaded and its meaning is 3583 dependent on the CMD value supplied. 3585 Formal Definition: The property is defined by the following notation: 3587 cmd = "CMD" ( 3588 / abort-cmd 3589 / continue-cmd 3590 / create-cmd 3591 / delete-cmd 3592 / generate-uid-cmd 3593 / get-capability-cmd 3594 / identify-cmd 3595 / modify-cmd 3596 / move-cmd 3597 / reply-cmd 3598 / search-cmd 3599 / set-locale-cmd 3600 ) CRLF 3602 id-param = ";" "ID" "=" unique-id 3603 ; The text value supplied is a unique value 3604 ; shared between the CUA and CS to uniquely 3605 ; identify the instance of command in the 3606 ; the current CUA session. The value has 3607 ; no meaning to other CUAs or other sessions. 3609 unique-id = ; text 3611 localize-param = ";" "LOCALIZE" "=" beep-localize 3612 ; The value supplied MUST BE one value from the initial 3613 ; BEEP greeting 'localize' attribute specifying 3614 ; the locale to use for error messages during 3615 ; this instance of the command sent. 3617 beep-localize = ; text 3619 latency-param = ";" "LATENCY" "=" latency-sec 3620 ; The value supplied in the time in seconds. 3621 ; If latency is supplied then action MUST BE 3622 ; supplied. 3624 latency-sec = integer 3626 action-parm = ";" "ACTION" "=" ( "ASK" / "ABORT" ) 3627 ; If latency is supplied then action MUST BE 3628 ; supplied. 3630 option-param = ";" "OPTIONS" "=" cmd-specific 3632 cmd-specific = ; The value supplied is dependent on the 3633 ; CMD value. See the specific CMDs below 3634 ; for the correct values to use for each 3635 ; CMD. 3637 option-value = paramtext 3639 Calendaring commands allow a CUA to directly manipulate a calendar. 3641 Calendar access rights can be granted or denied for any commands. 3643 10.1.1 Bounded Latency 3645 A CAP command can have an associated maximum latency time by 3646 specifying the "LATENCY" parameter. If the command is unable to be 3647 completed in the specified amount of time (as specified by the 3648 "LATENCY" parameter value), then a "TIMEOUT" command MUST BE sent on 3649 the same channel to which there MUST BE a an "ABORT" or a "CONTINUE" 3650 command reply. If the CUA initiated the original command, then the 3651 CS would issue the "TIMEOUT" command and the CUA would then have to 3652 issue an "ABORT" or "CONTINUE" command. If the CS initiated the 3653 original command then the CUA would have to issue the "TIMEOUT" and 3654 the CS would send the "ABORT" or "CONTINUE". 3656 Upon receiving an "ABORT" command, the command must then be 3657 terminated. Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE" 3658 commands can not be aborted. The "ABORT", "TIMEOUT", and "REPLY" 3659 commands MUST NOT have latency set. 3661 Upon receiving a "CONTINUE" command the work continues. Note that a 3662 new latency time MAY BE included in a "CONTINUE" command indicating 3663 to continue the original command until the "LATENCY" parameter value 3664 expires or the results of the original command can be returned. 3666 Both the "LATENCY" parameter and the "ACTION" parameter MUST BE 3667 supplied to any "CMD" property, or nether can be added to the "CMD" 3668 property. The "LATENCY" parameter MUST BE set to the maximum latency 3669 time in seconds. The "ACTION" parameter accepts the following 3670 values: "ASK" and "ABORT" parameters. 3672 If the maximum latency time is exceeded and the "ACTION" parameter is 3673 set to the "ASK" value, then "TIMEOUT" command MUST BE sent. 3674 Otherwise if the "ACTION" parameter is set to the "ABORT" value then 3675 the command MUST BE terminated and return a REQUEST-STATUS code of 3676 2.0.3 for the original command. 3678 If a CS can both start sending the reply to a command and guarantee 3679 that all of the results can be sent from a command (short of 3680 something like network or power falure), prior to the "LATENCY" 3681 timeout value, then the "LETENCY" time has not expired. 3683 Example: 3685 In this example the initiator asks for the listeners capabilities. 3687 I: Content-Type: text/calendar 3688 I: 3689 I: BEGIN:VCALENDAR 3690 I: VERSION:2.0 3691 I: PRODID:The CUA's PRODID 3692 I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY 3693 I: END:VCALENDAR 3695 # After 3 seconds 3697 L: Content-Type: text/calendar 3698 L: 3699 L: BEGIN:VCALENDAR 3700 L: PRODID:-//someone's prodid 3701 L: VERSION:2.0 3702 L: CMD;ID=xyz12346:TIMEOUT 3703 L: END:VCALENDAR 3705 In order to continue and give the CS more time then the CUA would 3706 issue a "CONTINUE" command: 3708 I: Content-Type: text/calendar 3709 I: 3710 I: BEGIN:VCALENDAR 3711 I: VERSION:2.0 3712 I: PRODID:-//someone's prodid 3713 I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE 3714 I: END:VCALENDAR 3716 L: Content-Type: text/calendar 3717 L: 3718 L: BEGIN:VCALENDAR 3719 L: VERSION:2.0 3720 L: PRODID:-//someone's prodid 3721 L: CMD;ID=xyz12346:REPLY 3722 L: BEGIN:VREPLY 3723 L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds 3724 L: END:VREPLY 3725 L: END:VCALENDAR 3727 To abort the command and not wait any further then issue an "ABORT" 3728 command: 3730 I: Content-Type: text/calendar 3731 I: 3732 I: BEGIN:VCALENDAR 3733 I: VERSION:2.0 3734 I: PRODID:-//someone's prodid 3735 I: CMD;ID=xyz12346:ABORT 3736 I: END:VCALENDAR 3738 # Which would result in a 2.0.3 reply. 3740 L: Content-Type: text/calendar 3741 L: 3742 L: BEGIN:VCALENDAR 3743 L: VERSION:2.0 3744 L: PRODID:-//someone's prodid 3745 L: CMD;ID=xyz12346:REPLY 3746 L: BEGIN:VREPLY 3747 L: REQUEST-STATUS:2.0.3;Aborted As Requested. 3748 L: END:VREPLY 3749 L: END:VCALENDAR 3751 10.1.2 ABORT Command 3753 CMD: ABORT 3755 Purpose: The "ABORT" command is sent to request that the named or 3756 only in process command be aborted. Latency MUST not be supplied 3757 with the "ABORT" command. 3759 Formal Definition: An "ABORT" command is defined by the following 3760 notation: 3762 abort-cmd = abortparam ":" "ABORT" 3764 abortparam = *( 3766 ; the following are optional, 3767 ; but MUST NOT occur more than once 3769 id-param 3770 / localize-param 3772 ; the following is optional, 3773 ; and MAY occur more than once 3775 / (";" xparam) 3777 ) 3779 The REPLY of any "ABORT" command is: 3781 abort-reply = "BEGIN" ":" "VCALENDAR" CRLF 3782 calprops 3783 abort-vreply 3784 "END" ":" "VCALENDAR" CRLF 3786 abort-vreply = "BEGIN" ":" "VREPLY" CRLF 3787 request-status 3788 *(x-prop) 3789 "END" ":" "VREPLY" CRLF 3791 10.1.3 CONTINUE Command 3793 CMD: CONTINUE 3795 Purpose: The "CONTINUE" command is only sent after a "TIMEOUT" 3796 command has been received to inform the other end of the session to 3797 resume working on a command. 3799 Formal Definition: A "CONTINUE" command is defined by the following 3800 notation: 3802 continue-cmd = continueparam ":" "CONTINUE" 3804 continueparam = *( 3805 ; the following are optional, 3806 ; but MUST NOT occur more than once 3808 id-param 3809 / localize-param 3810 / latency-param 3812 ; the following MUST occur exactly once and only 3813 ; when the latency-param has been supplied and 3814 ; MUST NOT be supplied if the latency-param is 3815 ; not supplied. 3817 / action-param 3819 ; the following is optional, 3820 ; and MAY occur more than once 3822 / (";" xparam) 3824 ) 3826 The REPLY of any "CONTINUE" command is: 3828 continue-reply = "BEGIN" ":" "VCALENDAR" CRLF 3829 calprops 3830 continue-vreply 3831 "END" ":" "VCALENDAR" CRLF 3833 continue-vreply = "BEGIN" ":" "VREPLY" CRLF 3834 request-status 3835 *(x-prop) 3836 "END" ":" "VREPLY" CRLF 3838 10.1.4 CREATE Command 3840 CMD: CREATE 3842 Purpose: The "CREATE" command is used to create one or more 3843 iCalendar objects in the store in the "BOOKED" or "UNPROCESSED" 3844 state. 3846 A CUA MAY send a "CREATE" command to a CS. The "CREATE" command MUST 3847 BE implemented by all CSs. 3849 The CS MUST NOT send a "CREATE" command to any CUA. 3851 Formal Definition: A "CREATE" command is defined by the following 3852 notation: 3854 create-cmd = createparam ":" "CREATE" 3856 createparam = *( 3858 ; the following are optional, 3859 ; but MUST NOT occur more than once 3861 id-param 3862 / localize-param 3863 / latency-param 3865 ; the following MUST occur exactly once and only 3866 ; when the latency-param has been supplied and 3867 ; MUST NOT be supplied if the latency-param is 3868 ; not supplied. 3870 / action-param 3872 ; the following is optional, 3873 ; and MAY occur more than once 3875 / (";" xparam) 3877 ) 3879 Response: 3881 One iCalendar object per TARGET property MUST BE returned. 3883 The REPLY of any "CREATE" command is: 3885 Restriction Table for the iCalendar section of a reply that contains 3886 an iCalendar object is any valid [iTIP] response plus any from this 3887 restriction table: 3889 create-reply = "BEGIN" ":" "VCALENDAR" CRLF 3890 calprops 3891 1*(create-vreply) 3892 "END" ":" "VCALENDAR" CRLF 3894 create-vreply = "BEGIN" ":" "VREPLY" CRLF 3895 created-id 3896 request-status 3897 *(x-prop) 3898 "END" ":" "VREPLY" CRLF 3900 ; Where the id is appropriate for the 3901 ; type of object created: 3902 ; 3903 ; VAGENDA = calid 3904 ; VCAR = carid 3905 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 3906 ; VQUERY = queryid 3907 ; x-component = x-id 3908 ; 3909 created-id = ( calid / carid / uid / queryid / 3910 tzid / sequence / x-id) 3912 The "TARGET" property specifies the containers where the component(s) 3913 will be created. This can be a "CSID", or a "CALID" value type. 3915 If the iCalendar object being created does not have a "METHOD" 3916 property, then is not an [iTIP] object, then its state will be 3917 "BOOKED". Use the "DELETE" command to set the state of an object to 3918 the "DELETED" state. A CUA can not use the "CREATE" command to 3919 create an object in the "DELETED" state. 3921 If an [iTIP] object is being booked, then the "METHOD" property MUST 3922 NOT BE supplied". Otherwise any [iTIP] object MUST have a valid 3923 [iTIP] "METHOD" property value and it is a scheduling request being 3924 deposited into the CS and will have its state set to "UNPROCESSED" 3925 state. 3927 Restriction table for the "CREATE" command: 3929 create-minimum = "BEGIN" ":" "VCALENDAR" CRLF 3930 calprops 3931 *(iana-prop) 3932 *(x-prop) 3933 1*(create-comp) 3934 "END" ":" "VCALENDAR" CRLF 3936 ; If The following contain the "METHOD" 3937 ; property they MUST conform to [iTIP]. 3938 ; 3939 create-comp = agendac / carc / queryc 3940 / timezonec / freebusyc 3941 / eventc / todoc / journalc 3942 / iana-comp / x-component 3944 In the following example, two new top level "VAGENDA" components are 3945 created. Note that the "CSID" value of the server is 3946 cal.example.com which is where the new "VAGENDA" components are 3947 going to be created. 3949 C: Content-Type: text/calendar 3950 C: 3951 C: BEGIN:VCALENDAR 3952 C: PRODID:-//someone's prodid 3953 C: VERSION:2.0 3954 C: CMD;ID=creation01:CREATE 3955 C: TARGET:cal.example.com 3956 C: BEGIN:VAGENDA <- data for 1st new calendar 3957 C: CALID:relcalz1 3958 C: NAME;LANGUAGE=en_US:Bill's Soccer Team 3959 C: OWNER:bill 3960 C: CALMASTER:mailto:bill@example.com 3961 C: TZID:US/Pacific 3962 C: END:VAGENDA 3963 C: BEGIN:VAGENDA <- data for 2nd new calendar 3964 C: CALID:relcalz2 3965 C: NAME;LANGUAGE=EN-us:Mary's personal calendar 3966 C: OWNER:mary 3967 C: CALMASTER:mailto:mary@example.com 3968 C: TZID:US/Pacific 3969 C: END:VAGENDA 3970 C: END:VCALENDAR 3972 When there are multiple "TARGET" properties in the original command 3973 object then the replies MUST BE in the exact same order as they were 3974 provided to the CS. The same is true for the objects created, their 3975 responses MUST BE in the exact same order as they were supplied to 3976 the CS. 3978 S: Content-Type: text/calendar 3979 S: 3980 S: BEGIN:VCALENDAR 3981 S: VERSION:2.0 3982 S: PRODID:-//someone's prodid 3983 S: CMD;ID=creation01:REPLY 3984 S: TARGET:cal.example.com 3985 S: BEGIN:VREPLY <- Reply for 1st calendar create 3986 S: CALID:relcalz1 3987 S: REQUEST-STATUS:2.0 3988 S: END:REPLY 3989 S: BEGIN:VREPLY <- Reply for 2nd calendar create 3990 S: CALID:relcalz2 3991 S: REQUEST-STATUS:2.0 3992 S: END:VREPLY 3993 S: END:VCALENDAR 3995 To create a new component in multiple containers simply name all of 3996 the containers in the "TARGET" in the create command. Here a new 3997 "VEVENT" component is created in two TARGET components. In this 3998 example, the "VEVENT" component is one new [iTIP] "REQUEST" to be 3999 stored in two calendars. The results would be iCalendar objects that 4000 conform to the [iTIP] replies as defined in [iTIP]. 4002 The "VREPLY" components MUST always be returned in the same order 4003 that the objects were listed in the original "CREATE" command. If 4004 there are multiple "TARGET" properties and components in the same 4005 create command then the reply is first listed by the "TARGET" order 4006 of the original create command, then component replies within that 4007 "TARGET" are ordered the same as in the original create command. 4009 This example shows two "VEVENT" components being created in each of 4010 the two supplied "TARGET" properties: 4012 C: Content-Type: text/calendar 4013 C: 4014 C: BEGIN:VCALENDAR 4015 C: VERSION:2.0 4016 C: PRODID:-//someone's prodid 4017 C: CMD;ID=creation02:CREATE 4018 C: METHOD:REQUEST 4019 C: TARGET:relcalz1 4020 C: TARGET:relcalz2 4021 C: BEGIN:VEVENT 4022 C: DTSTART:20030307T180000Z 4023 C: UID:FirstInThisExample-1 4024 C: DTEND:20030307T190000Z 4025 C: SUMMARY:Important Meeting 4026 C: END:VEVENT 4027 C: BEGIN:VEVENT 4028 C: DTSTART:20040307T180000Z 4029 C: UID:SecondInThisExample-2 4030 C: DTEND:20040307T190000Z 4031 C: SUMMARY:Important Meeting 4032 C: END:VEVENT 4033 C: END:VCALENDAR 4035 The CS could send the "VREPLY" commands in separate MIME objects, one 4036 per supplied "TARGET" property value. 4038 S: Content-Type: text/calendar 4039 S: 4040 S: BEGIN:VCALENDAR 4041 S: VERSION:2.0 4042 S: PRODID:-//someone's prodid 4043 S: CMD;ID=creation02:REPLY 4044 S: TARGET:relcalz1 <- 1st TARGET listed 4045 S: BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET. 4046 S: UID:FirstInThisExample-1 4047 S: REQUEST-STATUS:2.0 4048 S: END:VREPLY 4049 S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET. 4050 S: UID:SecondInThisExample-2 4051 S: REQUEST-STATUS:2.0 4052 S: END:VREPLY 4053 S: END:VCALENDAR 4055 And could send the second part of the reply later: 4057 S: Content-Type: text/calendar 4058 S: 4059 S: BEGIN:VCALENDAR 4060 S: VERSION:2.0 4061 S: PRODID:-//someone's prodid 4062 S: CMD;ID=creation02:REPLY 4063 S: TARGET:relcalz2 <- 2nd TARGET listed 4064 S: BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET. 4065 S: UID:FirstInThisExample-1 4066 S: REQUEST-STATUS:2.0 4067 S: END:VREPLY 4068 S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET. 4069 S: UID:SecondInThisExample-2 4070 S: REQUEST-STATUS:2.0 4071 S: END:VREPLY 4072 S: END:VCALENDAR 4074 10.1.5 DELETE Command 4076 CMD: DELETE 4078 Purpose: The "DELETE" command physically removes the QUERY result 4079 from the store or marks it for deletion. 4081 A CUA MAY send a "DELETE" command to a CS. The "DELETE" command MUST 4082 BE implemented by all CSs. 4084 The CS MUST NOT send a "DELETE" command to any CUA. 4086 Formal Definition: A "DELETE" command is defined by the following 4087 notation: 4089 delete-cmd = deleteparam ":" "DELETE" 4091 deleteparam = *( 4093 ; the following are optional, 4094 ; but MUST NOT occur more than once 4096 id-param 4097 / localize-param 4098 / latency-param 4099 / option-param "MARK" 4101 ; The following MUST occur exactly once and only 4102 ; when the latency-param has been supplied and 4103 ; MUST NOT be supplied if the latency-param is 4104 ; not supplied. 4106 / action-param 4108 ; the following is optional, 4109 ; and MAY occur more than once 4111 / (";" xparam) 4113 ) 4115 The "DELETE" command is used to delete calendars or components. The 4116 included "VQUERY" component(s) specifies the container(s) to delete. 4118 If a component is to be marked for delete and not physically removed, 4119 then include the "OPTIONS" parameter with its value set to the "MARK" 4120 value in order to alter its state to "DELETED". 4122 When components are deleted, only the top most component "REQUEST- 4123 STATUS" properties are returned. No "REQUEST-STATUS" properties are 4124 returned for components inside of the selected components. There 4125 MUST BE one "VREPLY" component returned for each object that is 4126 deleted or marked for delete. 4128 Restriction Table for the "REPLY" command for any "DELETE" command. 4130 delete-reply = "BEGIN" ":" "VCALENDAR" CRLF 4131 calprops 4132 1*(delete-vreply) 4133 "END" ":" "VCALENDAR" CRLF 4135 delete-vreply = "BEGIN" ":" "VREPLY" CRLF 4136 deleted-id 4137 request-status 4138 "END" ":" "VREPLY" CRLF 4140 ; Where the id is appropriate for the 4141 ; type of object deleted: 4142 ; 4143 ; VAGENDA = calid 4144 ; VCAR = carid 4145 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 4146 ; VQUERY = queryid 4147 ; ALARM = sequence 4148 ; x-component = x-id 4149 ; 4150 deleted-id = ( calid / carid / uid / uid dtstamp 4151 / queryid / tzid / sequence / x-id ) 4153 Example to delete a "VEVENT" component with "UID" value of 4154 'abcd12345' from the calendar "relcald-22" from the current CS: 4156 C: Content-Type: text/calendar 4157 C: 4158 C: BEGIN:VCALENDAR 4159 C: TARGET:relcalid-22 4160 C: CMD;ID:"random but unique per CUA":DELETE 4161 C: BEGIN:VQUERY 4162 C: QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' 4163 C: END:VQUERY 4164 C: END:VCALENDAR 4166 S: BEGIN:VCALENAR 4167 S: TARGET:relcalid-22 4168 S: CMD;ID:"random but unique per CUA":REPLY 4169 S: BEGIN:VREPLY 4170 S: UID:abcd12345 4171 S: REQUEST-STATUS:3.0 4172 S: END:VREPLY 4173 S: END:VCALENDAR 4175 One or more iCalendar objects will be returned that contain a 4176 "REQUEST-STATUS" properties for the deleted components. There could 4177 have been more than one component deleted, Any booked and any number 4178 of unprocessed [iTIP] scheduling components that matched the QUERY 4179 value in the above example. Each unique "METHOD" property value that 4180 was deleted from the store MUST BE in a separate iCalendar object. 4181 This is because only one "METHOD" property is allowed in a single 4182 "VCALENDAR" BEGIN/END block. 4184 10.2 GENERATE-UID Command 4186 CMD: GENERATE-UID 4188 Purpose: The "GENERATE-UID" command returns one or more unique 4189 identifiers which MUST BE globally unique. 4191 The "GENERATE-UID" command MAY BE sent to any CS. The "GENERATE-UID" 4192 command MUST BE implemented by all CSs. 4194 The "GENERATE-UID" command MUST NOT be sent to a CUA. 4196 Formal Definition: A "GENERATE-UID" command is defined by the 4197 following notation: 4199 generate-uid-cmd = genuidparam ":" "GENERATE-UID" 4201 genuidparam = *( 4202 ; The following are optional, 4203 ; but MUST NOT occur more than once. 4205 id-param 4206 / localize-param 4207 / latency-param 4209 ; The following MUST occur exactly once and only 4210 ; when the latency-param has been supplied and 4211 ; MUST NOT be supplied if the latency-param is 4212 ; not supplied. 4214 / action-param 4216 ; The following is optional, 4217 ; and MAY occur more than once. 4219 / (";" xparam) 4221 ; The following MUST BE supplied exactly once. 4222 ; The value specifies the number of UIDs to 4223 ; be returned. 4225 / option-param integer 4227 ) 4229 Response: 4231 gen-reply = "BEGIN" ":" "VCALENDAR" CRLF 4232 calprops 4233 1*(gen-vreply) 4234 "END" ":" "VCALENDAR" CRLF 4236 gen-vreply = "BEGIN" ":" "VREPLY" CRLF 4237 *(uid) 4238 request-status 4239 "END" ":" "VREPLY" CRLF 4241 Example: 4243 C: BEGIN:VCALENDAR 4244 C: VERSION:2.0 4245 C: PRODID:-//someone's prodid 4246 C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID 4247 C: END:VCALENDAR 4248 S: Content-Type: text/calendar 4249 S: 4250 S: BEGIN:VCALENDAR 4251 S: VERSION:2.0 4252 S: PRODID:-//someone's prodid 4253 S: CMD;ID=unique-per-cua-124:REPLY 4254 S: BEGIN:VREPLY 4255 S: UID:20011121T120000Z-12340@cal.example.com 4256 S: UID:20011121T120000Z-12341@cal.example.com 4257 S: UID:20011121T120000Z-12342@cal.example.com 4258 S: UID:20011121T120000Z-12343@cal.example.com 4259 S: UID:20011121T120000Z-12344@cal.example.com 4260 S: REQUEST-STATUS:2.0 4261 S: END:VREPLY 4262 S: END:VCALENDAR 4264 10.3 GET-CAPABILITY Command 4266 CMD: GET-CAPABILITY 4268 Purpose: The "GET-CAPABILITY" command returns the capabilities of the 4269 other end of the session. 4271 A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial 4272 connection. The "GET-CAPABILITY" command MUST BE implemented by all 4273 CSs. 4275 The CS MUST send a "GET-CAPABILITY" command to a CUA after the 4276 initial connection. The CUA MUST recogonize the "GET-CAPABILITY" 4277 command and MAY return a not implemented reply meaning that the CUA 4278 supports only the default capababilities. 4280 Formal Definition: A "GET-CAPABILITY" command is defined by the 4281 following notation: 4283 get-capability-cmd = capibiltyparam ":" "GET-CAPABILITY" 4285 capibiltyparam = *( 4287 ; the following are optional, 4288 ; but MUST NOT occur more than once 4289 ; 4290 id-param / localize-param / latency-param 4292 ; the following MUST occur exactly once and only 4293 ; when the latency-param has been supplied and 4294 ; MUST NOT be supplied if the latency-param is 4295 ; not supplied. 4296 ; 4297 / action-param 4299 ; the following is optional, 4300 ; and MAY occur more than once 4301 ; 4302 / (";" xparam) 4304 ) 4306 Response: 4308 The "GET-CAPABILITY" command returns information about the Calendar 4309 other end of the session given the current state of the connection. 4310 The values returned may differ depending on current user identify and 4311 the security level of the connection. 4313 Client implementations SHOULD NOT require any capability element 4314 beyond those defined in this specification, and MAY ignore any 4315 nonstandard, experimental capability elements. The "GET-CAPABILITY" 4316 reply may return different results depending on the UPN and if the 4317 UPN is authenticated. 4319 When sending a reply to a "GET-CAPABILITY" command, all of these MUST 4320 BE supplied. If the CUA does not support sending a full reply and 4321 sends not-implemented error, then the CS MUST assume the CUA supports 4322 the default values as defined below. A CS MUST always send the full 4323 reply when queried. 4325 When the CUA does not support sending a "GET-CAPABILITY" reply, then 4326 the CS MUST assume the defaults listed below. The following 4327 properties are returned in response to a "GET-CAPABILITY" command: 4329 Name Occurs Description 4331 ------------------------------------------------------------------ 4332 CAP-VERSION 1 Version of CAP. It MUST include at least "1.0" 4333 for this version of CAP. Like the "VERSION" 4334 property, it may have a range. Uses the exact 4335 same syntax as the "VERSION" property value. 4336 The default is "1.0". 4338 CAR-LEVEL 1 Indicates level of CAR support. CAR-NONE, 4339 CAR-MIN or CAR-FULL-1. If CAR-FULL-1 is 4340 supplied then CAR-MIN MUST BE assumed. 4341 A CAR-MIN implementation only supports 4342 the DEFAULT-VCARS listed in the VCALSTORE 4343 and does not support the creation or 4344 modification of VCARS. 4345 The default is CAR-NONE. 4347 COMPONENTS 1 A comma separated list of the names of 4348 components that are supported. This 4349 includes any components inside of 4350 other components (VALARM for example). 4351 It MUST include at least VCALSTORE, VCALENDAR, 4352 VREPLY, and VAGENDA and at least one of VEVENT, 4353 VTODO, VTIMEZONE, or VJOURNAL. The defalt 4354 is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, 4355 VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO, 4356 DAYLIGHT,STANDARD" 4358 STORES-EXPANDED 4359 1 If TRUE then it expands multiple instances 4360 separately when they are stored (RRULEs 4361 converted to RDATEs) and when sent. If 4362 FALSE then it expands instances dynamically 4363 during sending. Default is FALSE. 4365 DATE-MAX 1 The datetime value in UTC beyond which the 4366 server cannot accept. The default and and 4367 maximum value allowed is 99991231T235959Z. 4369 DATE-MIN 1 The datetime value in UTC prior to which 4370 the server cannot accept. The default and 4371 minimum value allowed is 00000101T000000Z. 4373 ITIP-VERSION 1 Version(s) of ITIP, it MUST include at least 4374 the default value of "2446" to specify 4375 RFC-2446 support. Comma separated list. 4377 MAX-COMPONENT-SIZE 4378 1 A positive integer value that specifies 4379 the size of the largest iCalendar object 4380 that can be accepted in octets. Objects 4381 larger than this will be rejected. A 4382 default value of zero (0) means no limit. 4383 This is also the maximum value of any BEEP 4384 payload that will be accepted or sent. 4386 MULTIPART 1 A comma separated list of MIME multipart 4387 the sender supports in lower case. The 4388 default is no multipart support (empty 4389 list). Example: MULTIPART:related,alternate 4391 PRODID 1 The product id. If supplied in the "VCALENDAR" 4392 components, the values MUST BE identical to 4393 what is sent in the "GET-CAPABILITY" reply 4394 from the CUA or CS. The CUA and CS PRODID 4395 values may differ from each other. 4397 QUERY-LEVEL 1 Indicates level of SQL support. The default 4398 is CAL-QL-1 and CAL-QL-NONE can be supplied. 4399 (CAL-QL-NONE is for CS's that allow ITIP 4400 methods only to be deposited and nothing else). 4401 The default value is CAL-QL-1. 4403 RECUR-ACCEPTED 1 Whether recurrence rules are acceptable. 4404 TRUE (default) or FALSE. 4406 RECUR-EXPAND 1 Whether or not it supports the expansion 4407 of recurrence rules. TRUE (default) or FALSE. 4409 RECUR-LIMIT 1 The maximum number of occurrences of a 4410 recurrence rule that are expanded. 4411 The default of Zero (0) means unlimited. 4413 VERSION 1 Versions of iCalendar support. MUST BE at 4414 least "2.0" (the default). This is the same 4415 property as defined in [iCAL]. 4417 RECUR-ACCEPTED 1 Whether recurrence rules are acceptable. 4418 The default is TRUE. 4420 X-... 0+ May include zero or more experimental 4421 properties. These have no default and 4422 if need to be sent by an implementation, 4423 then all of the above MUST BE sent. 4425 ------------------------------------------------------- 4427 Example: 4429 I: Content-Type: text/calendar 4430 I: 4431 I: BEGIN:VCALENDAR 4432 I: VERSION:2.0 4433 I: PRODID:-//someone's prodid 4434 I: CMD;ID=unique-per-cua-125:GET-CAPABILITY 4435 I: END:VCALENDAR 4437 L: Content-Type: text/calendar 4438 L: 4439 L: BEGIN:VCALENDAR 4440 L: VERSION:2.0 4441 L: PRODID:-//someone's prodid 4442 L: CMD;ID=unique-per-cua-125:REPLY 4443 L: BEGIN:VREPLY 4444 L: CAP-VERSION:1.0 4445 L: PRODID:The CS prodid 4446 L: QUERY-LEVEL:CAL-QL-1 4447 L: CAR-LEVEL:CAR-FULL-1 4448 L: DATE-MAX:99991231T235959Z 4449 L: DATE-MIN:00000101T000000Z 4450 L: MAX-COMPONENT-SIZE:0 4451 L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR, 4452 L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY 4453 L: ITIP-VERSION:2447 4454 L: RECUR-ACCEPTED:TRUE 4455 L: RECUR-EXPAND:TRUE 4456 L: RECUR-LIMIT:0 4457 L: STORES-EXPANDED:FALSE 4458 L: X-INET-PRIVATE-COMMANDS:1.0 4459 L: END:VREPLY 4460 L: END:VCALENDAR 4462 10.4 IDENTIFY Command 4464 CMD: IDENTIFY 4466 Purpose: The "IDENTIFY" command allows the CUA to set a new identity 4467 to be used for calendar access. 4469 A CUA MAY send an "IDENTIFY" command to a CS. The "IDENTIFY" command 4470 MUST BE implemented by all CSs. A CS implementation MAY reject all 4471 "IDENTIFY" commands. 4473 The CS MUST NOT send a "IDENTIFY" command to any CUA. 4475 Formal Definition: A "IDENTIFY" command is defined by the following 4476 notation: 4478 identify-cmd = identifyparam ":" "IDENTIFY" 4480 identifyparam = *( 4482 ; the following are optional, 4483 ; but MUST NOT occur more than once 4485 id-param 4486 / localize-param 4487 / latency-param 4489 ; the following MUST occur exactly once and only 4490 ; when the latency-param has been supplied and 4491 ; MUST NOT be supplied if the latency-param is 4492 ; not supplied. 4494 / action-param 4496 ; the following is optional, 4497 ; and MAY occur more than once 4499 / (";" xparam) 4501 ; The value is the UPN of the requested 4502 ; identity. If not supplied it is a request 4503 ; to return to the original authenticated identity. 4505 / option-param upn 4507 ) 4509 Response: 4511 "REQUEST-STATUS" with only one of the following 4512 request-status codes: 4514 2.0 Successful. 4516 6.4 Identity not permitted. VCAR restriction. 4518 The CS determines through an internal mechanism if the credentials 4519 supplied at authentication permit the operation as the selected 4520 identity. If they do, the session assumes the new identity, 4521 otherwise a security error is returned. 4523 Example: 4525 C: Content-Type: text/calendar 4526 C: 4527 C: BEGIN:VCALENDAR 4528 C: VERSION:2.0 4529 C: PRODID:-//someone's prodid 4530 C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY 4531 C: END:VCALENDAR 4533 S: Content-Type: text/calendar 4534 S: 4535 S: BEGIN:VCALENDAR 4536 S: VERSION:2.0 4537 S: PRODID:-//someone's prodid 4538 S: REQUEST-STATUS:2.0;Request Approved 4539 S: END:VCALENDAR 4541 Or if denied: 4543 S: Content-Type: text/calendar 4544 S: 4545 S: BEGIN:VCALENDAR 4546 S: PRODID:-//someone's prodid 4547 S: VERSION:2.0 4548 S: REQUEST-STATUS:6.4;Request Denied 4549 S: END:VCALENDAR 4551 And for the CUA to return to its original authenticated identity 4552 the OPTIONS parameter is omitted: 4554 C: Content-Type: text/calendar 4555 C: 4556 C: BEGIN:VCALENDAR 4557 C: VERSION:2.0 4558 C: PRODID:-//someone's prodid 4559 C: CMD;ID=unique-per-cua-995:IDENTIFY 4560 C: END:VCALENDAR 4562 The CS may accept (2.0) or deny (6.4) the request to return to the 4563 original identity. 4565 If a CS considers the "IDENTIFY" command an attempt to violate 4566 security, the CS MAY terminate the BEEP session without any further 4567 notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. 4569 10.5 MODIFY Command 4571 CMD: MODIFY 4573 Purpose: The "MODIFY" command is used to modify existing components. 4575 A CUA MAY send a "MODIFY" command to a CS. The "MODIFY" command MUST 4576 BE implemented by all CSs. 4578 The CS MUST NOT send a "MODIFY" command to any CUA. 4580 Formal Definition: A "MODIFY" command is defined by the following 4581 notation: 4583 modify-cmd = modifyparam ":" "MODIFY" 4585 modifyparam = *( 4587 ; the following are optional, 4588 ; but MUST NOT occur more than once 4590 id-param 4591 / localize-param 4592 / latency-param 4594 ; the following MUST occur exactly once and only 4595 ; when the latency-param has been supplied and 4596 ; MUST NOT be supplied if the latency-param is 4597 ; not supplied. 4599 / action-param 4601 ; the following is optional, 4602 ; and MAY occur more than once 4604 / (";" xparam) 4606 ) 4608 The "MODIFY" command is used to modify existing components. The 4609 TARGET property specifies the calendars where the components exist 4610 that are going to be modified. 4612 The format of the request is two components inside of "VCALENDAR" 4613 component: 4615 BEGIN:VCALENDAR 4616 ... 4617 BEGIN:VQUERY 4618 ... 4619 END:VQUERY 4620 BEGIN:XXX 4621 ...old-values... 4622 END:XXX 4623 BEGIN:XXX 4624 ...new-values... 4625 END:XXX 4626 END:CALENDAR 4628 The "VQUERY" component selects the components that are to be 4629 modified. 4631 Where "XXX" above is a named component type (VEVENT, VTODO, ...). 4632 Both the old and new components MUST BE of the same type. 4634 The old-values is a component and the contents of that component are 4635 going to change and may contain information that helps uniquely 4636 identify the original component (SEQUENCE in the example below). If 4637 the CS can not find a component that matches the QUERY and does not 4638 have at least all of the OLD-VALUES, then a 6.1 error is returned. 4640 The new-values is a component of the same type as old-values and new- 4641 values contains the new data for each selected component. Any data 4642 that is in old-values and not in new-values is deleted from the 4643 selected component. Any values in new-values that was not in old- 4644 values is added to the component. 4646 In this example the "VEVENT" component with a "UID" property value of 4647 'unique-58' has; the "LOCATION" property and "LAST-MODIFIED" property 4648 changed, the "VALARM" component with the "SEQUENCE" property with a 4649 value of "3" has its "TRIGGER" property disabled, the "X-LOCAL" 4650 property is removed from the "VEVENT" component, and a "COMMENT" 4651 property is added. 4653 Because "SEQUENCE" property is used to locate the "VALARM" component 4654 in this example, both the old-values and the new-values contain the 4655 "SEQUENCE" property with a value of "3" and if the "SEQUENCE" 4656 property were to be left out of new-values, it would have been 4657 deleted. 4659 Example: 4661 C: Content-Type: text/calendar 4662 C: 4663 C: BEGIN:VCALENDAR 4664 C: VERSION:2.0 4665 C: PRODID:-//someone's prodid 4666 C: TARGET:my-cal 4667 C: CMD:ID=unique-mod:MODIFY 4668 C: BEGIN:VQUERY <- Query to select data set. 4669 C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58' 4670 C: END:VQUERY 4671 C: BEGIN:VEVENT <- Start of old data. 4672 C: LOCATION:building 3 4673 C: LAST-MODIFIED:20020101T123456Z 4674 C: X-LOCAL:some private stuff 4675 C: BEGIN:VALARM 4676 C: SEQUENCE:3 4677 C: TRIGGER;RELATED=END:PT5M 4678 C: END:VALARM 4679 C: END:VEVENT 4680 C: BEGIN:VEVENT <- End of new data. 4681 C: LOCATION:building 4 4682 C: LAST-MODIFIED:20020202T010203Z 4683 C: COMMENT:Ignore global trigger. 4684 C: BEGIN:VALARM 4685 C: SEQUENCE:3 4686 C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M 4687 C: END:VALARM 4688 C: END:VEVENT 4690 The "X-LOCAL" property was not supplied in the new-values, so it was 4691 deleted. The "LOCATION" property value was altered, as was the 4692 "LAST-MODIFIED" value. The "VALARM" component with a "SEQUENCE" 4693 property value of "3" had its "TRIGGER" property disabled, and the 4694 "SEQUENCE" property value did not change so it was not effected. The 4695 "COMMENT" property was added. 4697 When it comes to inline ATTACHMENTs, the CUA only needs to uniquely 4698 identify the contents of the ATTACHMENT value in the old-values in 4699 order to delete them. When the CS compares the attachment data it is 4700 compared in its binary form. The ATTACHMENT value supplied by the 4701 CUA MUST BE valid encoded information. 4703 For example, to delete the same huge inline attachment from every 4704 VEVENT in 'my-cal' that has an "ATTACH" property value with the old- 4705 values: 4707 BEGIN:VCALENDAR 4708 VERSION:2.0 4709 PRODID:-//someone's prodid 4710 TARGET:my-cal 4711 CMD:MODIFY 4712 BEGIN:VQUERY 4713 QUERY:SELECT ATTACH FROM VEVENT 4714 END:VQUERY 4715 BEGIN:VEVENT 4716 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: 4717 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U 4718 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE 4719 ...< remainder of attachment data NOT supplied >.... 4720 END:VEVENT 4721 BEGIN:VEVENT 4722 END:VEVENT 4723 END:VCALENDAR 4725 Above the new-values is empty, so everything in the old-values is 4726 deleted. 4728 Furthermore, the following additional restrictions apply: 4730 1. One can not change the "UID" property of a component. 4732 2. If a contained component is changed inside of a selected 4733 component, and that contained component has multiple instances, 4734 then old-values MUST contain information that uniquely identifies 4735 the instance or instances that are changing. It is valid to 4736 change more than one. As all contained components that match 4737 old-values will be modified. In the first modify example above, 4738 if "SEQUENCE" properties were to be deleted from both the old- 4739 values and new-values, then all "TRIGGER" properties that matched 4740 the old-values in all "VALARM" components in the selected 4741 "VEVENT" components would be disabled. 4743 3. The result of the modify MUST BE a valid iCalendar object. 4745 Response: A "VCALENDAR" component is returns with one ore more 4746 "REQUEST-STATUS" property values. 4748 If any error occurred: 4750 No component will be changed at all. That is, it will appear just 4751 as it was prior to the modify and the CAP server SHOULD return a 4752 "REQUEST-STATUS" property for each error that occurred. 4754 There MUST BE at least one error reported. 4756 If multiple components are selected, then what uniquely identified 4757 the component MUST BE returned (UID, QUERYID, ...) if the component 4758 contains a unique identifier. If not, sufficient information to 4759 uniquely identify the modified components MUST BE returned in the 4760 reply. 4762 S: Content-Type: text/calendar 4763 S: 4764 S: BEGIN:VCALENDAR 4765 S: TARGET:relcalid 4766 S: CMD;ID=delete#1:REPLY 4767 S: BEGIN:VREPLY 4768 S: BEGIN:VEVENT 4769 S: UID:123 4770 S: REQUEST-STATUS:2.0 4771 S: END:VEVENT 4772 S: END:VREPLY 4773 S: END:VCALENDAR 4775 10.6 MOVE Command 4777 CMD: MOVE 4779 Purpose: The "MOVE" command is used to move components within the CS. 4781 A CUA MAY send a "MOVE" command to a CS. The "MOVE" command MUST BE 4782 implemented by all CSs. 4784 The CS MUST NOT send a "MOVE" command to any CUA. 4786 Formal Definition: A "MOVE" command is defined by the following 4787 notation: 4789 move-cmd = moveparam ":" "MOVE" 4791 moveparam = *( 4793 ; the following are optional, 4794 ; but MUST NOT occur more than once 4796 id-param 4797 / localize-param 4798 / latency-param 4800 ; the following MUST occur exactly once and only 4801 ; when the latency-param has been supplied and 4802 ; MUST NOT be supplied if the latency-param is 4803 ; not supplied. 4805 / action-param 4807 ; the following is optional, 4808 ; and MAY occur more than once 4810 / (";" xparam) 4812 ) 4814 Response: 4815 The REQUEST-STATUS in a VCALENDAR object. 4817 The content of each "result" is subject to the result restriction 4818 table defined below. 4820 The access control on the "VAGENDA" component after it has been moved 4821 to its new location in the calstore MUST BE at least as secure as it 4822 was prior to the move. If the CS is not able to ensure the same 4823 level of security, a permission denied "REQUEST-STATUS" property 4824 value MUST BE returned and the "MOVE" command not performed. 4826 The "TARGET" property value specifies the new location, and the 4827 "VQUERY" component specifies the old location. 4829 Restriction Table for the "REPLY" command of any "MOVE" command. 4831 move-reply = "BEGIN" ":" "VCALENDAR" CRLF 4832 calprops 4833 1*(move-vreply) 4834 "END" ":" "VCALENDAR" CRLF 4836 move-vreply = "BEGIN" ":" "VREPLY" CRLF 4837 move-id 4838 request-status 4839 "END" ":" "VREPLY" CRLF 4841 ; Where the id is appropriate for the 4842 ; type of object moved: 4843 ; 4844 ; VAGENDA = calid 4845 ; VCAR = carid 4846 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 4847 ; VQUERY = queryid 4848 ; ALARM = sequence 4849 ; x-component = x-id 4850 ; 4851 move-id = ( calid / carid / uid / uid dtstamp 4852 / queryid / tzid / sequence / x-id) 4854 Example: moving the VAGENDA Nellis to Area-51 4855 C: Content-Type: text/calendar 4856 C: 4857 C: BEGIN:VCALENDAR 4858 C: VERSION:2.0 4859 C: PRODID:-//someone's prodid 4860 C: CMD:MOVE 4861 C: TARGET:Area-51 4862 C: BEGIN:VQUERY 4863 C: QUERY: SELECT * FROM VAGENDA WHERE CALID='Nellis' 4864 C: END:VQUERY 4865 C: END:VCALENDAR 4867 S: Content-Type: text/calendar 4868 S: 4869 S: BEGIN:VCALENDAR 4870 S: VERSION:2.0 4871 S: PRODID:-//someone's prodid 4872 S: TARGET:Area-51 4873 S: BEGIN:VREPLY 4874 S: CALID:Nellis 4875 S: REQUEST-STATUS: 2.0 4876 S: END:VREPLY 4877 S: END:VCALENDAR 4879 10.7 REPLY Response to a Command 4881 CMD: REPLY 4883 Purpose: The "REPLY" value to the "CMD" property is used to return 4884 the results of all other commands to the CUA. 4886 A CUA MUST send a "REPLY" command to a CS for any command a CS MAY 4887 send to the CUA. The "REPLY" command MUST BE implemented by all CUAs 4888 that support getting the "GET-CAPABILITY" command. 4890 A CS MUST send a "REPLY" command to a CUA for any command a CUA MAY 4891 send to the CS. The "REPLY" command MUST BE implemented by all CSs. 4893 Formal Definition: A "REPLY" command is defined by the following 4894 notation: 4896 reply-cmd = replyparam ":" "REPLY" 4898 replyparam = *( 4900 ; The 'id' parameter value MUST BE exactly the 4901 ; same as the value sent in the original 4902 ; CMD property. If the original CMD did 4903 ; not have an 'id' parameter, then the 'id' 4904 ; MUST NOT be supplied in the REPLY. 4906 id-param 4908 ; the following is optional, 4909 ; and MAY occur more than once 4911 / (";" xparam) 4913 ) 4915 10.8 SEARCH Command 4917 CMD: SEARCH 4919 Purpose: The "SEARCH" command is used to return selected components 4920 to the CUA. 4922 A CUA MAY send a "SEARCH" command to a CS. The "SEARCH" command MUST 4923 BE implemented by all CSs. 4925 The CS MUST NOT send a "SEARCH" command to any CUA. 4927 Formal Definition: A "SEARCH" command is defined by the following 4928 notation: 4930 search-cmd = searchparam ":" "SEARCH" 4932 searchparam = *( 4934 ; the following are optional, 4935 ; but MUST NOT occur more than once 4937 id-param 4938 / localize-param 4939 / latency-param 4941 ; the following MUST occur exactly once and only 4942 ; when the latency-param has been supplied and 4943 ; MUST NOT be supplied if the latency-param is 4944 ; not supplied. 4946 / action-param 4948 ; the following is optional, 4949 ; and MAY occur more than once 4951 / (";" xparam) 4953 ) 4955 Response: 4957 The data in each result contains an iCalendar object composed of all 4958 the selected components enclosed in a "VREPLY" component. Only 4959 "REQUEST-STATUS" property and the properties mentioned in the 4960 "SELECT" clause of the QUERY are included in the components. Each 4961 iCalendar object is tagged with the "TARGET" property. 4963 Searching for objects 4965 In the example below objects on March 10,1999 between 080000Z and 4966 190000Z are read. In this case only 4 properties for each objects 4967 are returned. Two calendars are specified. Only booked (vs 4968 scheduled) entries are to be returned (this example only selected 4969 VEVENT objects): 4971 C: Content-Type: text/calendar 4972 C: 4973 C: BEGIN:VCALENDAR 4974 C: VERSION:2.0 4975 C: PRODID:-//someone's prodid 4976 C: CMD:SEARCH 4977 C: TARGET:relcal2 4978 C: TARGET:relcal3 4979 C: BEGIN:VQUERY 4980 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID 4981 C: FROM VEVENT 4982 C: WHERE DTEND >= '19990310T080000Z' 4983 C: AND DTSTART <= '19990310T190000Z' 4984 C: AND STATE() = 'BOOKED' 4985 C: END:VQUERY 4986 C: END:VCALENDAR 4988 The return values are subject to VCAR filtering. That is, if the 4989 request contains properties to which the UPN does not have access, 4990 those properties will not appear in the return values. If the UPN 4991 has access to at least one property of the component, but has been 4992 denied access to all properties called out in the request, the 4993 response will contain a single "REQUEST-STATUS" property indicating 4994 the error. 4996 Here the request was successful, but the "VEVENT" component contents 4997 were not accessible (4.1). 4999 S: Content-Type: text/calendar 5000 S: 5001 S: BEGIN:VCALENDAR 5002 S: TARGET:relcalid 5003 S: CMD:REPLY 5004 S: VERSION:2.0 5005 S: PRODID:-//someone's prodid 5006 S: BEGIN:VREPLY 5007 S: BEGIN:VEVENT 5008 S: REQUEST-STATUS:4.1 5009 S: END:VEVENT 5010 S: END:VREPLY 5011 S: END:VCALENDAR 5013 If the UPN has no access to any components at all, the response will 5014 simply be an empty data set. The response looks the same if there 5015 the particular components did not exist. 5017 S: Content-Type: text/calendar 5018 S: 5019 S: BEGIN:VCALENDAR 5020 S: VERSION:2.0 5021 S: PRODID:-//someone's prodid 5022 S: CMD:REPLY 5023 S: TARGET:ralcalid 5024 S: BEGIN:VREPLY 5025 S: REQUEST-STATUS:2.0 5026 S: END:VREPLY 5027 S: END:VCALENDAR 5029 If there are multiple targets, each iCalendar reply is contained 5030 within its own iCalendar object. 5032 Stored VQUERY can be used by specifying the property QUERYID instead 5033 of QUERY. 5035 10.9 SET-LOCALE Command 5037 CMD: SET-LOCALE 5039 Purpose: The "SET-LOCALE" command is used to select the locale that 5040 will be used in error codes used int the "REQUEST-STATUS" property. 5041 It also effect the locale sorting order for queries. 5043 A CUA MAY send a "SET-LOCALE" command to a CS. The SET-LOCALE 5044 command MUST BE implemented by all CSs. 5046 The CS MUST NOT send a "SET-LOCALE" command to any CUA. 5048 Formal Definition: A "SET-LOCALE" command is defined by the following 5049 notation: 5051 setlocale-cmd = searchparam ":" "SET-LOCALE" 5053 setlocaleparam = *( 5055 ; the following are optional, 5056 ; but MUST NOT occur more than once 5058 id-param 5059 / localize-param 5060 / latency-param 5061 / setlocale-option 5063 ; the following MUST occur exactly once and only 5064 ; when the latency-param has been supplied and 5065 ; MUST NOT be supplied if the latency-param is 5066 ; not supplied. 5068 / action-param 5070 ; the following is optional, 5071 ; and MAY occur more than once 5073 / (";" xparam) 5075 setlocal-option = option-param newlocale 5077 newlocale = ; Any locale supplied in the initial BEEP 5078 ; "greeting" "localize" parameter and 5079 ; and any charset supported by the CS 5080 ; and listed in the DEFAULT-CHARSET property 5081 ; of the VCALSTORE. 5083 ) 5085 Restriction Table for the "REPLY" command of any "SET-LOCALE" 5086 command. 5088 setlocale-reply = "BEGIN" ":" "VCALENDAR" CRLF 5089 calprops 5090 1*(setlocale-vreply) 5091 "END" ":" "VCALENDAR" CRLF 5093 setlocale-vreply = "BEGIN" ":" "VREPLY" CRLF 5094 request-status 5095 "END" ":" "VREPLY" CRLF 5097 10.10 TIMEOUT Command 5099 CMD: TIMEOUT 5101 Purpose: The "TIMEOUT" command is only sent after a command has been 5102 sent with a latency value set. When received it means the command 5103 could not be completed in the time allowed. 5105 Formal Definition: A "CONTINUE" command is defined by the following 5106 notation: 5108 continue-cmd = continueparam ":" "CONTINUE" 5110 continueparam = *( 5112 ; the following are optional, 5113 ; but MUST NOT occur more than once 5115 id-param 5116 / localize-param 5118 / (";" xparam) 5120 ) 5122 The REPLY of any "TIMEOUT" command is: 5124 timeout-reply = "BEGIN" ":" "VCALENDAR" CRLF 5125 calprops 5126 timeout-vreply 5127 "END" ":" "VCALENDAR" CRLF 5129 timeout-vreply = "BEGIN" ":" "VREPLY" CRLF 5130 request-status 5131 *(x-prop) 5132 "END" ":" "VREPLY" CRLF 5134 10.11 Response Codes 5136 Numeric response codes are returned using the "REQUEST-STATUS" 5137 property. 5139 The format of these codes is described in [iCAL], and extend in 5140 [iTIP] and [iMIP]. The following describes new codes added to this 5141 set and how existing codes apply to CAP. 5143 At the application layer response codes are returned as the value of 5144 a "REQUEST-STATUS" property. The value type of this property is 5145 modified from that defined in [iCAL], in order to make the 5146 accompanying "REQUEST-STATUS" property text optional. 5148 Code Description 5149 -------------------------------------------------------------- 5150 2.0 Success. The parameters vary with the 5151 operation and are specified. 5153 2.0.3 In response to the client issuing an 5154 "abort" reply, this reply code indicates 5155 that any command currently underway was 5156 successfully aborted. 5158 3.1.4 Capability not supported. 5160 4.1 Calendar store access denied. 5162 6.1 Container not found. 5164 6.2 Attempt to create or modify an object 5165 such that it would overlap another object 5166 in either of the following two circumstances: 5168 (a) One of the objects has a TRANSP 5169 property set to OPAQUE-NOCONFLICT or 5170 TRANSPARENT-NOCONFLICT. 5172 (b) The calendar's ALLOW-CONFLICT 5173 property is set to FALSE. 5175 6.3 Bad args. 5177 6.4 Permission denied - VCAR restriction. 5178 A VCAR exists and the CS will not perform 5179 the operation. 5181 7.0 A timeout has occurred. The server was 5182 unable to complete the operation in the 5183 requested time. 5185 8.0 A failure has occurred in the Calendar Server 5186 that prevents the operation from 5187 succeeding. 5189 8.1 A query was performed and the query is 5190 too complex for the CS. The operation 5191 was not performed. 5193 8.2 Used to signal that an iCalendar object has 5194 exceeded the server's size limit 5196 8.3 A DATETIME value was too far in the future 5197 represented on this Calendar. 5199 8.4 A DATETIME value was too far in the past 5200 to be represented on this Calendar. 5202 8.5 An attempt was made to create a new 5203 object but the unique UID specified is 5204 already in use. 5206 9.0 An unrecognized command was received. 5207 Or an unsupported command was received. 5209 10.4 The operation has not been performed 5210 because it would cause the resources 5211 (memory, disk, CPU, etc) to exceed the 5212 allocated quota. 5214 -------------------------------------------------------------- 5216 11. Object Registration 5218 This section provides the process for registration of new or modified 5219 properties, parameters, commands, or other modifications, additions, 5220 or deletions to objects. 5222 11.1 Registration of New and Modified Entities 5224 New objects are registered by the publication of an IETF Request for 5225 Comment (RFC). Changes to a objects are registered by the 5226 publication of a revision to the RFC in a new RFC. 5228 11.2 Post the item definition 5230 The object description MUST BE posted to the new object discussion 5231 list: ietf-calendar@imc.org. 5233 11.3 Allow a comment period 5235 Discussion on a new object MUST BE allowed to take place on the list 5236 for a minimum of two weeks. Consensus MUST BE reached on the object 5237 before proceeding to the next step. 5239 11.4 Release a new RFC 5241 The new object will be submitted for publication as any other 5242 internet draft requesting RFC status. 5244 12. BEEP and CAP 5246 12.1 BEEP Profile Registration 5248 TBD 5250 12.2 BEEP Exchange Styles 5252 [BEEP] defines three styles of message exchange: 5254 MSG/ANS,ANS,...,NUL - For one to many exchanges. 5256 MSG/RPY - For one to one exchanges. 5258 MSG/ERR - For requests the cannot be processed due to an error. 5260 A CAP request, targeted at more than one containers, MAY use a one- 5261 to-many exchange, with a distinct answer associated with each target. 5262 CAP request targeted at a single container MAY use a one-to-one 5263 exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when 5264 an error condition prevents the execution of the request on all the 5265 targeted calendars. 5267 13. IANA Considerations 5269 This memo defines IANA registered extensions to the attributes 5270 defined by iCalendar, as defined in [iCAL], and [iTIP]. 5272 IANA registration proposals for iCalendar and [iTIP] are to be mailed 5273 to the registration agent for the "text/calendar" [MIME] content- 5274 type, using the format defined in 5275 section 7 of [iCAL]. 5277 If the IESG approves this memo for publication, then the IANA 5278 registers the profile specified in Section 12.1, and selects an IANA- 5279 specific URI, e.g., http://iana.org/beep/cap/1.0. 5281 14. Security Considerations 5283 Access rights should be granted cautiously, consult Section 2.4.2 for 5284 a discussion of the subject. Without careful planning it is possible 5285 to open up access to a greater degree than desired. 5287 The "IDENTIFY" command should be carefully implemented as discussed 5288 in Section 6.1.3. 5290 In addition, since CAP is a profile of the BEEP, consult [BEEP]'s 5291 Section 9 for a discussion of BEEP-specific security issues. 5293 Although service provisioning is a policy matter, at a minimum, all 5294 implementations must provide the following tuning profiles: 5296 for authentication: http://iana.org/beep/SASL/DIGEST-MD5 5298 for confidentiality: http://iana.org/beep/TLS (using the 5299 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) 5301 for both: http://iana.org/beep/TLS (using the 5302 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side 5303 certificates) 5305 URIs 5307 [1] 5309 Authors' Addresses 5311 Doug Royer 5312 INET-Consulting.com 5313 1795 W. Broadway #266 5314 Idaho Falls, ID 83402 5315 US 5317 Phone: +1-866-594-8574 5318 Fax: +1-866-594-8574 5319 EMail: Doug@Royer.com 5320 URI: http://INET-Consulting.com 5322 George Babics 5323 Oracle 5324 2000 Peel Street 5325 Montreal, Quebec H3A 2W5 5326 CA 5328 Phone: +1-514-733-8500 x4201 5329 Fax: +1-514-733-8878 5330 EMail: George.Babics@Oracle.com 5332 Paul Hill 5333 Massachusetts Institute of Technology 5334 W92-172 5335 77 Massachusetts Avenue 5336 Cambridge, MA 02139 5337 US 5339 Phone: +1-617-253-0124 5340 Fax: +1-617-258-8736 5341 EMail: phb@mit.edu 5342 Steve Mansour 5343 AOL/Netscape 5344 466 Ellis Road 5345 Mountain View, CA 94043 5346 US 5348 Phone: +1-650-937-3351 5349 EMail: sman@netscape.com 5351 Appendix A. Acknowledgments 5353 The following have individuals were major contributors in the 5354 drafting and discussion of this memo: 5356 Harald Alvestrand, Christopher Apple, G. Barnes, ArentJan Banck, 5357 Martijn van Beers, Mario Bonin, Andrea Campi, Darryl Champagne, Damon 5358 Chaplin, Karen Chu, Shannon Clark, Andre Courtemanche, Dave Crocker, 5359 Alan Davies, Andrew Davison, Mark Davidson, Bernard Desruisseaux, 5360 Frank Dawson, Pat Egen, Greg FitzPatrick, illes Fortin, Ned Freed, 5361 Gary Frederick, Jagan Garimella, Graham Gilmore, Micah Gorrell, 5362 Lawrence Greenfield, Bertrand Guiheneuf, Olivier Gutknecht, Mike 5363 Hixson, Jeff Hodges, Paul Hoffman, Scott Hollenbeck, Alex Hoppman, 5364 Bruce Kahn, Lata Kannan, suchet singh khalsa, Dan Kohn, Patrice 5365 Lapierre, Jonathan Lennox, Lisa Lippert, Robert Lusardi, David Madeo, 5366 Bob Mahoney, Murata Makoto, Gary McGath, Libby Miller, Steve Miller, 5367 Bob Morgan, David Nicol, David Nusbaum, Pete O'Leary, Mark Paterson, 5368 Ralph Patterson, Eric R. Plamondon, Robert Ransdell, Jim Ray, 5369 Marshall Rose, JP Rosevear, Paul Sharpe, Richard Shusterman, Tony 5370 Small, John Smith, Benjamin Sonntag, John Stracke, Alexander Taler, 5371 Peter Thompson, Steve Vinter, Mark Wahl, Dan Winship 5373 Appendix B. Bibliography 5375 [BEEP] Rose, M., "The Block Extensible Exchange Protocol Core", 5376 RFC 3080, March 2001 5377 ftp://ftp.isi.edu/in-notes/rfc3080.txt 5379 [BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001 5380 ftp://ftp.isi.edu/in-notes/rfc3081.txt 5382 [CHARREG] Freed, N., Postel, J., "IANA Charset Registration Procedures", 5383 RFC 2278, January 1998, 5384 ftp://ftp.isi.edu/in-notes/rfc2278.txt 5386 [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages", 5387 RFC 2277, January 1998, 5388 ftp://ftp.isi.edu/in-notes/rfc2277.txt 5390 [GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet 5391 Calendaring", RFC 3283, June 2002, 5392 ftp://ftp.isi.edu/in-notes/rfc3283.txt 5394 [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and 5395 Scheduling Core Object Specification (iCalendar)", RFC 2445, 5396 November 1998 ftp://ftp.isi.edu/in-notes/rfc2245.txt 5398 [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., 5399 "iCalendar Transport-Independent Interoperability Protocol 5400 (iTIP) Events, BusyTime, To-dos and Journal Entries", 5401 RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc2446.txt 5403 [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar 5404 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 5405 November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt 5407 [MIME] Borenstein, N. and Freed, N., "Multipurpose Internet Mail 5408 Extensions (MIME) Part One: Format of Internet Message Bodies", 5409 RFC 2045, November 1996 5410 ftp://ftp.isi.edu/in-notes/rfc2045.txt 5412 [RFCWORDS] Bradner, S., "Key words for use in RFCs to Indicate 5413 Requirement Levels", RFC 2119, BCP 14, March 1997 5414 ftp://ftp.isi.edu/in-notes/rfc2119.txt 5416 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 5417 RFC 2222, October 1997 5418 ftp://ftp.isi.edu/in-notes/rfc2222.txt 5420 [SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, 5421 aka ANSI X3.135-1992, aka FiPS PUB 127-2 5423 [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 5424 to ISO/IEC 9075: 1992, also adopted as Amendment 1 to 5425 ANSI X3.135.1992 5427 [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 5428 "Guidelines for new URL Schemes", RFC 2718, November 1999, 5429 ftp://ftp.isi.edu/in-notes/rfc2718.txt 5431 [URI] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform Resource 5432 Identifiers (URI): Generic Syntax", RFC 2396, August 1998 5433 ftp://ftp.isi.edu/in-notes/rfc2396.txt 5435 [URL] Berners-Lee, T, Masinter, L. and McCahil, M., "Uniform 5436 Resource Locators (URL)", RFC 1738, December 1994 5437 ftp://ftp.isi.edu/in-notes/rfc1738.txt 5439 [X509CRL] Housley, R., Ford, W., Polk, W., Solo, D. "Internet X.509 5440 Public Key Infrastructure, Certificate and CRL Profile", 5441 RFC 2459, January 1999, 5442 ftp://ftp.isi.edu/in-notes/rfc2459.txt 5444 Full Copyright Statement 5446 Copyright (C) The Internet Society (2002). All Rights Reserved. 5448 This document and translations of it may be copied and furnished to 5449 others, and derivative works that comment on or otherwise explain it 5450 or assist in its implementation may be prepared, copied, published 5451 and distributed, in whole or in part, without restriction of any 5452 kind, provided that the above copyright notice and this paragraph are 5453 included on all such copies and derivative works. However, this 5454 document itself may not be modified in any way, such as by removing 5455 the copyright notice or references to the Internet Society or other 5456 Internet organizations, except as needed for the purpose of 5457 developing Internet standards in which case the procedures for 5458 copyrights defined in the Internet Standards process must be 5459 followed, or as required to translate it into languages other than 5460 English. 5462 The limited permissions granted above are perpetual and will not be 5463 revoked by the Internet Society or its successors or assigns. 5465 This document and the information contained herein is provided on an 5466 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 5467 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 5468 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 5469 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 5470 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5472 Acknowledgement 5474 Funding for the RFC Editor function is currently provided by the 5475 Internet Society.