idnits 2.17.1 draft-royer-calsch-cap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 6012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6002. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 44 instances of too long lines in the document, the longest one being 30 characters in excess of 72. == 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 368: '... is, "events MUST BE scheduled in ...' RFC 2119 keyword, line 422: '... These extensions MUST start with "x-"...' RFC 2119 keyword, line 455: '...flict, the Realm SHOULD be postfixed w...' RFC 2119 keyword, line 460: '...endar store. It MUST BE unique within...' RFC 2119 keyword, line 496: '...odid' and 'version' are both REQUIRED,...' (240 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 353 has weird spacing: '...able to diffe...' == Line 824 has weird spacing: '...cts for that ...' == Line 1909 has weird spacing: '...roperty woul...' == Line 1980 has weird spacing: '... know if "u...' == Line 2098 has weird spacing: '...lm. In it's ...' == (5 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 (August 8, 2005) is 6835 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? 'BEEP' on line 5908 looks like a reference -- Missing reference section? 'RFCWORDS' on line 5948 looks like a reference -- Missing reference section? 'GUIDE' on line 5926 looks like a reference -- Missing reference section? 'URL' on line 5971 looks like a reference -- Missing reference section? 'URI' on line 5967 looks like a reference -- Missing reference section? 'URLGUIDE' on line 5963 looks like a reference -- Missing reference section? 'ABNF' on line 5904 looks like a reference -- Missing reference section? 'MIME' on line 5943 looks like a reference -- Missing reference section? 'CAP' on line 1316 looks like a reference -- Missing reference section? 'BEEPTCP' on line 5912 looks like a reference -- Missing reference section? 'X509CRL' on line 5975 looks like a reference -- Missing reference section? 'SQL92' on line 5956 looks like a reference -- Missing reference section? 'SQLCOM' on line 5959 looks like a reference -- Missing reference section? 'NOT' on line 1886 looks like a reference -- Missing reference section? 'CHARREG' on line 5918 looks like a reference -- Missing reference section? 'CHARPOL' on line 5922 looks like a reference -- Missing reference section? 'BEEPGUIDE' on line 5915 looks like a reference -- Missing reference section? 'SASL' on line 5952 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendaring and Scheduling D. Royer 3 Internet-Draft IntelliCal, LLC 4 Expires: February 9, 2006 G. Babics 5 Oracle 6 P. Hill 7 Massachusetts Institute of 8 Technology 9 S. Mansour 10 AOL/Netscape 11 August 8, 2005 13 Calendar Access Protocol (CAP) 14 draft-royer-calsch-cap-03 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on February 9, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 The Calendar Access Protocol (CAP) is an Internet protocol described 48 in this memo that permits a Calendar User (CU) to utilize a Calendar 49 User Agent (CUA) to access an [iCAL] based Calendar Store (CS). 51 At the time of this writing there are three vendors implementing CAP. 52 It has already been determined that some changes are needed. In 53 order to get implementation experience the participants felt that CAP 54 needed to be released so that many years of work could be preserved. 55 Many properties in CAP can be used by other iCalendar protocols and 56 have had many years of debate. 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) . . . . . . . . . . . . . . . 15 66 2.1.1 New Parameters (summary) . . . . . . . . . . . . . . 15 67 2.1.2 New or Updated Properties (summary) . . . . . . . . 16 68 2.1.3 New Components (summary) . . . . . . . . . . . . . . 18 69 2.2 Relationship of RFC-2446 (ITIP) and CAP . . . . . . . . 19 70 3. CAP Design . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 3.1 System Model . . . . . . . . . . . . . . . . . . . . . . 22 72 3.2 Calendar Store Object Model . . . . . . . . . . . . . . 22 73 3.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 23 74 3.3.1 Use of BEEP, MIME and iCalendar . . . . . . . . . . 24 75 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . 26 76 4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 26 77 4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . 26 78 4.1.2 Anonymous Users and Authentication . . . . . . . . . 27 79 4.1.3 User Groups . . . . . . . . . . . . . . . . . . . . 27 80 4.2 Access Rights . . . . . . . . . . . . . . . . . . . . . 28 81 4.2.1 Access Control and NOCONFLICT . . . . . . . . . . . 28 82 4.2.2 Predefined VCARs . . . . . . . . . . . . . . . . . . 28 83 4.2.3 Decreed VCARs . . . . . . . . . . . . . . . . . . . 30 84 4.3 CAP Session Identity . . . . . . . . . . . . . . . . . . 31 85 5. CAP URL and Calendar Address . . . . . . . . . . . . . . . . 33 86 6. New Value Types . . . . . . . . . . . . . . . . . . . . . . 35 87 6.1 Property Value Data Types . . . . . . . . . . . . . . . 35 88 6.1.1 CAL-QUERY Value Type . . . . . . . . . . . . . . . . 35 89 6.1.2 UPN Value Type . . . . . . . . . . . . . . . . . . . 51 90 6.1.3 UPN-FILTER Value . . . . . . . . . . . . . . . . . . 52 91 7. New Parameters . . . . . . . . . . . . . . . . . . . . . . . 55 92 7.1 ACTION Parameter . . . . . . . . . . . . . . . . . . . . 55 93 7.2 ENABLE Parameter . . . . . . . . . . . . . . . . . . . . 55 94 7.3 ID Parameter . . . . . . . . . . . . . . . . . . . . . . 56 95 7.4 LATENCY Parameter . . . . . . . . . . . . . . . . . . . 57 96 7.5 LOCAL Parameter . . . . . . . . . . . . . . . . . . . . 58 97 7.6 LOCALIZE Parameter . . . . . . . . . . . . . . . . . . . 58 98 7.7 OPTIONS Parameter . . . . . . . . . . . . . . . . . . . 59 99 8. New Properties . . . . . . . . . . . . . . . . . . . . . . . 61 100 8.1 ALLOW-CONFLICT Property . . . . . . . . . . . . . . . . 61 101 8.2 ATT-COUNTER Property . . . . . . . . . . . . . . . . . . 61 102 8.3 CALID Property . . . . . . . . . . . . . . . . . . . . . 62 103 8.4 CALMASTER Property . . . . . . . . . . . . . . . . . . . 63 104 8.5 CAP-VERSION Property . . . . . . . . . . . . . . . . . . 63 105 8.6 CARID Property . . . . . . . . . . . . . . . . . . . . . 64 106 8.7 CAR-LEVEL Property . . . . . . . . . . . . . . . . . . . 65 107 8.8 COMPONENTS Property . . . . . . . . . . . . . . . . . . 65 108 8.9 CSID Property . . . . . . . . . . . . . . . . . . . . . 67 109 8.10 DECREED Property . . . . . . . . . . . . . . . . . . . . 67 110 8.11 DEFAULT-CHARSET Property . . . . . . . . . . . . . . . . 68 111 8.12 DEFAULT-LOCALE Property . . . . . . . . . . . . . . . . 69 112 8.13 DEFAULT-TZID Property . . . . . . . . . . . . . . . . . 70 113 8.14 DEFAULT-VCARS Property . . . . . . . . . . . . . . . . . 71 114 8.15 DENY Property . . . . . . . . . . . . . . . . . . . . . 72 115 8.16 EXPAND property . . . . . . . . . . . . . . . . . . . . 72 116 8.17 GRANT Property . . . . . . . . . . . . . . . . . . . . . 73 117 8.18 ITIP-VERSION Property . . . . . . . . . . . . . . . . . 74 118 8.19 MAX-COMP-SIZE Property . . . . . . . . . . . . . . . . . 74 119 8.20 MAXDATE Property . . . . . . . . . . . . . . . . . . . . 75 120 8.21 MINDATE Property . . . . . . . . . . . . . . . . . . . . 76 121 8.22 MULTIPART Property . . . . . . . . . . . . . . . . . . . 76 122 8.23 NAME Property . . . . . . . . . . . . . . . . . . . . . 77 123 8.24 OWNER Property . . . . . . . . . . . . . . . . . . . . . 78 124 8.25 PERMISSION Property . . . . . . . . . . . . . . . . . . 79 125 8.26 QUERY property . . . . . . . . . . . . . . . . . . . . . 79 126 8.27 QUERYID property . . . . . . . . . . . . . . . . . . . . 80 127 8.28 QUERY-LEVEL Property . . . . . . . . . . . . . . . . . . 81 128 8.29 RECUR-ACCEPTED Property . . . . . . . . . . . . . . . . 81 129 8.30 RECUR-LIMIT Property . . . . . . . . . . . . . . . . . . 82 130 8.31 RECUR-EXPAND Property . . . . . . . . . . . . . . . . . 83 131 8.32 RESTRICTION Property . . . . . . . . . . . . . . . . . . 83 132 8.33 SCOPE Property . . . . . . . . . . . . . . . . . . . . . 84 133 8.34 STORES-EXPANDED Property . . . . . . . . . . . . . . . . 85 134 8.35 TARGET Property . . . . . . . . . . . . . . . . . . . . 86 135 8.36 TRANSP Property . . . . . . . . . . . . . . . . . . . . 86 136 9. New Components . . . . . . . . . . . . . . . . . . . . . . . 88 137 9.1 VAGENDA Component . . . . . . . . . . . . . . . . . . . 88 138 9.2 VCALSTORE Component . . . . . . . . . . . . . . . . . . 90 139 9.3 VCAR Component . . . . . . . . . . . . . . . . . . . . . 92 140 9.4 VRIGHT Component . . . . . . . . . . . . . . . . . . . . 95 141 9.5 VREPLY Component . . . . . . . . . . . . . . . . . . . . 96 142 9.6 VQUERY Component . . . . . . . . . . . . . . . . . . . . 96 143 10. Commands and Responses . . . . . . . . . . . . . . . . . . 98 144 10.1 CAP Commands (CMD) . . . . . . . . . . . . . . . . . . . 98 145 10.1.1 Bounded Latency . . . . . . . . . . . . . . . . . . 99 146 10.2 ABORT Command . . . . . . . . . . . . . . . . . . . . . 101 147 10.3 CONTINUE Command . . . . . . . . . . . . . . . . . . . . 102 148 10.4 CREATE Command . . . . . . . . . . . . . . . . . . . . . 103 149 10.5 DELETE Command . . . . . . . . . . . . . . . . . . . . . 109 150 10.6 GENERATE-UID Command . . . . . . . . . . . . . . . . . . 112 151 10.7 GET-CAPABILITY Command . . . . . . . . . . . . . . . . . 114 152 10.8 IDENTIFY Command . . . . . . . . . . . . . . . . . . . . 117 153 10.9 MODIFY Command . . . . . . . . . . . . . . . . . . . . . 120 154 10.10 MOVE Command . . . . . . . . . . . . . . . . . . . . . 124 155 10.11 REPLY Response to a Command . . . . . . . . . . . . . 127 156 10.12 SEARCH Command . . . . . . . . . . . . . . . . . . . . 128 157 10.12.1 Searching for VFREEBUSY . . . . . . . . . . . . . 131 158 10.13 SET-LOCALE Command . . . . . . . . . . . . . . . . . . 132 159 10.14 TIMEOUT Command . . . . . . . . . . . . . . . . . . . 134 160 10.15 Response Codes . . . . . . . . . . . . . . . . . . . . 134 161 11. Object Registration . . . . . . . . . . . . . . . . . . . 137 162 11.1 Registration of New and Modified Entities . . . . . . . 137 163 11.2 Post the item definition . . . . . . . . . . . . . . . . 137 164 11.3 Allow a comment period . . . . . . . . . . . . . . . . . 137 165 11.4 Release a new RFC . . . . . . . . . . . . . . . . . . . 137 166 12. BEEP and CAP . . . . . . . . . . . . . . . . . . . . . . . 138 167 12.1 BEEP Profile Registration . . . . . . . . . . . . . . . 138 168 12.2 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 140 169 12.3 BEEP connection details . . . . . . . . . . . . . . . . 140 170 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 143 171 14. Security Considerations . . . . . . . . . . . . . . . . . 144 172 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 145 173 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 146 174 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 147 175 Intellectual Property and Copyright Statements . . . . . . . 149 177 1. Introduction 179 This document specifies how a Calendar CUA interacts with a CS to 180 manage calendar information. In particular, it specifies how to 181 query, create, modify, and delete iCalendar components (e.g., events, 182 to-dos, or daily journal entries). It further specifies how to 183 search for available busy time information. Synchronization with 184 CUAs is not covered and believed to be possible using CAP. 186 CAP is specified as a [BEEP] "profile". As such, many aspects of the 187 protocol (e.g., authentication and privacy) are provided within 188 [BEEP]. The protocol data units leverage the standard iCalendar 189 format [iCAL] to convey calendar related information. 191 CAP can also be used to store and fetch [iTIP] objects and when those 192 objects are used in this memo, they mean exactly the same as defined 193 in [iTIP]. When iCalendar objects are transferred between the CUA 194 and a CS, some additional properties and parameters may be added and 195 the CUA is responsible for correctly generating iCalendar objects to 196 non CAP processes. 198 The definition of new components, properties, parameter's, and value 199 types are broken into two parts. The first part summarizes and 200 defines the new objects. The second part provides the detail and any 201 ABNF for those objects. The ABNF in CAP as in other iCalendar 202 specifications is order independent. That is properties in a 203 component may occur in any order and parameters in any property may 204 occur in any order. 206 1.1 Formatting Conventions 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 210 document are to be interpreted as described in [RFCWORDS]. 212 Calendaring and scheduling roles are referred to in quoted-strings of 213 text with the first character of each word in upper case. For 214 example, "Organizer" refers to a role of a "Calendar User" (CU) 215 within the protocol defined by [iTIP]. Calendar components defined 216 by [iCAL] are referred to with capitalized, quoted-strings of text. 217 All iCalendar components should start with the letter "V". For 218 example, "VEVENT" refers to the event calendar component, "VTODO" 219 refers to the to-do component and "VJOURNAL" refers to the daily 220 journal component. 222 Scheduling methods defined by [iTIP], are referred to with 223 capitalized, quoted-strings of text. For example, "REPLY" refers to 224 the method for replying to a "REQUEST". 226 CAP commands are referred to by upper-case, quoted-strings of text, 227 followed by the word "command". For example, "CREATE" command refers 228 to the command for creating a calendar entry, "SEARCH" command refers 229 to the command for reading calendar components. CAP Commands are 230 named using the "CMD" property. 232 Properties defined by this memo are referred to with capitalized, 233 quoted-strings of text, followed by the word "property". For 234 example, "ATTENDEE" property refers to the iCalendar property used to 235 convey the calendar address that has been invited to a "VEVENT" or 236 "VTODO" component. 238 Property parameters defined by this memo are referred to with 239 capitalized, quoted-strings of text, followed by the word 240 "parameter". For example, "PARTSTAT" parameter refers to the 241 iCalendar property parameter used to specify the participation status 242 of an attendee. Enumerated values defined by this memo are referred 243 to with capitalized text, either alone or followed by the word 244 "value". 246 Object states defined by this memo are referred to with capitalized, 247 quoted-strings of text, followed by the word "state". For example, 248 "BOOKED" state refers to an object in the booked state. 250 Within a query, the different parts are referred to as a "clause" and 251 its value as "clause value" and the clause name will be in uppercase 252 enclosed in quotes. Example, The "SELECT" clause or if the "SELECT" 253 clause value contains ... 255 In tables, the quoted-string text is specified without quotes in 256 order to minimize the table length. 258 1.2 Related Documents 260 Implementers will need to be familiar with several other memos that, 261 along with this one, describe the Internet calendaring and scheduling 262 standards. These documents are: 264 [iCAL] - (RFC2445) Which specifies the objects, data types, 265 properties and property parameters used in the protocols, along 266 with the methods for representing and encoding them. 268 [iTIP] - (RFC2446) Which specifies an interoperability protocol for 269 scheduling between different installations. 271 [iMIP] - (RFC2447) Which specifies the Internet email binding for 272 [iTIP]. 274 [GUIDE] - (RFC3283), a guide to implementers and describes the 275 elements of a calendaring system, how they interact with each 276 other, how they interact with end users, and how the standards and 277 protocols are used. 279 This memo does not attempt to repeat the specification of concepts 280 and definitions from these other memos. Where possible, references 281 are made to the memo that provides for the specification of these 282 concepts and definitions. 284 1.3 Definitions 286 BOOKED - An object in the calendar store has one of three conceptual 287 states. It is in the "UNPROCESSED" state, "BOOKED" state, or 288 marked for deletion which is the "DELETED" state. How the 289 implementation stores the state of any object is not a protocol 290 issues and is not discussed. An object can be said to be booked, 291 unprocessed, or marked for delete. 293 1. An "UNPROCESSED" state scheduling object has been stored in 294 the calendar store but has not been acted on by a CU or CUA. 295 All scheduled entries are [iTIP] objects. All [iTIP] objects 296 in the store are not in the "BOOKED" state. To retrieve any 297 [iTIP] object, simply do a query asking for any objects that 298 are stored in the "UNPROCESSED" state. 300 2. A "BOOKED" state entry is stored with the "CREATE" command. 301 It is an object that has been acted on by a CU or CUA and 302 there has been a decision to store an object. To retrieve any 303 booked object, simply do a query asking for any objects that 304 were stored in the "BOOKED" state. 306 3. A "DELETED" state entry is created by sending a "DELETE" 307 command with the "OPTION" parameter value set to "MARK". To 308 retrieve any deleted object, simply do a query asking for any 309 objects that were stored in the "DELETED" state. By default 310 objects marked for delete are not returned. The CUA must 311 specifically ask for marked for delete objects. You can not 312 ask for components in the "DELETED" state and in other states 313 in the same "VQUERY" component, as there would be no way to 314 distinguish between them in the reply. 316 Calendar - A collection of logically related objects or entities 317 each of which may be associated with a calendar date and possibly 318 time of day. These entities can include calendar properties or 319 components. In addition, a calendar might be related to other 320 calendars with the "RELATED-TO" property. A calendar is 321 identified by its unique calendar identifier. The [iCAL] defines 322 the initial calendar properties, calendar components and 323 properties that make up the contents of a calendar. 325 Calendar Access Protocol (CAP) - The standard Internet protocol that 326 permits a CUA to access and manipulate calendars residing on a 327 Calendar Store. (this memo) 329 Calendar Access Rights (VCAR) - The mechanism for specifying the CAP 330 operations ("PERMISSION") that a particular calendar user ("UPN") 331 is granted or denied permission to perform on a given calendar 332 object ("SCOPE"). The calendar access rights are specified with a 333 "VCAR" component. (Section 9.3.) 335 Calendar Address - Also See Calendar URL - they are one in the same 336 for CAP addresses. The calendar address can also be the value to 337 the "ATTENDEE" and "ORGANIZER" properties as defined in [iCAL]. 339 Calendar URL - A calendar URL is a URL defined in this memo that 340 specifies the address of a CS or Calendar. 342 Component- Any object that conforms to the iCalendar object format 343 and that is either defined in an internet draft, registered with 344 IANA, or is an experimental object that is prefixed with "x-". 345 Some types of components include calendars, events, to-dos, 346 journals, alarms, and time zones. A component consists of 347 properties and possibly other contained components. For example, 348 an event may contain an alarm component. 350 Container - This is a generic name for VCALSTORE or VAGENDA. 352 Properties - An attribute of a particular component. Some 353 properties are applicable to different types of components. For 354 example, the "DTSTART" property is applicable to the "VEVENT", 355 "VTODO", and "VJOURNAL" components. Other components are 356 applicable only to an individual type of calendar component. For 357 example, the "TZURL" property may only be applicable to the 358 "VTIMEZONE" components. 360 Calendar Identifier (CALID) - A globally unique identifier 361 associated with a calendar. Calendars reside within a CS. See 362 Qualified Calendar Identifier and Relative Calendar Identifier. 363 All CALIDs start with "cap:". 365 Calendar Policy - A CAP operational restriction on the access or 366 manipulation of a calendar. These may be outside of the scope of 367 the CAP protocol. An example of an implementation or site policy 368 is, "events MUST BE scheduled in unit intervals of one hour". 370 Calendar Property - An attribute of a calendar ("VAGENDA"). The 371 attribute applies to the calendar, as a whole. For example, the 372 "CALSCALE" property specifies the calendar scale (e.g., the 373 "GREGORIAN" value) for the all entries within the calendar. 375 Calendar Store (CS) - The data and service model definition for a 376 Calendar Store as defined in this memo. This memo does not 377 specify how the CS is implemented. 379 Calendar Server - An implementation of a Calendar Store (CS) that 380 manages one or more calendars. 382 Calendar Store Identifier (CSID) - The globally unique identifier 383 for an individual CS. A CSID consists of the host and port 384 portions of a "Common Internet Scheme Syntax" part of a URL, as 385 defined by [URL]. The CSID excludes any reference to a specific 386 calendar. (Section 8.9) 388 Calendar Store Components - Components maintained in a CS specify a 389 grouping of calendar store-wide information. 391 Calendar Store Properties - Properties maintained in a Calendar 392 Store calendar store-wide information. 394 Calendar User (CU) - An entity (often biological) that uses a 395 calendaring system. 397 Calendar User Agent (CUA) - The client application that a CU 398 utilizes to access and manipulate a calendar. 400 CAP Session - An open communication channel between a CUA and a CS. 401 If the CAP session is authenticated, the CU is "authenticated" and 402 it is an "authenticated CAP session". 404 Contained Component / Contained Properties - A component or property 405 that is contained inside of another component. A "VALARM" 406 component for example may be contained inside of a "VEVENT" 407 component. And a "TRIGGER" property could be a contained property 408 of a "VALARM" component. 410 Delegate - A CU (sometimes called the delegatee) who has been 411 assigned participation in a scheduled component (e.g., VEVENT) by 412 one of the attendees in the scheduled component (sometimes called 413 the delegator). An example of a delegate is a team member told to 414 go to a particular meeting in place of another Attendee who is 415 unable to attend. 417 Designate - A CU who is authorized to act on behalf of another CU. 418 An example of a designate is an assistant. 420 Experimental - The CUA and CS may implement experimental extensions 421 to the protocol. They also might have experimental components, 422 properties, and parameters. These extensions MUST start with "x-" 423 (or "X-") and should include a vendor prefix (such as 424 "x-myvendor-"). There is no guarantee that these experimental 425 extensions will interoperate with other implementations. There is 426 no guarantee that they will not interact in unpredictable ways 427 with other vendor experimental extensions. There is no guarantee 428 that the same specific experimental extension is not used my 429 multiple vendors in incompatible ways. Implementations should 430 limit sending those extensions to other implementations. 432 Object - A generic name for any component, property, parameter, or 433 value type to be used in iCalendar. 435 Overlapped Booking - A policy which indicates whether or not 436 components with a "TRANSP" property not set to "TRANSPARENT- 437 NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap one another. 438 When the policy is applied to a calendar it indicates whether or 439 not the time span of any component (VEVENT, VTODO, ...) in the 440 calendar can overlap the time span of any other component in the 441 same calendar. When applied to an individual object, it indicates 442 whether or not any other component's time span can overlap that 443 individual component. If the CS does not allow overlapped 444 booking, then the CS is unwilling to allow any overlapped bookings 445 within any calendar or entry in the CS. 447 Owner - One or more CUs or UGs that are listed in the "OWNER" 448 property in a calendar. There can be more than one owner. 450 Qualified Calendar Identifier (Qualified CALID) - A CALID in which 451 both the scheme and CSID of the CAP URI are present. 453 Realm - A collection of calendar user accounts, identified by a 454 string. The name of the Realm is only used in UPNs. In order to 455 avoid namespace conflict, the Realm SHOULD be postfixed with an 456 appropriate DNS domain name. (e.g., the foobar Realm could be 457 called foobar.example.com). 459 Relative Calendar Identifier (Relative CALID) - An identifier for an 460 individual calendar in a calendar store. It MUST BE unique within 461 a calendar store. A Relative CALID consists of the "URL path" of 462 the "Common Internet Scheme Syntax" portion of a URL, as defined 463 by [URI] and [URLGUIDE]. 465 Session Identity - A UPN associated with a CAP session. A session 466 gains an identity after successful authentication. The identity 467 is used in combination with VCAR to determine access to data in 468 the CS. 470 User Group (UG) - A collection of Calendar Users and/or User Groups. 471 These groups are expanded by the CS and may reside either locally 472 or in an external database or directory. The group membership may 473 be fixed or dynamic over time. 475 Username - A name which denotes a Calendar User within a Realm. 476 This is part of a UPN. 478 User Principal Name (UPN) - A unique identifier that denotes a CU or 479 a group of CU. (Section 6.1.2) 481 2. Additions to iCalendar 483 Several new components, properties, parameters, and value types are 484 added in CAP. This section summarizes those new objects. 486 This memo extends the properties that can go into 'calprops' as 487 defined in [iCAL] section 4.6 page 51 to allow [iTIP] objects 488 transmitted between a CAP aware CUA and the CS to contain the 489 "TARGET" and "CMD" properties. This memo also adds to the [iCAL] 490 ABNF to allow IANA and experimental extensions. This memo does not 491 address how a CUA transmits [iTIP] or [iMIP] objects to non CAP 492 programs. (What follows is ABNF as described in [ABNF]) 494 calprops = 2*( 496 ; 'prodid' and 'version' are both REQUIRED, 497 ; but MUST NOT occur more than once. 498 ; 499 prodid /version / 500 ; 501 ; These are optional, but MUST NOT occur 502 ; more than once. 503 ; 504 calscale / 505 method / 506 cmd / 507 ; 508 ; Target is optional, and may occur more 509 ; than once. 510 ; 511 target / other-props ) 512 ; 513 other-props = *(x-prop) *(iana-prop) *(other-props) 514 ; 515 iana-prop = ; Any property registered by IANA directly or 516 ; included in an RFC that may be applied to 517 ; the component and within the rules published. 518 ; 519 x-prop = ; As defined in [iCAL] 520 ; 521 methodp = ; As defined in [iCAL] 522 ; 523 prodid = ; As defined in [iCAL] 524 ; 525 calscale = ; As defined in [iCAL] 526 ; 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 ; property then the 'component' is optional: 536 ; 537 / calprops ; Which MUST include a "CMD" property 538 ; 539 component = ; As defined in [iCAL] 541 In addition a problem exists with the control of "VALARM" components 542 and their "TRIGGER" properties. A CU may wish to set their own alarm 543 (local alarms) on components. These local alarms are not to be 544 forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property 545 and the "ENABLE" parameter. So for the protocol between a CUA and a 546 CS, the following changes apply to the CAP protocol from [iCAL] 547 section 4.6.6 page 67: 549 alarmc = "BEGIN" ":" "VALARM" CRLF 550 alarm-seq 551 other-props 552 (audioprop / dispprop / emailprop / procprop) 553 "END" ":" "VALARM" CRLF 554 ; 555 emailprop = ; As definded in [iCAL] 556 ; 557 procprop = ; As definded in [iCAL] 558 ; 559 dispprop = ; As definded in [iCAL] 560 ; 561 audioprop = ; As definded in [iCAL] 562 ; 563 alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF 564 ; 565 alarmseqparams = other-params [";" local-param] other-params 566 ; 567 ; Where DIGIT is defined in [iCAL] 568 ; 569 posint0 = 1*DIGIT 570 posint1 = posintfirst 1*DIGIT 571 ; 572 ; A number starting with 1 through 9. 573 ; 574 posintfirst = %x31-39 575 ; 576 other-params = *(";" xparam) *(";" iana-params) *(";" other-params) 577 ; 578 iana-params = ; Any parameter registered by IANA directly or 579 ; included in an RFC that may be applied to 580 ; the property and within the rules published. 581 ; 582 xparam ; As defined in [iCAL] 583 ; 585 The CUA adds a "SEQUENCE" property to each "VALARM" component as it 586 books the component. This property along with the "LOCAL" and 587 "ENABLE" parameters allow the CUA to uniquely identify any VALARM in 588 any component. The CUA should remove those before forwarding to non 589 CAP aware CUAs. 591 In addition, if a CUA wished to ignore a "TRIGGER" property in a 592 "VALARM" component that was supplied to it by the "Organizer", the 593 CUA needs a common way to tag that trigger as disabled. So the 594 following is a modification to [iCAL] section 4.8.6.3 page 127: 596 trigger = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs) 597 ; 598 trigrel = ; As defined in [iCAL] 599 ; 600 trigabs = ; As defined in [iCAL] 602 Section 7.2 and Section 7.5. 604 2.1 New Value Types (summary) 606 UPN The UPN value type is text value type restricted to only UPN 607 values. (Section 6.1.2) 609 UPN-FILTER Like the UPN value type, but also includes filter rules 610 that allow wildcards. (Section 6.1.3) 612 CALQUERY The "CAL-QUERY" value type is a query syntax that is used by 613 the CUA to specify the rules that apply to a CAP command. 614 (Section 6.1.1) 616 2.1.1 New Parameters (summary) 618 ACTION - The "ACTION" parameter informs the endpoint if it should 619 abort or ask to continue on timeout. (Section 7.1). 621 ENABLE - The "ENABLE" parameter in CAP is used to tag a property in 622 a component as disabled or enabled. (Section 7.2). 624 ID - The "ID" parameter specifies a unique identifier to be used for 625 any outstanding commands. 627 LATENCY - The "LATENCY" parameter supplies the timeout value for 628 command completion to the other endpoint. (Section 7.4). 630 LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a 631 component to signify that the component is local or to be 632 distributed. (Section 7.5). 634 LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used 635 in error and warning messages. 637 OPTIONS - The "OPTIONS" parameter passes optional information for 638 the command being sent. 640 2.1.2 New or Updated Properties (summary) 642 ALLOW-CONFLICT - Some entries in a calendar might not be valid if 643 other entries were allowed to overlap the same time span. 644 (Section 8.1) 646 ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" 647 method, there needs to be a way to remember the "ATTENDEE" value 648 that sent the COUNTER. (Section 8.2) 650 CAP-VERSION - The version of CAP the implementation supports. 651 (Section 8.5) 653 CAR-LEVEL - The level of calendar access level supported. 654 (Section 8.7) 656 COMPONENTS - The list of components supported. (Section 8.8) 658 CSID - The Calendar Store IDentifier (CSID) uniquely identifies a 659 CAP server. (Section 8.9) 661 CALID - Each calendar within a CS needs to be uniquely identifiable. 662 The "CALID" property identifies a unique calendar within a CS. It 663 can be a full CALID or a relative CALID. (Section 8.3) 665 CALMASTER - The "CALMASTER" property specifies the contact 666 information for the CS. (Section 8.4) 668 CARID - Access rights can be saved and fetched by unique ID - the 669 "CARID" property. (Section 8.6) 671 CMD - The CAP commands, as well as replies are transmitted using the 672 "CMD" property. (Section 10.1) 674 DECREED - Some access rights are not changeable by the CUA. When 675 that is the case, the "DECREED" property value in the "VCAR" 676 component will be "TRUE". (Section 8.10) 678 DEFAULT-CHARSET - The list of charsets supported by the CS. The 679 first entry is the default for the CS. (Section 8.11) 681 DEFAULT-LOCALE - The list of locales supported by the CS. The first 682 entry in the list is the default locale. (Section 8.12) 684 DEFAULT-TZID - This is the list of known timezones supported. The 685 first entry is the default. (Section 8.13) 687 DEFAULT-VCARS - A list of the "CARID" properties that will be used 688 to create new calendars. (Section 8.14) 690 DENY - The UPNs listed in the "DENY" property of a "VCAR" component 691 will denied access as described in the "VRIGHT" component. 692 (Section 8.15) 694 EXPAND - This property tells the CS if the query reply should expand 695 components into multiple instances. The default is "FALSE" and is 696 ignored for CSs that can not expand recurrence rules. 697 (Section 8.16) 699 GRANT - The UPNs listed in the "GRANT" property of a "VCAR" 700 component will allowed access as described in the "VRIGHT" 701 component. (Section 8.17) 703 ITIP-VERSION - The version of [iTIP] supported. (Section 8.18) 705 MAXDATE - The maximum date supported by the CS. (Section 8.20) 707 MAX-COMP-SIZE - The largest component size allowed in the 708 implementation including attachments in octets. (Section 8.19) 710 MINDATE - The minimum date supported by the CS. (Section 8.21) 712 MULTIPART - Passed in the capability messages to indicate which MIME 713 multipart types the sender supports. (Section 8.22) 715 NAME - The "NAME" property is used to add locale specific 716 descriptions into components. (Section 8.23) 718 OWNER - Each calendar has at least one "OWNER" property. (xref 719 target="OWNER"/>) Related to the "CAL-OWNERS()" (Section 6.1.1.1) 720 query clause. 722 PERMISSION - This property specifies the permission being granted or 723 denied. Examples are the "SEARCH" and "MODIFY" values. 724 (Section 8.25) 726 QUERY - Used to hold the CAL-QUERY (Section 8.26) for the component. 728 QUERYID - A unique id for a stored query. (Section 8.27) 730 QUERY-LEVEL - The level of the query language supported. 731 (Section 8.28) 733 RECUR-ACCEPTED - If the implementation support recurrence rules. 734 (Section 8.29) 736 RECUR-EXPAND - If the implementation support expanding recurrence 737 rules. (Section 8.31) 739 RECUR-LIMIT - Any maximum limit on the number of instances the 740 implementation will expand recurring objects. (Section 8.30) 742 REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to 743 include new error numbers. 745 RESTRICTION - In the final check when granting calendar access 746 requests, the CS test the results to the value of the 747 "RESTRICTION" property in the corresponding "VRIGHT" component to 748 determine if the access meets that restriction. (Section 8.32) 750 SCOPE - The "SCOPE" property is used in "VRIGHT"s component to 751 select the subset of data that may be acted upon when checking 752 access rights. (Section 8.33) 754 SEQUENCE - When the "SEQUENCE" property is used in a "VALARM" 755 component it uniquely identifies the instances of the "VALARM" 756 within that component. 758 STORES-EXPANDED - Specifies if the implementation stores recurring 759 object expanded or not. (Section 8.34) 761 TARGET - The new "VCALENDAR" component property "TARGET" 762 (Section 8.35) is used to specify which calendar(s) will be the 763 subject of the CAP command. 765 TRANSP - This is a modification the [iCAL] "TRANSP" property and it 766 allows more values. The new values are related to conflict 767 control. (Section 8.36) 769 2.1.3 New Components (summary) 771 VAGENDA - CAP allows the fetching and storing of the entire contents 772 of a calendar. The "VCALENDAR" component is not sufficient to 773 encapsulate all of the needed data that describes a calendar. The 774 "VAGENDA" component is the encapsulating object for an entire 775 calendar. (Section 9.1) 777 VCALSTORE - Each CS contains one or more calendars (VAGENDAs), the 778 "VCALSTORE" component is the encapsulating object that can hold 779 all of the "VAGENDA" components along with any components and 780 properties that are unique to the store level. (Section 9.2) 782 VCAR - Calendar Access Rights are specified and encapsulated in the 783 new iCalendar "VCAR" component. The "VCAR" component holds some 784 new properties and at least one "VRIGHT" component. (Section 9.3) 786 VRIGHT - This component encapsulates a set of instructions to the CS 787 that define the rights or restrictions needed. (Section 9.4) 789 VREPLY - This component encapsulates a set of data that can consist 790 of an arbitrary amounts of properties and components. Its 791 contents is dependent on the command that was issued. 792 (Section 9.5) 794 VQUERY - The search operation makes use of a new component, called 795 "VQUERY" and a new value type "CAL-QUERY" (Section 6.1.1). The 796 "VQUERY" component is used to fetch objects from the CS. 797 (Section 9.6) 799 2.2 Relationship of RFC-2446 (ITIP) and CAP 801 [iTIP] describes scheduling methods which result in indirect 802 manipulation of components. In CAP, the "CREATE" command is used to 803 deposit entities into the store. Other CAP commands such as 804 "DELETE", "MODIFY" and "MOVE" command values provide direct 805 manipulation of components. In the CAP calendar store model, 806 scheduling messages are conceptually kept separate from other 807 components by their state. 809 All scheduling operations are as defined in [iTIP]. This memo makes 810 no changes to any of the methods or procedures described in [iTIP]. 811 In this memo referring to the presence of the "METHOD" property in an 812 object is the same as saying an [iTIP] object. 814 A CUA may create a "BOOKED" state object by depositing an iCalendar 815 object into the store. This is done by depositing an object that 816 does not have a "METHOD" property. The CS then knows to set the 817 state of the object to the "BOOKED" state. If the object has a 818 "METHOD" property then the object is stored in the "UNPROCESSED" 819 state. 821 If existing "UNPROCESSED" state objects exist in the CS for the same 822 UID (UID is defined in [iCAL]) then a CUA may wish to consolidate the 823 objects in to one "BOOKED" state object. The CUA would fetch the 824 "UNPROCESSED" state objects for that UID and process them in the CUA 825 as described in [iTIP]. Then if the CUA wished to book the UID, the 826 CUA would issue a "CREATE" command to create the new "BOOKED" state 827 object in the CS, followed by a "DELETE" command to remove any 828 related old [iTIP] objects from the CS. And it might also involve 829 having the CUA send some [iMIP] objects or contacting other CSs and 830 performing CAP operations on those CSs. 832 The CUA could also decide not to book the object. In which case the 833 "UNPROCESSED" state objects could be removed from the CS or the CUA 834 could set those object to the marked for delete state. The CUA could 835 also ignore objects for later processing. 837 The marked for delete state is used to keep the object around so that 838 the CUA can process duplicate requests automatically. If a duplicate 839 [iTIP] object is deposited into the CS and there exists identical 840 marked for delete objects, then a CUA acting on behalf of the "OWNER" 841 can silently drop those duplicate entries. 843 Another purpose for the marked for delete state is so that when a CU 844 decides they do not wish to have the object show in their calendar, 845 the CUA can book the object; changing the "PARTSTAT" parameter to 846 "DECLINED" in the "ATTENDEE" property that corresponds to their UPN. 847 Then perform an [iTIP] processing such as sending back a decline. 848 Then mark that object as marked for delete. Their CUA might be 849 configurable to automatically drop any updates for that object 850 knowing the CU has already declined. 852 When synchronizing with multiple CUAs, the marked for delete state 853 could be used to inform the synchronization process that an object is 854 to be deleted. How synchronization is done is not specified in this 855 memo. 857 Several "UNPROCESSED" state entries can be in the CS for the same 858 UID. However once consolidated, then only one object exists in the 859 CS and that is the booked object. The others MUST BE removed, or 860 have their state changed to "DELETED". 862 There MUST NOT BE more than one "BOOKED" state object in a calendar 863 for the same "UID". The "ADD" method value may create multiple 864 objects all in the "BOOKED" state for the same UID, however for the 865 purpose of this memo, they are the same object that simply have 866 multiple "VCALENDAR" components. 868 For example, if you were on vacation, you could have received a 869 "REQUEST" method to attend a meeting and several updates to that 870 meeting. Your CUA would have to issue "SEARCH" commands to find them 871 in the CS using CAP, process them, determine what the final state of 872 the object from a possible combination of user input and programmed 873 logic. Then the CUA would instruct the CS to create a new booked 874 object from the consolidated results. Finally, the CUA could do a 875 "DELETE" command to remove the related "UNPROCESSED" state objects. 876 See [iTIP] for details on resolving multiple [iTIP] scheduling 877 entries. 879 3. CAP Design 881 3.1 System Model 883 The system model describes the high level components of a calendar 884 system and how they interact with each other. 886 CAP is used by a CUA to send commands to and receive responses from a 887 CS. 889 The CUA prepares a [MIME] encapsulated message, sends it to the CS, 890 and receives a [MIME] encapsulated response. The calendaring related 891 information within these messages are represented by iCalendar 892 objects. In addition the "GET-CAPABILITY" command can be sent from 893 the CS to the CUA. 895 There are two distinct protocols in operation to accomplish this 896 exchange. [BEEP] is the transport protocol used to move these 897 encapsulations between a CUA and a CS. CAP's [BEEP] profile defines 898 the application protocol where the content and semantics of the 899 messages sent between the CUA and the CS are specified. 901 3.2 Calendar Store Object Model 903 [iCAL] describes components such as events, todos, alarms, and 904 timezones. [CAP] requires additional object infrastructure. In 905 particular, detailed definitions of the containers for events and 906 todos (calendars), access control objects, and a query language. 908 The conceptual model for a calendar store is shown below. The 909 calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s, 910 "VTIMEZONE"s, "VAGENDA"s and calendar store properties. 912 Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, 913 "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s and calendar 914 properties. 916 The component "VCALSTORE" is used to denote the a root of the 917 calendar store and contains all of the calendars. 919 Calendar Store 921 VCALSTORE 922 | 923 +-- properties 924 +-- VCARs 925 +-- VQUERYs 926 +-- VTIMEZONEs 927 +-- VAGENDA 928 | | 929 | +--properties 930 | +--VEVENTs 931 | | | 932 | | +--VALARMs 933 | +--VTODOs 934 | | | 935 | | +--VALARMs 936 | +--VJOURNALs 937 | +--VCARs 938 | +--VTIMEZONEs 939 | +--VQUERYs 940 | +--VFREEBUSYs 941 | | 942 | | ... 943 . 944 . 945 +-- VAGENDA 946 . . 947 . . 948 . . 950 Calendars within a Calendar Store are identified by their unique 951 Relative CALID. 953 3.3 Protocol Model 955 CAP uses [BEEP] as the transport and authentication protocol. 957 The initial charset MUST BE UTF-8 for the session in an unknown 958 locale. If the CS supplied the [BEEP] 'localize' attribute in the 959 [BEEP] 'greeting' then the CUA may tell the CS to switch locales for 960 the session by issuing the "SET-LOCALE" CAP command and supplying one 961 of the locales supplied by the [BEEP] 'localize' attribute. If 962 supplied the first locale in the [BEEP] 'localize' attribute is the 963 default locale of the CS. The locale is switched only after a 964 successful reply. 966 The "DEFAULT-CHARSET" property of the CS contains the list of 967 charsets supported by the CS with the first value being the default 968 for new calendars. If the CUA wishes to switch to one of those 969 charsets for the session, the CUA issues the "SET-LOCALE" command. 970 The CUA would have to first perform a "GET-CAPABILITY" command on the 971 CS to get the list of charsets supported by the CS. The charset is 972 switched only after a successful reply. 974 The CUA may switch locales and charsets as needed. There is no 975 requirement that a CS support multiple locales or charsets. 977 3.3.1 Use of BEEP, MIME and iCalendar 979 CAP uses the [BEEP] application protocol over TCP. (refer to [BEEP] 980 and [BEEPTCP] for more information). The default port that the CS 981 listens for connections is on user port 1026. 983 The [BEEP] data exchanged in CAP is a iCalendar MIME content that 984 fully conforms to [iCAL] iCalendar format. 986 This example tells the CS to generate and return 10 UIDs to be used 987 by the CUA. Note throughout this memo, 'C:' refers to what the CUA 988 sends, 'S:' refers to what the CS sends, 'I:' refers to what the 989 initiator sends, and 'L:' refers to what the listener sends. Where 990 initiator and listener are used as defined in [BEEP]. 992 C: MSG 1 2 . 432 62 993 C: Content-Type: text/calendar 994 C: 995 C: BEGIN:VCALENDAR 996 C: VERSION:2.0 997 C: PRODID:-//someone's prodid 998 C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID 999 C: END:VCALENDAR 1001 NOTE: The following examples will not include the [BEEP] header and 1002 footer information. Only the iCalendar objects that are sent between 1003 the CUA and CS will be shown as the [BEEP] payload boundaries are 1004 independent of CAP. 1006 The commands listed below are used to manipulate or access the data 1007 on the calendar store: 1009 ABORT - Sent to halt the processing of some of the commands. 1010 (Section 10.2) 1012 CONTINUE - Sent to continue processing a command that has had its 1013 specified timeout time reached. (Section 10.3) 1015 CREATE - Create a new object on the CS. Initiated by the CUA only. 1016 (Section 10.4) 1018 SET-LOCALE - Tell the CS to use any named locale and charset 1019 supplied. Initiated by the CUA only. (Section 10.13) 1021 DELETE - Delete objects from the CS. Initiated by the CUA only. 1022 Can also be used to mark an object for deletion. (Section 10.5) 1024 GENERATE-UID - Generate one or more unique ids. Initiated by the 1025 CUA only. (Section 10.6) 1027 GET-CAPABILITY - Query the capabilities the other end point of the 1028 session. (Section 10.7) 1030 IDENTIFY - Set a new identity for the session. Initiated by the CUA 1031 only. (Section 10.8) 1033 MODIFY - Modify components. Initiated by the CUA only. 1034 (Section 10.9) 1036 MOVE - Move components to another container. Initiated by the CUA 1037 only. (Section 10.10) 1039 REPLY - When replying to a command, the "CMD" value will be set to 1040 "REPLY" so that it will not be confused with a new command. 1041 (Section 10.11) 1043 SEARCH - Search for components. Initiated by the CUA only. 1044 (Section 10.12) 1046 TIMEOUT - Sent when a specified amount of time has lapsed and a 1047 command has not finished. (Section 10.14) 1049 4. Security Model 1051 The [BEEP] transport performs all session authentication. 1053 4.1 Calendar User and UPNs 1055 A CU is an entity that can be authenticated. It is represented in 1056 CAP as a UPN, which is a key part of access rights. The UPN 1057 representation is independent of the authentication mechanism used 1058 during a particular CUA/CS interaction. This is because UPNs are 1059 used within VCARs. If the UPN were dependent on the authentication 1060 mechanism, a VCAR could not be consistently evaluated. A CU may use 1061 one mechanism while using one CUA but the same CU may use a different 1062 authentication mechanism when using a different CUA, or while 1063 connecting from a different location. 1065 The user may also have multiple UPNs for various purposes. 1067 Note that the immutability of the user's UPN may be achieved by using 1068 SASL's authorization identity feature. (The transmitted 1069 authorization identity may be different than the identity in the 1070 client's authentication credentials.) [SASL, section 3]. This also 1071 permits a CU to authenticate using their own credentials, yet request 1072 the access privileges of the identity for which they are proxying 1073 SASL. Also, the form of authentication identity supplied by a 1074 service like TLS may not correspond to the UPNs used to express a 1075 server's access rights, requiring a server specific mapping to be 1076 done. The method by which a server determines a UPN, based on the 1077 authentication credentials supplied by a client, is implementation 1078 specific. See [BEEP] for authentication details; [BEEP] relies on 1079 SASL. 1081 4.1.1 UPNs and Certificates 1083 When using X.509 certificates for purposes of CAP authentication, the 1084 UPN should appear in the certificate. Unfortunately there is no 1085 single correct guideline for which field should contain the UPN. 1087 From RFC-2459, section 4.1.2.6 (Subject): 1089 If subject naming information is present only in the subjectAlt- 1090 Name extension (e.g., a key bound only to an email address or 1091 URI), then the subject name MUST be an empty sequence and the 1092 subjectAltName extension MUST BE critical. 1094 Implementations of this specification MAY use these comparison 1095 rules to process unfamiliar attribute types (i.e., for name 1096 chaining). This allows implementations to process certificates 1097 with unfamiliar attributes in the subject name. 1099 In addition, legacy implementations exist where an RFC 2822 name 1100 is embedded in the subject distinguished name as an EmailAddress 1101 attribute. The attribute value for EmailAddress is of type 1102 IA5String to permit inclusion of the character '@', which is not 1103 part of the PrintableString character set. EmailAddress attribute 1104 values are not case sensitive (e.g., 1105 "fanfeedback@redsox.example.com" is the same as "FANFEEDBACK@ 1106 REDSOX.EXAMPLE.COM"). 1108 Conforming implementations generating new certificates with 1109 electronic mail addresses MUST use the rfc822Name in the subject 1110 alternative name field (see sec. 4.2.1.7 of [X509CRL]) to describe 1111 such identities. Simultaneous inclusion of the EmailAddress 1112 attribute in the subject distinguished name to support legacy 1113 implementations is deprecated but permitted. 1115 Since no single method of including the UPN in the certificate will 1116 work in all cases, CAP implementations MUST support the ability to 1117 configure what the mapping will be by the CS administrator. 1118 Implementations MAY support multiple mapping definitions, for 1119 example, the UPN may be found in either the subject alternative name 1120 field, or the UPN may be embedded in the subject distinguished name 1121 as an EmailAddress attribute. 1123 Note: If a CS or CUA is validating data received via [iMIP], if the 1124 "ORGANIZER" or "ATTENDEE" properties said (e.g.) "ATTENDEE;CN=Joe 1125 Random User:MAILTO:juser@example.com" then the email address should 1126 be checked against the UPN. This is so the "ATTENDEE" property 1127 cannot be changed to something misleading like "ATTENDEE;CN=Joe 1128 Rictus User:MAILTO:jrictus@example.com" and have it pass validation. 1129 Note that it is the email addresses that miscompare, the CN 1130 miscompare is irrelevant. 1132 4.1.2 Anonymous Users and Authentication 1134 Anonymous access is often desirable. For example an organization may 1135 publish calendar information that does not require any access control 1136 for viewing or login. Conversely, a user may wish to view 1137 unrestricted calendar information without revealing their identity. 1139 4.1.3 User Groups 1141 A User Group is used to represent a collection of CUs or other UGs 1142 that can be referenced in VCARs. A UG is represented in CAP as a 1143 UPN. The CUA cannot distinguish between a UPN that represents a CU 1144 or a UG. 1146 UGs are expanded as necessary by the CS. The CS MAY expand a UG 1147 (including nested UGs) to obtain a list of unique CUs. Duplicate 1148 UPNs are filtered during expansion. 1150 How the UG expansion is maintained across commands is implementation 1151 specific. A UG may reference a static list of members, or it may 1152 represent a dynamic list. Operations SHOULD recognize changes to UG 1153 membership. 1155 CAP does not define commands or methods for managing UGs. 1157 4.2 Access Rights 1159 Access rights are used to grant or deny access to calendars, 1160 components, properties, and parameters in a CS to a CU. CAP defines 1161 a new component type called a Calendar Access Right (VCAR). 1162 Specifically, a "VCAR" component grants, or denies, UPNs the right to 1163 search and write components, properties, and parameters on calendars 1164 within a CS. 1166 The "VCAR" component model does not put any restriction on the 1167 sequence in which the object and access rights are created. That is, 1168 an object associated with a particular "VCAR" component might be 1169 created before or after the actual "VCAR" component is defined. In 1170 addition, the "VCAR" and "VEVENT" components might be created in the 1171 same iCalendar object and passed together in a single object. 1173 All rights MUST BE denied unless specifically granted. 1175 If two rights specified in "VCAR" components are in conflict, the 1176 right that denies access always takes precedence over the right that 1177 grants access. Any attempt to create a "VCAR" component that 1178 conflicts with a "VCAR" components with a "DECREED" property set to 1179 the "TRUE" value must fail. 1181 4.2.1 Access Control and NOCONFLICT 1183 The "TRANSP" property can take on values "TRANSPARENT-NOCONFLICT" and 1184 "OPAQUE-NOCONFLICT" that prohibit other components from overlapping 1185 it. This setting overrides access. The "ALLOW-CONFLICT" CS, 1186 Calendar or component setting may also prevent overlap, returning an 1187 error code "6.3". 1189 4.2.2 Predefined VCARs 1191 Predefined calendar access CARIDs that MUST BE implemented are: 1193 CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules that 1194 allow UPNs to search "VFREEBUSY" components. An example 1195 definition for this VCAR is: 1197 BEGIN:VCAR 1198 CARID:READBUSYTIMEINFO 1199 BEGIN:VRIGHT 1200 GRANT:* 1201 PERMISSION:SEARCH 1202 SCOPE:SELECT * FROM VFREEBUSY WHERE STATE() = 'BOOKED' 1203 END:VRIGHT 1204 END:VCAR 1206 CARID:REQUESTONLY - Specifies the "GRANT" and "DENY" rules to UPNs 1207 other than the owner of the calendar the ability to write new 1208 objects with the property "METHOD" property set to the "REQUEST" 1209 value. This CARID allows the owner to specify which UPNs are 1210 allowed to make scheduling requests. An example definition for 1211 this VCAR is: 1213 BEGIN:VCAR 1214 CARID:REQUESTONLY 1215 BEGIN:VRIGHT 1216 GRANT:NON CAL-OWNERS() 1217 PERMISSION:CREATE 1218 RESTRICTION:SELECT VEVENT FROM VAGENDA WHERE METHOD = 'REQUEST' 1219 RESTRICTION:SELECT VTODO FROM VAGENDA WHERE METHOD = 'REQUEST' 1220 RESTRICTION:SELECT VJOURNAL FROM VAGENDA WHERE METHOD = 'REQUEST' 1221 END:VRIGHT 1222 END:VCAR 1224 CARID:UPDATEPARTSTATUS - Grants to authenticated users the right to 1225 modify the instances of the "ATTENDEE" property set to one of 1226 their calendar addresses in any components for any booked 1227 component containing an "ATTENDEE" property. This allows (or 1228 denies) a CU the ability to update their own participation status 1229 in a calendar where they might not otherwise have "MODIFY" command 1230 access. They are not allowed to change the "ATTENDEE" property 1231 value. An example definition for this VCAR is (This example only 1232 affects the "VEVENT" components): 1234 BEGIN:VCAR 1235 CARID:UPDATEPARTSTATUS 1236 BEGIN:VRIGHT 1237 GRANT:* 1238 PERMISSION:MODIFY 1239 SCOPE:SELECT ATTENDEE FROM VEVENT 1240 WHERE ATTENDEE = SELF() 1241 AND ORGANIZER = CURRENT-TARGET() 1242 AND STATE() = 'BOOKED' 1243 RESTRICTION:SELECT * FROM VEVENT 1244 WHERE ATTENDEE = SELF() 1245 END:VRIGHT 1246 END:VCAR 1248 CARID:DEFAULTOWNER - Grants to any owner the permission they have 1249 for the target. An example definition for this VCAR is: 1251 BEGIN:VCAR 1252 CARID:DEFAULTOWNER 1253 BEGIN:VRIGHT 1254 GRANT:CAL-OWNERS() 1255 PERMISSION:* 1256 SCOPE:SELECT * FROM VAGENDA 1257 END:VRIGHT 1258 END:VCAR 1260 4.2.3 Decreed VCARs 1262 A CS MAY choose to implement and allow persistent immutable VCARs 1263 that may be configured by the CS administrator. A reply from the CS 1264 may dynamically create "VCAR" components that are decreed depending 1265 on the implementation. To the CUA any "VCAR" component with the 1266 "DECREED" property set to "TRUE" can not be changed by the currently 1267 authenticated UPN, and depending on the implementation and other 1268 "VCAR" components; might not be able to be changed by any UPN using 1269 CAP, and never when the CUA gets a "DECREED:TRUE" VCAR. 1271 When a user attempts to modify or override a decreed "VCAR" component 1272 rules an error will be returned indicating that the user has 1273 insufficient authorization to perform the operation. The reply to 1274 the CUA MUST BE the same as if a non-decreed VCAR caused the failure. 1276 The CAP protocol does not define the semantics used to initially 1277 create a decreed VCAR. This administrative task is outside the scope 1278 of the CAP protocol. 1280 For example; an implementation or a CS administrator may wish to 1281 define a VCAR that will always allow the calendar owners to have full 1282 access to their own calendars. 1284 Decreed "VCAR" components MUST BE readable by the calendar owner in 1285 standard "VCAR" component format. 1287 4.3 CAP Session Identity 1289 A [BEEP] session has an associated set of authentication credentials, 1290 from which is derived a UPN. This UPN is the identity of the CAP 1291 session, and is used to determine access rights for the session. 1293 The CUA may change the identity of a CAP session by calling the 1294 "IDENTIFY" command. The CS only permits the operation if the 1295 session's authentication credentials are good for the requested 1296 identity. The method of checking this permission is implementation 1297 dependent, but may be thought of as a mapping from authentication 1298 credentials to UPNs. The "IDENTIFY" command allows a single set of 1299 authentication credentials to choose from multiple identities, and 1300 allows multiple sets of authentication credentials to assume the same 1301 identity. 1303 For anonymous access the identity of the session is "@". A UPN with 1304 a null Username and null Realm is anonymous. A UPN with a null 1305 Username, but non-null Realm, such as "@example.com" may be used to 1306 mean any identity from that Realm, which is useful to grant access 1307 rights to all users in a given Realm. A UPN with a non-null Username 1308 and null Realm, such as "bob@" could be a security risk and MUST NOT 1309 be used. 1311 As the UPN includes Realm information it may be used to govern 1312 calendar store access rights across Realms. However, governing 1313 access rights across Realms is only useful if login access is 1314 available. This could be done through a trusted server relationship 1315 or a temporary account. Note that trusted server relationships are 1316 outside the scope of [CAP]. 1318 The "IDENTIFY" command also provides for a weak group implementation. 1319 By allowing multiple sets of authentication credentials belonging to 1320 different users to identify as the same UPN, that UPN essentially 1321 identifies a group of people, and may be used for group calendar 1322 ownership, or the granting of access rights to a group. 1324 5. CAP URL and Calendar Address 1326 The CAP URL scheme is used to designate calendar stores and calendars 1327 accessible using the CAP protocol. 1329 The CAP URL scheme conform to the generic URL syntax, defined in RFC 1330 2396, and follows the Guidelines for URL Schemes, set forth in RFC 1331 2718. 1333 A CAP URL begins with the protocol prefix "cap" and is defined by the 1334 following grammar. 1336 capurl = "cap://" csidpart [ "/" relcalid ] 1337 ; 1338 csidpart = hostport ; As defined in Section 3.2.2 of RFC 2396 1339 ; 1340 relcalid = *uric ; As defined in Section 2 of RFC 2396 1342 A 'relcalid' is an identifier that uniquely identifies a calendar on 1343 a particular calendar store. There is no implied structure in a 1344 Relative CALID (relcalid). It may refer to the calendar of a user or 1345 of a resource such as a conference room. It MUST BE unique within 1346 the calendar store. 1348 Examples: 1350 cap://cal.example.com 1351 cap://cal.example.com/Company/Holidays 1352 cap://cal.example.com/abcd1234Usr 1354 A 'relcalid' is permitted and is resolved according to the rules 1355 defined in Section 5 of RFC 2396. 1357 Examples of valid relative CAP URLs: 1359 opqaueXzz123String 1360 UserName/Personal 1362 A Calendar addresses can be described as qualified or relative CAP 1363 URLs. 1365 For a user currently authenticated to the CS on cal.example.com, 1366 these two example calendar addresses refer to the same calendar: 1368 cap://cal.example.com/abcd1234USR 1369 abcd1234USR 1371 6. New Value Types 1373 The following sections contains new components, properties, 1374 parameters, and value definitions. 1376 The purpose of these is to extend the iCalendar objects in a 1377 compatible way so that existing iCalendar "VERSION" property "2.0" 1378 value parsers can still parse the objects without modification. 1380 6.1 Property Value Data Types 1382 6.1.1 CAL-QUERY Value Type 1384 Subject: Registration of text/calendar MIME value type CAL-QUERY 1386 Value Name: CAL-QUERY 1388 Value Type Purpose: This value type is used to identify values and 1389 contains query statements targeted at locating those values. 1391 This is based on [SQL92] and [SQLCOM]. 1393 1. For the purpose of a query, all components should be handled as 1394 tables, and the properties of those components, should be handled 1395 as columns. 1397 2. All VAGENDAs and CSs look like tables for the purpose of a QUERY. 1398 And all of their properties look like columns in those tables. 1400 3. You CAN NOT do any cross component-type joins. And that means 1401 you can ONLY have one component, OR one "VAGENDA" component OR 1402 one "VCALSTORE" component in the "FROM" clause. 1404 4. Everything in the "SELECT" clause and "WHERE" clauses in MUST BE 1405 from the same component type, or "VAGENDA" component OR 1406 "VCALSTORE" component in the "FROM" clause. 1408 5. When multiple "QUERY" properties are supplied in a single 1409 "VQUERY" component, the results returned are the same as the 1410 results returned for multiple "VQUERY" components having each a 1411 single "QUERY" property. 1413 6. The '.' is used to separate the table name (component) and column 1414 name (property or component) when selecting a property that is 1415 contained inside of a component that is targeted in the TARGET 1416 property. 1418 7. A contained component without a '.' is not the same as 1419 "component-name.*". If given as "component-name" (no dot) the 1420 encapsulating BEGIN/END statement will be supplied for 1421 "component-name".: 1423 In this example the '.' is used to separate the "TRIGGER" property 1424 from its contained component (VALARM). Which is contained in any 1425 "VEVENT" component in the selected "TARGET" property value (a 1426 relcalid). All "TRIGGER" properties in any "VEVENT" component in 1427 relcalid would be returned. 1429 TARGET:relcalid 1430 QUERY:SELECT VALARM.TRIGGER FROM VEVENT 1432 SELECT VALARM FROM VEVENT WHERE UID = "123" 1434 This returns one BEGIN/END "VALARM" component for each 1435 "VALARM" component in the matching "VEVENT" component. 1436 As there is no '.' (dot) in the VALARM after the SELECT above: 1438 BEGIN:VALARM 1439 TRIGGER;RELATED=END:PT5M 1440 REPEAT:4 1441 ... 1442 END:VALARM 1443 BEGIN:VALARM 1444 TRIGGER;RELATED=START:PT5M 1445 DURATION:PT10M 1446 ... 1447 END:VALARM 1448 ... 1449 ... 1451 If provided as "component-name.*", then only the properties and any 1452 contained components will be returned: 1454 SELECT VALARM.* FROM VEVENT WHERE UID = "123" 1456 Will return all of the properties in each "VALARM" component 1457 in the matching "VEVENT" component: 1459 TRIGGER;RELATED=END:PT5M 1460 REPEAT:4 1461 ... 1462 TRIGGER;RELATED=START:PT5M 1463 DURATION:PT10M 1464 ... 1465 ... 1467 (a) SELECT FROM VEVENT 1469 (b) SELECT VALARM FROM VEVENT 1471 (c) SELECT VALARM.* FROM VEVENT 1473 (d) SELECT * FROM VEVENT 1475 (e) SELECT * FROM VEVENT WHERE 1476 VALARM.TRIGGER < '20020201T000000Z' 1477 AND VALARM.TRIGGER > '20020101T000000Z' 1479 Note: 1480 (a) Selects all instances of 1481 from all "VEVENT" components. 1483 (b) and (c) Select all "VALARM" components from all 1484 "VEVENT" components. (b) would return then in 1485 BEGIN/END VALARM tags. (c) would return all 1486 of the properties without BEGIN/END VALARM tags. 1488 (d) Selects every property and every component 1489 that is in any "VEVENT" component, with each "VEVENT" 1490 component wrapped in a BEGIN/END VEVENT tags. 1492 (e) Selects all properties and all contained 1493 components in all "VEVENT" components that have a "VALARM" 1494 component with a "TRIGGER" property value between 1495 the provided dates and times, with each "VEVENT" 1496 component wrapped in a BEGIN/END VEVENT tags. 1498 NOT VALID: 1500 (f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT 1502 (g) SELECT DTSTART,UID FROM VEVENT WHERE 1503 VTODO.SUMMERY = "Fix typo in CAP" 1505 Note: (f) Is NOT valid because it contains 1506 two '.' characters in the "SELECT" clause. 1508 (g) Is NOT valid because it mixes VEVENT 1509 and VTODO properties in the same VQUERY. 1511 Formal Definition: The value type is defined by the following 1512 notation: 1514 cal-query = "SELECT" SP cap-val SP 1515 "FROM" SP comp-name SP 1516 "WHERE" SP cap-expr 1518 / "SELECT" SP cap-cols SP 1519 "FROM" SP comp-name 1520 ; 1521 cap-val = cap-cols / param 1522 / ( cap-val "," cap-val ) 1523 ; 1524 ; NOTE: there is NO space around the "," on 1525 ; the next line 1526 cap-cols = cap-col / ( cap-cols "," cap-col) 1527 / "*" 1528 / "*.*" ; only valid when the target is a "VAGENDA" 1529 ; 1530 ; A 'cap-col' is: 1531 ; 1532 ; Any property name ('cap-prop') found in the component 1533 ; named in the 'comp-name' used in the "FROM" clause. 1534 ; 1535 ; SELECT ORGANIZER FROM VEVENT ... 1536 ; 1537 ; OR 1538 ; 1539 ; A component name ('comp-name') of an existing component 1540 ; contained inside of the 'comp-name' used in the "FROM" 1541 ; clause. 1542 ; 1543 ; SELECT VALARM FROM VEVENT ... 1544 ; 1545 ; OR 1546 ; 1547 ; A component name ('comp-name') of an existing 1548 ; component contained inside of the 'comp-name' used 1549 ; in the "FROM" clause followed by a property 1550 ; name ('cap-prop') to be selected from that component. 1551 ; (comp-name "." cap-prop) 1552 ; 1553 ; SELECT VALARM.TRIGGER FROM VEVENT ... 1554 ; 1555 cap-col = comp-name 1556 / comp-name "." cap-prop 1557 / cap-prop 1558 ; 1559 comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" 1560 / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" 1561 / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" 1562 / "VRIGHT" / x-comp / iana-comp 1563 ; 1564 cap-prop = ; A property that may be in the 'cap-comp' named 1565 ; in the "SELECT" clause. 1566 ; 1567 cap-expr = "(" cap-expr ")" 1568 / cap-term 1569 ; 1570 cap-term = cap-expr SP cap-logical SP cap-expr 1571 / cap-factor 1572 ; 1573 cap-logical= "AND" / "OR" 1574 ; 1575 cap-factor = cap-colval SP cap-oper SP col-value 1576 / cap-colval SP "LIKE" SP col-value 1577 / cap-colval SP "NOT LIKE" SP col-value 1578 / cap-colval SP "IS NULL" 1579 / cap-colval SP "IS NOT NULL" 1580 / col-value SP "IN" cap-colval 1581 / col-value SP "NOT IN" cap-colval 1582 / "STATE()" "=" ( "BOOKED" 1583 / "UNPROCESSED" 1584 / "DELETED" 1585 / iana-state 1586 / x-state ) 1587 ; 1588 iana-state = ; Any state registered by IANA directly or 1589 ; included in an RFC that may be applied to 1590 ; the component and within the rules published. 1591 ; 1592 x-state = ; Any experimental state that starts with 1593 ; "x-" or "X-". 1594 ; 1595 cap-colval = cap-col / param 1596 ; 1597 param = "PARAM(" cap-col "," cap-param ")" 1598 ; 1599 cap-param = ; Any parameter that may be contained in the cap-col 1600 ; in the supplied PARAM() function 1601 ; 1602 col-value = col-literal 1603 / "SELF()" 1604 / "CAL-OWNERS()" 1605 / "CAL-OWNERS(" cal-address ")" 1606 / "CURRENT-TARGET()" 1607 ; 1608 cal-address = ; A CALID as define by CAP 1609 ; 1611 col-literal = "'" literal-data "'" 1612 ; 1613 literal-data = ; Any data that matches the value type of the 1614 ; column that is being compared. That is you can 1615 ; not compare PRIORITY to "some string" because 1616 ; PRIORITY has a value type of integer. If it is 1617 ; not preceded by the LIKE element, any '%' and '_' 1618 ; characters in the literal data are not treated as 1619 ; wildcard characters and do not have to be backslash 1620 ; escaped. 1621 ; 1622 ; OR 1623 ; 1624 ; If the literal-data is preceded by the LIKE 1625 ; element it may also contain the '%' and '_' 1626 ; wildcard characters. And if the literal data 1627 ; that is comparing contains any '%' or '_' 1628 ; characters, they MUST BE backslash escaped as 1629 ; described in the notes below in order for them not 1630 ; to be treated as wildcard characters. 1631 ; 1632 ; And if the literal data contains any characters 1633 ; that would have to be backslash escaped if 1634 ; a property or parameter value then they must 1635 ; be backslash escaped in the literal-data. 1636 ; PLUS the quote character (') must be backslash 1637 ; escaped. Example: 1638 ; 1639 ; ... WHERE SUBJECT = 'It\'s time to ski' 1640 ; 1641 cap-oper = "=" 1642 / "!=" 1643 / "<" 1644 / ">" 1645 / "<=" 1646 / ">=" 1647 ; 1648 SP = ; A single white space ASCII character 1649 ; (value in HEX %x20). 1650 ; 1651 x-comp = ; As defined in [iCAL] section 4.6 1652 ; 1653 iana-comp = ; As defined in [iCAL] section 4.6 1655 6.1.1.1 [NOT] CAL-OWNERS() 1657 This function returns the list of "OWNER" properties for the named 1658 calendar when used in the "SELECT" clause. 1660 If called as 'CAL-OWNERS()', it is equivalent to the comma separated 1661 list of all of the owners of the calendar that match the provided 1662 "TARGET" property value. If the target is a "VCALSTORE", it returns 1663 the "CALMASTER" property. 1665 If called as 'CAL-OWNERS(cal-address)', then it is the equivalent to 1666 the comma separated list of owners for the named calendar id. If 1667 'cal-address' is a CS, it returns the "CALMASTER" property. 1669 If used in the "WHERE" clause it then returns true if the currently 1670 authenticated UPN is an owner of the currently selected object 1671 matched in the provided "TARGET" property. Used in a CAL-QUERY 1672 "WHERE" clause and in the UPN-FILTER. 1674 6.1.1.2 CURRENT-TARGET() 1676 Is equivalent to the value of the "TARGET" property in the current 1677 command. Used in a CAL-QUERY "WHERE" clause. 1679 6.1.1.3 PARAM() 1681 Used in a CAL-QUERY. Returns or tests for the value of the named 1682 parameter from the named property. 1684 6.1.1.3.1 PARAM() in SELECT 1686 When used in a "SELECT" clause, it returns the entire property and 1687 all of that properties parameters (the result is not limited to the 1688 supplied parameter). If the property does not contain the named 1689 parameter, then the property is not returned (It could however be 1690 returned as a result of another "SELECT" clause value.) If multiple 1691 properties of the supplied name have the named parameter, all 1692 properties with that named parameter are returned. If multiple 1693 PARAM() clauses in a single "SELECT" CLAUSE match the same property, 1694 then the single matching property is returned only once. 1696 Also note that many parameters have default values defined in [iCAL] 1697 that must be treated as existing with their default value in the 1698 properties as defined in [iCAL} even when not explicitly present. So 1699 for example if a query were performed with PARAM(ATTENDEE,ROLE) then 1700 ALL "ATTENDEE" properties would match because even when they do not 1701 explicitly contain the "ROLE" parameter, it has a default value and 1702 therefore must match. 1704 So when PARAM() is used in a "SELECT" clause, then it is more 1705 accurate to say that it means return the property if it contains the 1706 named parameter explicitly in the property or simply because the 1707 parameter has a default for that property. 1709 6.1.1.3.2 PARAM() in WHERE 1711 When used in the "WHERE" clause, a match is true when the parameter 1712 value matches the compare clause according to the supplied WHERE 1713 values. If multiple named properties contain the named parameter, 1714 then each parameter value is compared in turn to the condition and if 1715 any match, then the results would be true for that condition the same 1716 as if only one had existed. Each matching properties or components 1717 are returned only once. 1719 As a parameter may be multivalued then the comparison might need to 1720 be done with an "IN" or "NOT IN" comparator. 1722 Given the following query: 1724 ATTENDEE;PARTSTAT=ACCEPTED:cap://host.com/joe 1726 SELECT VEVENT FROM VAGENDA 1727 WHERE PARAM(ATTENDEE,PARTSTAT) = 'ACCEPTED' 1729 Then all "VEVENT" components that contain one or more "ATTENDEE" 1730 properties that have a "PARTSTAT" parameter with a "ACCEPTED" value 1731 would be returned. And each uniquely matching VEVENT would only be 1732 returned once no matter how many "ATTENDEE" properties had matching 1733 roles in each unique "VEVENT" component. 1735 Also note that many parameters have default values defined in [iCAL]. 1736 So if the following query were performed on the "ATTENDEE" property 1737 in the above example: 1739 SELECT VEVENT FROM VAGENDA 1740 WHERE PARAM(ATTENDEE,ROLE) = 'REQ-PARTICIPANT' 1742 It would return the "ATTENDEE" property exampled above because the 1743 default value for the "ROLE" parameter is "REQ-PARTICIPANT". 1745 6.1.1.4 SELF() 1747 Used in a CAL-QUERY "WHERE" clause. Returns the UPN of the currently 1748 authenticated UPN or their current UPN as a result of an IDENTIFY 1749 command. 1751 6.1.1.5 STATE() 1753 Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" 1754 depending on the state of the object. Where "DELETED" is a component 1755 in the marked for delete state. Components that have been removed 1756 from the store are never returned. 1758 If not specified in a query then both "BOOKED" and "UNPROCESSED" data 1759 is returned. Each unique "METHOD" property must be in a separate 1760 MIME object per the [iCAL] section 3.2 restriction. 1762 6.1.1.6 Use of single quote 1764 All literal values are surrounded by single quotes ('), not double 1765 quotes ("), and not without any quotes. If the value contains quotes 1766 or any other ESCAPED-CHAR, they MUST BE backslash escaped as 1767 described in section 4.3.11 "Text" of [iCAL]. Any "LIKE" clause 1768 wildcard characters that are part of any literal data that is 1769 preceded by a "LIKE" clause or "NOT LIKE" clause and is not intended 1770 to mean wildcard search MUST BE escaped as described in note (7) 1771 below. 1773 6.1.1.7 Comparing DATE and DATE-TIME values 1775 When comparing "DATE-TIME" values to "DATE" values and when comparing 1776 "DATE" values to "DATE-TIME" values, the result will be true if the 1777 "DATE" value is on the same day as the "DATE-TIME" value. And they 1778 are compared in UTC no matter what time zone the data may actual have 1779 been stored in. 1781 Local time event as descibed in section 4.2.19 of [iCAL] must be 1782 considered to be in the CUA default timezone that was supplied by the 1783 CUA in the "CAPABILITY" exchange. 1785 VALUE-1 VALUE-2 Compare Results 1787 20020304 20020304T123456 TRUE 1788 (in UTC-3) (in UTC-3) 1790 20020304 20020304T003456 FALSE 1791 (in UTC) (in UTC-4) 1793 20020304T003456Z 20020205T003456 FALSE 1794 (in UTC-0) (in UTC-7) 1796 When comparing "DATE" values and "DATE-TIME" values with the "LIKE" 1797 clause the comparison will be done as if the value is a [iCAL] DATE 1798 or DATE-TIME string value. 1800 LIKE '2002%' will match anything in the year 2002. 1802 LIKE '200201%' will match anything in January 2002. 1804 LIKE '%T000000' will match anything at midnight. 1806 LIKE '____01__T%' will match anything for any year or 1807 time that is in January. 1808 (Four '_', '01', two '_' 'T%'). 1810 Using a "LIKE" clause value of "%00%, would return any value that 1811 contained two consecutive zeros. 1813 All comparisons will be done in UTC. 1815 6.1.1.8 DTEND and DURATION 1817 The "DTEND" property value is not included in the time occupied by 1818 the component. That is a "DTEND" property value of 20030614T12000 1819 includes all of the time up to but not including noon on that day. 1821 The "DURATION" property value end time is also not inclusive. So an 1822 object with a "DTSTART" property value of 20030514T110000 and a 1823 "DURATION" property value of "1H" does not include noon on that day. 1825 When a "QUERY" property value contains a "DTEND" value, then the CS 1826 MUST also evaluate any existing "DURATION" property value and 1827 determine if it has an effective end time that matches the "QUERY" 1828 property supplied "DTEND" value or any range of values supplied by 1829 the "QUERY" property. 1831 When a "QUERY" property contains a "DURATION" value, then the CS MUST 1832 also evaluate any existing "DTEND" property values and determine if 1833 they have an effective duration that matches the "QUERY" property 1834 value supplied "DURATION" value or any range of values supplied by 1835 the "QUERY" property. 1837 6.1.1.9 [NOT] LIKE 1839 The pattern matching characters are the '%' that matches zero or more 1840 characters, and '_' that matches exactly one character (where 1841 character does not always mean octet). 1843 "LIKE" clause pattern matches always cover the entire string. To 1844 match a pattern anywhere within a string, the pattern must start and 1845 end with a percent sign. 1847 To match a '%' or '_' in the data and not have it interpreted as a 1848 wildcard character, they MUST BE backslash escaped. That is to 1849 search for a '%' or '_' in the string: 1851 LIKE '%\%%' Matches any string with a '%' in it. 1852 LIKE '%\_%' Matches any string with a '_' in it. 1854 Strings compared using the "LIKE" clause MUST BE performed using case 1855 in-sensitive comparisons when the locale allows. (Example: in US- 1856 ASCII the compare assumes 'a' = 'A'). 1858 If the "LIKE" clause is preceded by 'NOT' then there is a match when 1859 the string compare fails. 1861 Some property values (such as the 'recur' value type), contain commas 1862 and are not multi valued. The CS must understand the objects being 1863 compared and understand how to determine how any multi valued or 1864 multi instances properties or parameter values are separated, quoted, 1865 and backslash escaped and perform the comparisons as if each value 1866 existed by itself and not quoted or backslash escaped when comparing 1867 using the LIKE element. 1869 See related examples in Section 6.1.1.11 1871 6.1.1.10 Empty vs. NULL 1873 When used in a CAL-QUERY value, "NULL" means that the property or 1874 parameter is not present in the object. Paramaters that are not 1875 provided and have a default value in the property are considered to 1876 exist with their default value and will not be "NULL". 1878 If the property exists but has no value then "NULL" MUST NOT match. 1879 If the parameter exists but has no value then "NULL" MUST NOT match. 1880 If the parameter not present and has a default value then "NULL" MUST 1881 NOT match. 1883 If the property (or parameter) exists, but has no value then it 1884 matches the empty string '' (quote quote). 1886 6.1.1.11 [NOT] IN 1888 This is similar to the "LIKE" clause, except it does value matching 1889 and not string comparison matches. 1891 Some iCalendar objects can be multi instance and multi valued. The 1892 "IN" clause will return a match if the literal value supplied as part 1893 of the "IN" clause is contained in the value of any instance of the 1894 named property or parameter, or is in any of the multiple values in 1895 the named property or parameter. Unlike the "LIKE" clause, the '%' 1896 and '_' matching characters are not used with the "IN" clause and 1897 have no special meaning. 1899 BEGIN:A-COMPONENT 1900 a property:value1,value2 One property, two values. 1901 b property:"value1,value2" One property, one value. 1902 c property:parameter=1,2:x One parameter, two values. 1903 d property:parameter="1,2",3:y One parameter, one value. 1904 e property:parameter=",":z One parameter, one value. 1905 f property:x,y,z One property, three values 1906 END:A-COMPONENT 1908 'value1' IN property would match (a) only. 1909 'value1,value2' IN property would match (b) only. 1910 'value%' IN property would NOT match any. 1911 ',' IN property would NOT match any. 1912 '%,%' IN property would NOT match any. 1913 'x' IN property would match (f) and (c). 1914 '2' IN parameter would match (c) only. 1915 '1,2' IN parameter would match (d) only. 1916 ',' IN parameter would match (e) only. 1917 '%,%' IN parameter would NOT match any. 1919 property LIKE 'value1%' would match (a) and (b). 1920 property LIKE 'value%' would match (a) and (b). 1921 property LIKE 'x' would match (f) and (c). 1922 parameter LIKE '1%' would match (c) and (d). 1923 parameter LIKE '%2%' would match (c) and (d). 1924 parameter LIKE ',' would match (e) only. 1926 Some property values (such as the "RECUR" value type), contain commas 1927 and are not multi valued. The CS must understand the objects being 1928 compared and understand how to determine how any multi valued or 1929 multi instances properties or parameter values are separated, quoted, 1930 and backslash escaped and perform the comparisons as if each value 1931 existed by itself and not quoted or backslash escaped when comparing 1932 using the IN element. 1934 If the "IN" clause is preceded by 'NOT' then there is a match when 1935 the value does not exist in the property or parameter value. 1937 6.1.1.12 DATE-TIME and TIME values in a WHERE clause 1939 All "DATE-TIME" and "TIME" literal values supplied in a "WHERE" 1940 clause MUST BE terminated with 'Z'. That means that the CUA MUST 1941 supply the values in UTC. 1943 Valid: 1945 WHERE alarm.TRIGGER < '20020201T000000Z' 1946 AND alarm.TRIGGER > '20020101T000000Z' 1948 Not valid and it is a syntax error and the CS MUST reject the QUERY. 1950 WHERE alarm.TRIGGER < '20020201T000000' 1951 AND alarm.TRIGGER > '20020101T000000' 1953 6.1.1.13 Multiple contained components 1955 If a query references a component and a component or property 1956 contained in the component, any clauses referring to the contained 1957 component or property must be evaluated on all of the contained 1958 components or properties. If any of the contained components or 1959 properties match the query, and the conditions on the containing 1960 component are also true, the component matches the query. 1962 For example, in the query below, if a BOOKED VEVENT contains multiple 1963 VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs 1964 in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT 1965 would be included in the QUERY results. 1967 BEGIN:VQUERY 1968 EXPAND:TRUE 1969 QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT 1970 WHERE VALARM.TRIGGER >= '20000101T030405Z' 1971 AND VALARM.TRIGGER <= '20001231T235959Z' 1972 AND STATE() = 'BOOKED' 1973 END:VQUERY 1975 6.1.1.14 Example, Query by UID 1977 The following example would match the entire content of a "VEVENT" or 1978 "VTODO" component with the "UID" property equal to "uid123" and not 1979 expand any multiple instances of the component. If the CUA does not 1980 know if "uid123" was a "VEVENT", "VTODO", "VJOURNAL", or any other 1981 component, then all components that the CUA supports MUST BE supplied 1982 in a QUERY property. This example assumes the CUA is only interested 1983 in "VTODO" and "VEVENT" components. 1985 If the results were empty it could also mean that "uid123" was a 1986 property in a component other than a VTODO or VEVENT. 1988 BEGIN:VQUERY 1989 QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' 1990 QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' 1991 END:VQUERY 1993 6.1.1.15 Query by Date-Time range 1995 This query selects the entire content of every booked "VEVENT" 1996 component that has an instance greater than or equal to July 1st, 1997 2000 00:00:00 UTC and less than or equal to July 30st, 2000 23:59:59 1998 UTC. This includes single instance "VEVENT" components that do no 1999 explicitly contain any recurence properties or "RECURRENCE-ID" 2000 properties. This works only for CSs that have the "RECUR-EXPAND" 2001 property value set to "TRUE" in the "GET-CAPABILITY" exchange. 2003 BEGIN:VQUERY 2004 EXPAND:TRUE 2005 QUERY:SELECT * FROM VEVENT 2006 WHERE RECURRENCE-ID >= '20000701T000000Z' 2007 AND RECURRENCE-ID <= '20000730T235959Z' 2008 AND STATE() = 'BOOKED' 2009 END:VQUERY 2011 6.1.1.16 Query for all Unprocessed Entries 2013 The following example selects the entire contents of all non-booked 2014 "VTODO" and "VEVENT" components in the "UNPROCESSED" state. The 2015 default for the "EXPAND" property is "FALSE", so the recurrence rules 2016 will not be expanded. 2018 BEGIN:VQUERY 2019 QUERYID:Fetch VEVENT and VTODO iTIP components 2020 QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' 2021 QUERY:SELECT * FROM VTODO WHERE STATE() = 'UNPROCESSED' 2022 END:VQUERY 2024 The following example fetches all "VEVENT" and "VTODO" components in 2025 the "BOOKED" state. 2027 BEGIN:VQUERY 2028 QUERYID:Fetch All Booked VEVENT and VTODO components 2029 QUERY:SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' 2030 QUERY:SELECT * FROM VTODO WHERE STATE() = 'BOOKED' 2031 END:VQUERY 2033 The following fetches the "UID" property for all "VEVENT" and "VTODO" 2034 components that have been marked for delete. 2036 BEGIN:VQUERY 2037 QUERYID:Fetch UIDs of marked for delete VEVENTs and VTODOs 2038 QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETED' 2039 QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETED' 2040 END:VQUERY 2042 6.1.1.17 Query with Subset of Properties by Date/Time 2044 In this example only the named properties will be selected and all 2045 booked and non-booked components will be selected that have a 2046 "DTSTART" value from February 1st to February 10th 2000 (in UTC). 2048 BEGIN:VQUERY 2049 QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT 2050 WHERE DTSTART >= '20000201T000000Z' 2051 AND DTSTART <= '20000210T235959Z' 2052 END:VQUERY 2054 6.1.1.18 Query with Components and Alarms In A Range 2056 This example fetches all booked "VEVENT" components with an alarm 2057 that triggers within the specified time range. In this case only the 2058 "UID", "SUMMARY", and "DESCRIPTION" properties will be selected for 2059 all booked "VEVENTS" components that have an alarm between the two 2060 date-times supplied. 2062 BEGIN:VQUERY 2063 EXPAND:TRUE 2064 QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT 2065 WHERE VALARM.TRIGGER >= '20000101T030405Z' 2066 AND VALARM.TRIGGER <= '20001231T235959Z' 2067 AND STATE() = 'BOOKED' 2068 END:VQUERY 2070 6.1.2 UPN Value Type 2072 Value Name: UPN 2074 Purpose: This value type is used to identify values that contain user 2075 principal name of CU or group of CU. 2077 Formal Definition: The value type is defined by the following 2078 notation: 2080 ; 2081 upn = "@" 2082 / [ dot-atom-text ] "@" dot-atom-text 2083 ; 2084 ; dot-atom-text is defined in RFC 2822 2085 ; 2086 ; 2087 dot-atom-text = ; As defined in [iCAL] 2089 Description: This data type is an identifier that denotes a CU or a 2090 group of CU. A UPN is a RFC 2822 compliant email address, with 2091 exceptions listed below, and in most cases it is deliverable to the 2092 CU. In some cases it is identical to the CU's well known email 2093 address. A CU's UPN MUST never be an e-mail address that is 2094 deliverable to a different person. And there is no requirement that 2095 a person's UPN MUST BE their e-mail address. A UPN is formatted as a 2096 user name followed by "@" followed by a Realm in the form of a valid, 2097 and unique, DNS domain name. The user name MUST BE unique within the 2098 Realm. In it's simplest form it looks like "user@example.com". 2100 In certain cases a UPN will not be RFC 2822 compliant. When 2101 anonymous authentication is used, or anonymous authorization is being 2102 defined, the special UPN "@" will be used. When authentication MUST 2103 BE used, but unique identity MUST BE obscured, a UPN of the form 2104 @DNS-domain-name may be used. For example, "@example.com". 2106 Example: 2108 The following is a UPN for a CU: 2110 jdoe@example.com 2112 The following is a example of a UPN that could be for a group of CU: 2114 staff@example.com 2116 The following is a UPN for an anonymous CU belonging to a specific 2117 realm or when used as a UPN-FILTER it specifies that it applies to 2118 all UPNs in a specific realm: 2120 @example.com 2122 The following is a UPN for an anonymous CU: 2124 @ 2126 6.1.3 UPN-FILTER Value 2128 Value Name: UPN-FILTER 2130 Purpose: This value type is used to identify values that contain a 2131 user principal name filter. 2133 Formal Definition: The value type is defined by the following 2134 notation: 2136 ; 2137 ; NOTE: "CAL-OWNERS(cal-address)" 2138 ; and "NOT CAL-OWNERS(cal-address)" 2139 ; are both NOT allowed below. 2140 ; 2141 upn-filter = "CAL-OWNERS()" / 2142 "NOT CAL-OWNERS()" / 2143 "*" / 2144 [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) 2145 ; 2146 ; dot-atom-text is defined in RFC 2822 2148 Description: The value is used to match user principal names (UPNs). 2149 For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.24. 2151 * Matches all UPNs. 2153 @ Matches the UPN of anonymous CUs 2154 belonging to the null realm 2156 @* Matches the UPN of anonymous CUs 2157 belonging to any non-null realm 2159 @realm Matches the UPN of anonymous CUs 2160 belonging to the specified realm. 2162 *@* Matches the UPN of non-anonymous CUs 2163 belonging to any non-null realm 2165 *@realm Matches the UPN of non-anonymous CUs 2166 belonging to the specified realm 2168 user@realm Matches the UPN of the specified CU 2169 belonging to the specified realm 2171 user@* Not allowed. 2173 user@ Not allowed. 2175 Example: The following are examples of this value type: 2177 DENY:NON CAL-OWNERS() 2178 DENY:@hackers.example.com 2179 DENY:*@hackers.example.com 2180 GRANT:sam@example.com 2182 7. New Parameters 2184 7.1 ACTION Parameter 2186 Parameter Name: ACTION 2188 Purpose: This parameter indicates the action to be taken when a 2189 timeout occurs. 2191 Value Type: TEXT 2193 Conformance: This property can be specified in the "CMD" property. 2195 When present in a "CMD" property the "ACTION" parameter specifies the 2196 action to be taken when the command timeout expires. 2198 Formal Definition: The parameter is defined by the following 2199 notation: 2201 action-param = ";" "ACTION" "=" ( "ASK" / "ABORT" ) 2202 ; If 'action-param' is supplied then 2203 ; 'latency-param' MUST BE supplied. 2205 Example: The following is an example of this parameter: 2207 CMD;LATENCY=10;ACTION=ASK:CREATE 2209 7.2 ENABLE Parameter 2211 Parameter Name: ENABLE 2213 Purpose: This parameter indicates whether or not the property should 2214 be ignored. Example if a "TRIGGER" property in a "VALARM" component 2215 should be ignored. 2217 Value Type: BOOLEAN 2219 Conformance: This property can be specified in the "TRIGGER" 2220 properties. 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 "ENABLE" parameter to any "TRIGGER" property before 2228 booking the component. If the "ENABLE" parameter is set to "FALSE", 2229 then the alarm will be ignored by the CUA. If set to "TRUE", or if 2230 the "ENABLE" property is not in the "TRIGGER" property, the alarm is 2231 enabled. This parameter may not be known by pre-CAP implementations 2232 and should not be an issue as it conforms to an 'ianaparam' as 2233 defined in [iCAL]. 2235 Formal Definition: The property is defined by the following notation: 2237 enable-param = "ENABLE" "=" boolean 2238 ; 2239 boolean = ; As defined in [iCAL] 2241 Example: The following is an example of this property for a "VAGENDA" 2242 component: 2244 TRIGGER;ENABLE=FALSE;RELATED=END:PT5M 2246 7.3 ID Parameter 2248 Parameter Name: ID 2250 Purpose: When used in a "CMD" component provides a unique identifier. 2252 Value Type: TEXT 2254 Conformance: This parameter can be specified in the "CMD" property. 2256 Description: If there is more than one command sent then the "ID" 2257 parameter is used to uniquely identify the command. 2259 A CUA may add the "ID" parameter to any "CMD" property before sending 2260 the command. There must not be more than one outstanding command 2261 tagged with the same "ID" parameter value. 2263 Formal Definition: The property is defined by the following notation: 2265 id-param = ";" "ID" "=" unique-id 2266 ; The text value supplied is a unique value 2267 ; shared between the CUA and CS to uniquely 2268 ; identify the instance of command in the 2269 ; the current CUA session. The value has 2270 ; no meaning to other CUAs or other sessions. 2271 ; 2272 unique-id = ; text 2273 ; 2274 text = ; As defined in [iCAL]. 2276 Example: The following is an example of this parameter component: 2278 CMD;UD=some-unique-value:CREATE 2280 7.4 LATENCY Parameter 2282 Parameter Name: LATENCY 2284 Purpose: This parameter indicates time in seconds for when a timeout 2285 occurs. 2287 Value Type: TEXT 2289 Conformance: This property can be specified in the "CMD" property. 2291 When present in a "CMD" property the "LATENCY" parameter specifies 2292 the time in sections when the command timeout expires. 2294 Formal Definition: The parameter is defined by the following 2295 notation: 2297 latency-param = ";" "LATENCY" "=" latency-sec 2298 ; The value supplied in the time in seconds. 2299 ; If 'latency-param' is supplied then 2300 ; 'action-param' MUST BE supplied. 2301 ; 2302 latency-sec = posint1 2304 ; Default is zero (0) meaning no timeout. 2306 Example: The following is an example of this parameter: 2308 CMD;LATENCY=10;ACTION=ASK:CREATE 2310 7.5 LOCAL Parameter 2312 Parameter Name: LOCAL 2314 Purpose: Indicates if the named component should be exported to any 2315 non-organizer calendar. 2317 Value Type: BOOLEAN 2319 Conformance: This parameter can be specified in the "SEQUENCE" 2320 properties in a "VALARM" component. 2322 Description: When a non owner sends an [iTIP] "REQUEST" to a calendar 2323 that object might contain a "VALARM" component. The owner may wish 2324 to have local control over their own CUA and when or how alarms are 2325 triggered. 2327 A CUA may add the "LOCAL" parameter to the "SEQUENCE" property before 2328 booking the component. If the "LOCAL" parameter is set to "TRUE", 2329 then the alarm MUST NOT be forwarded to any other calender. If set 2330 to "FALSE", or if the "LOCAL" parameter is not in the "SEQUENCE" 2331 property, the alarm is global. 2333 Formal Definition: The property is defined by the following notation: 2335 local-param = "LOCAL" "=" boolean 2337 Example: The following is an example of this parameter: 2339 SEQUENCE;LOCAL=TRUE:4 2341 7.6 LOCALIZE Parameter 2343 Parameter Name: LOCALIZE 2345 Purpose: If provided the "LOCALIZE" parameter specifies the desired 2346 language for error and warning messages. 2348 Value Type: TEXT 2350 Conformance: This parameter can be specified in the "CMD" properties. 2352 When the "LOCALIZE" parameter is supplied then its value MUST BE one 2353 of the values listed in the initial [BEEP] greeting 'localize' 2354 attribute. 2356 A CUA may add the "LOCALIZE" parameter to the "CMD" property to 2357 specify the language of any error or warning messages. 2359 Formal Definition: The property is defined by the following notation: 2361 localize-param = ";" "LOCALIZE" "=" beep-localize 2362 ; 2363 beep-localize = text ; As defined in [BEEP] 2364 ; The value supplied MUST BE one value from the initial 2365 ; [BEEP] greeting 'localize' attribute specifying 2366 ; the locale to use for error messages during 2367 ; this instance of the command sent. 2369 Example: The following is an example of this parameter: 2371 CMD;LOCALIZE=fr_CA:CREATE 2373 7.7 OPTIONS Parameter 2375 Parameter Name: OPTIONS 2377 Purpose: If provided the "OPTIONS" parameter specifies some "CMD" 2378 property specific options. 2380 Value Type: TEXT 2382 Conformance: This parameter can be specified in the "CMD" properties. 2384 A CUA adds the "OPTIONS" parameter to the "CMD" property when the 2385 command needs extra values. 2387 Formal Definition: The property is defined by the following notation: 2389 option-param = ";" "OPTIONS" "=" cmd-specific 2390 ; 2391 cmd-specific = ; The value supplied is dependent on the 2392 ; CMD value. See the specific CMDs for the 2393 ; correct values to use for each CMD. 2395 Example: The following is an example of this parameter: 2397 CMD;OPTIONS=10:GENERATE-UID 2399 8. New Properties 2401 8.1 ALLOW-CONFLICT Property 2403 Property Name: ALLOW-CONFLICT 2405 Purpose: This property indicates whether or not the calendar and CS 2406 supports component conflicts. That is, whether or not any of the 2407 components in the calendar can overlap. 2409 Value Type: BOOLEAN 2411 Property Parameters: Non-standard property parameters can be 2412 specified on this property. 2414 Conformance: This property can be specified in "VAGENDA" and 2415 "VCALSTORE" component. 2417 Description: This property is used to indicate whether components may 2418 conflict. That is, if their expanded instances may share the same 2419 time or overlap the same time periods. If it has a value of "TRUE", 2420 then conflicts are allowed. If "FALSE", the no two components may 2421 conflict. 2423 If "FALSE" in the "VCALSTORE" component, then all "VAGENDA" component 2424 "ALLOW-CONFLICT" property values MUST BE "FALSE" in the CS. 2426 Formal Definition: The property is defined by the following notation: 2428 allow-conflict = "ALLOW-CONFLICT" other-params ":" boolean CRLF 2430 Example: The following is an example of this property for a "VAGENDA" 2431 component: 2433 ALLOW-CONFLICT:FALSE 2435 8.2 ATT-COUNTER Property 2437 Property Name: ATT-COUNTER 2439 Property Parameters: Non-standard property parameters can be 2440 specified on this property. 2442 Conformance: This property MUST be specified in an iCalendar object 2443 that specifies counter proposal to a group scheduled calendar entity. 2444 When storing a "METHOD" property with the "COUNTER" method, there 2445 needs to be a way to remember who sent the COUNTER. The ATT-COUNTER 2446 property MUST BE added to all "COUNTER" [iTIP] components by the CUA 2447 before storing in a CS. 2449 Description: This property is used to identify the CAL-ADDRESS of the 2450 entity that sent the "COUNTER" [iTIP] object. 2452 Formal Definition: The property is defined by the following notation: 2454 attcounter = "ATT-COUNTER" other-params ":" cal-address CRLF 2456 Examples: 2458 ATT-COUNTER:cap:example.com/Doug 2459 ATT-COUNTER:mailto:Doug@Example.com 2461 8.3 CALID Property 2463 Property Name: CALID 2465 Property Parameters: Non-standard property parameters can be 2466 specified on this property. 2468 Conformance: This property can be specified in the "VAGENDA" 2469 component. 2471 Description: This property is used to specify a fully qualified 2472 CALID. 2474 Formal Definition: The property is defined by the following notation: 2476 calid = "CALID" other-params ":" relcalid CRLF 2478 Example: 2480 CALID:cap://cal.example.com/sdfifgty4321 2482 8.4 CALMASTER Property 2484 Property Name: CALMASTER 2486 Purpose: The property specifies an e-mail address of a person 2487 responsible for the calendar store. 2489 Value Type: URI 2491 Property Parameters: Non-standard property parameters can be 2492 specified on this property. 2494 Conformance: The property can be specified in a "VCALSTORE" 2495 component. 2497 Description: The parameter value SHOULD BE a MAILTO URI as defined in 2498 [URL]. It MUST BE a contact URI such as a MAILTO URI and not a home 2499 page or file URI that describes how to contact the calmasters. 2501 Formal Definition: The property is defined by the following notation: 2503 calmaster = "CALMASTER" other-params ":" uri CRLF 2504 ; 2505 uri = ; IANA registered uri as defined in [iCAL] 2507 Example: The following is an example of this property: 2509 CALMASTER:mailto:administrator@example.com 2511 8.5 CAP-VERSION Property 2513 Property Name: CAP-VERSION 2515 Purpose: This property specifies the version of CAP supported. 2517 Value Type: TEXT 2519 Property Parameters: Non-standard property parameters can be 2520 specified on this property. 2522 Conformance: This property is specified in the "VREPLY" component 2523 that is sent in response to a "GET-CAPABILITY" command. 2525 Description: This specifies the version of CAP that the endpoint 2526 supports. The list is a comma separated list of RFC numbers 2527 supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE 2528 REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT). 2530 Formal Definition: The property is defined by the following notation: 2532 cap-version = "CAP-VERSION" other-params ":" text CRLF 2534 Example: The following are examples of this property: 2536 CAP-VERSION:XXXX 2538 8.6 CARID Property 2540 Property Name: CARID 2542 Purpose: This property specifies the identifier for an access right 2543 component. 2545 Value Type: TEXT 2547 Property Parameters: Non-standard property parameters can be 2548 specified on this property. 2550 Conformance: This property MUST BE specified once in a "VCAR" 2551 component. 2553 Description: This property is used in the "VCAR" component to specify 2554 an identifier. A "CARID" property value is unique per container. 2556 Formal Definition: The property is defined by the following notation: 2558 carid = "CARID" other-params ":" text CRLF 2560 Example: The following are examples of this property: 2562 CARID:xyzzy-007 2563 CARID:User Rights 2565 8.7 CAR-LEVEL Property 2567 Property Name: CAR-LEVEL 2569 Purpose: The property specifies the level of VCAR supported. 2571 Value Type: TEXT 2573 Property Parameters: Non-standard property parameters can be 2574 specified on this property. 2576 Conformance: The property can be specified in a "VREPLY" component 2577 that is sent in response to a "GET-CAPABILITY" command. 2579 Description: The value is one from a list of "CAR-NONE", "CAR-MIN", 2580 or "CAR-FULL-1". If "CAR-FULL-1" is supplied then "CAR-MIN" is also 2581 available. A "CAR-MIN" implementation only supported the "DEFAULT- 2582 VCARS" property values listed in the "VCALSTORE" component and a 2583 "CAR-MIN" implementation does not support the creation or 2584 modification of "VCAR" components from the CUA. 2586 Formal Definition: The property is defined by the following notation: 2588 car-level = "CAR-LEVEL" ":" other-params ":" car-level-values 2589 ; 2590 car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1" 2591 / other-levels ) 2592 ; 2593 other-levels = ; Any name published in an RFC for a "CAR-LEVEL" 2594 ; property value. 2596 Example: The following is an example of this property: 2598 CAR-LEVEL:CAR-FULL-1 2600 8.8 COMPONENTS Property 2602 Property Name: COMPONENTS 2604 Purpose: The property specifies a the list of components supported by 2605 the endpoint. 2607 Value Type: TEXT 2608 Property Parameters: Non-standard property parameters can be 2609 specified on this property. 2611 Conformance: The property can be specified in a "VREPLY" component in 2612 response to a "GET-CAPABILITY" command. 2614 Description: A comma separated list of components supported by the 2615 endpoint. If not in the list sent from the endpoint then they are 2616 not supported by that endpoint. Sending an unsupported component 2617 results in unpredictable results. This includes any components 2618 inside of other components (VALARM for example). The recommended 2619 list is "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, 2620 VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,VALARM 2621 DAYLIGHT,STANDARD,VCAR,VRIGHT,VQUERY" 2623 Formal Definition: The property is defined by the following notation: 2625 components = "COMPONENTS" other-params ":" comp-list CRLF 2626 ; 2627 ; All of these MUST BE supplied only once. 2628 ; 2629 comp-list-req = "VCALSTORE" "," "VCALENDAR" "," "VTIMEZONE" "," 2630 "VREPLY" "," "VAGENDA" "," "STANDARD" "," 2631 "DAYLIGHT" 2632 ; At least one MUST BE supplied. The same value 2633 ; MUST NOT occur more than once. 2634 ; 2635 comp-list-min = ( "," "VEVENT") / ( "," "VTODO") / ( "," "VJOURNAL" ) 2636 ; The same value MUST NOT occur 2637 ; more than once. If "VCAR" is supplied then 2638 ; "VRIGHT" must be supplied. 2639 ; 2640 comp-list-opt = ( "," "VFREEBUSY" ) / ( "," "VALARM" ) 2641 / ( "," "VCAR" ) / ( "," "VRIGHT" ) 2642 / ( "," "VQUERY") / ( "," x-comp ) 2643 / ( "," iana-comp ) 2644 ; 2645 comp-list = comp-list-req 1*3comp-list-min *(comp-list-opt) 2647 Example: The following is an example of this property: 2649 COMPONENTS:VCALSTORE,VCALENDAR,VREPLY,VAGENDA, 2650 VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO, 2651 DAYLIGHT,STANDARD,VFREEBUSY,VCAR,VRIGHT,VQUERY 2653 8.9 CSID Property 2655 Property Name: CSID 2657 Purpose: The property specifies a the globally unique identifier for 2658 the calendar store. 2660 Value Type: URI 2662 Property Parameters: Non-standard property parameters can be 2663 specified on this property. 2665 Conformance: The property can be specified in a "VCALSTORE" 2666 component. 2668 Description: The identifier MUST BE globally unique. Each CS needs 2669 its own unique identifier. The "CSID" property is the official 2670 unique identifier for the CS. If the [BEEP] 'serverName' attribute 2671 was supplied in the [BEEP] 'start' message, then the CSID will be 2672 mapped to the virtual host name supplied and the host name part of 2673 the CSID MUST BE the same as the 'serverName' value. This allows one 2674 CS implementation to service multiple virtual hosts. CS's are not 2675 required to support virtual hosting. If a CS does not support 2676 virtual hosting then it must ignore the [BEEP] 'serverName' 2677 attribute. 2679 Formal Definition: The property is defined by the following notation: 2681 csid = "CSID" other-params ":" capurl CRLF 2683 Example: The following is an example of this property: 2685 CSID:cap://calendar.example.com 2687 8.10 DECREED Property 2689 Property Name: DECREED 2691 Purpose: This property specifies if an access right calendar 2692 component is decreed or not. 2694 Value Type: BOOLEAN 2695 Property Parameters: Non-standard property parameters can be 2696 specified on this property. 2698 Conformance: This property MAY be specified once in a "VCAR" 2699 component. 2701 Description: This property is used in the "VCAR" component to specify 2702 whether the component is decreed or not. If the "DECREED" property 2703 value is "TRUE" then the CUA will be unable to change the contents of 2704 the "VCAR" component and any attempt will fail with an error. 2706 Formal Definition: The property is defined by the following notation: 2708 decreed = "DECREED" other-params ":" boolean CRLF 2710 Example: The following is an example of this property: 2712 DECREED:TRUE 2714 8.11 DEFAULT-CHARSET Property 2716 Property Name: DEFAULT-CHARSET 2718 Purpose: This property indicates the default charset. 2720 Value Type: TEXT 2722 Property Parameters: Non-standard property parameters can be 2723 specified on this property. 2725 Conformance: This property can be specified in "VAGENDA" and 2726 "VCALSTORE" calendar component. 2728 Description: In a "VAGENDA" component this property is used to 2729 indicate the charset of calendar. If not specified, the default is 2730 the first value in the "VCALSTORE" components "DEFAULT-CHARSET" 2731 property value list. The value MUST BE an IANA registered character 2732 set as defined in [CHARREG]. 2734 In a "VCALSTORE" component it is a comma separated list of charsets 2735 supported by the CS. The first entry is the default entry for all 2736 newly created "VAGENDA" components. The "UTF-8" value MUST BE in the 2737 "VCALSTORE" component "DEFAULT-CHARSET" property list. All compliant 2738 CAP implementations (CS and CUA) MUST support at least the "UTF-8" 2739 charset. 2741 If a charset name contains a comma (,), then that comma must be 2742 backslashed escaped in the value. 2744 Formal Definition: The property is defined by the following notation: 2746 default-charset = "DEFAULT-CHARSET" other-params ":" text 2747 *( "," text) CRLF 2749 Example: The following is an example of this property for a "VAGENDA" 2750 component: 2752 DEFAULT-CHARSET:Shift_JIS,UTF-8 2754 8.12 DEFAULT-LOCALE Property 2756 Property Name: DEFAULT-LOCALE 2758 Purpose: This property specifies the default language for text 2759 values. 2761 Value Type: TEXT 2763 Property Parameters: Non-standard property parameters can be 2764 specified on this property. 2766 Conformance: This property can be specified in "VAGENDA" and 2767 "VCALSTORE" components. 2769 Description: In a "VAGENDA" component, the "DEFAULT-LOCALE" property 2770 is used to indicate the locale of the calendar. The full locale 2771 SHOULD be used. The default and minimum locale is POSIX (aka the 'C' 2772 locale). 2774 In a "VCALSTORE" component it is a comma separated list of locales 2775 supported by the CS. The first value in the list is the default for 2776 all newly created VAGENDAs. "POSIX" MUST BE in the list. 2778 Formal Definition: The property is defined by the following notation: 2780 default-locale = "DEFAULT-LOCALE" other-params ":" language 2781 *( "," language) CRLF 2782 ; 2783 language = ; Text identifying a locale, as defined in [CHARPOL] 2785 Example: The following is an example of this property: 2787 DEFAULT-LOCALE:en-US.iso-8859-1,POSIX 2789 8.13 DEFAULT-TZID Property 2791 Property Name: DEFAULT-TZID 2793 Purpose: This property specifies the text value that specifies the 2794 time zones. 2796 Value Type: TEXT 2798 Property Parameters: Non-standard property parameters can be 2799 specified on this property. 2801 Conformance: This property may be specified once in a "VAGENDA" and 2802 "VCALSTORE" components. 2804 Description: A multi valued property that lists the known time zones. 2805 The first is the default. Where "TZID" property values are the same 2806 as the "TZID" property as defined in [iCAL]. 2808 If in a "VCALSTORE" component it is a comma separated list of TZIDs 2809 known to the CS. The entry is used as the default TZID list for all 2810 newly created calendars. The list MUST contain at least "UTC". A 2811 "VCALSTORE" components MUST have one "VTIMEZONE" component contained 2812 in it for each value in the "DEFAULT-TZID" property value. 2814 If in a "VAGENDA" component it is a comma separated list of "TZID" 2815 property values naming the time zones known to the calendar. The 2816 first time zone in the list is the default and is used as the 2817 localtime for objects that contain a date or date-time value without 2818 a time zone. All "VAGENDA" components MUST have one "VTIMEZONE" 2819 component contained for each value in the "DEFAULT-TZID" property 2820 value. 2822 If a "TZID" property value contains a comma (,), the comma must be 2823 backslash escaped. 2825 Formal Definition: This property is defined by the following 2826 notation: 2828 default-tzid = "DEFAULT-TZID" other-params 2829 ":" [tzidprefix] text 2830 *("," [tzidprefix] text) CRLF 2831 ; 2832 txidprefix = ; As defined in [iCAL] 2834 Example: The following is an example of this property: 2836 DEFAULT-TZID:US/Mountain,UTC 2838 8.14 DEFAULT-VCARS Property 2840 Property Name: DEFAULT-VCARS 2842 Purpose: This property is used to specify the "CARID" property ids of 2843 the default "VCAR" components for newly created "VAGENDA" components. 2845 Value Type: TEXT 2847 Property Parameters: Non-standard property parameters can be 2848 specified on this property. 2850 Conformance: This property MUST BE specified in "VCALSTORE" calendar 2851 component and MUST at least specify the following values: 2852 "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and 2853 "DEFAULTOWNER". 2855 Description: This property is used in the "VCALSTORE" component to 2856 specify the "CARID" value of the "VCAR" components that MUST BE 2857 copied into now "VAGENDA" components at creation time by the CS. All 2858 "DEFAULT-VCAR" values must have "VCARS" components stored in the 2859 "VCALSTORE". 2861 Formal Definition: The property is defined by the following notation: 2863 defautl-vcars = "DEFAULT-VCARS" other-params ":" text 2864 *( "," text ) CRLF 2866 Example: The following is an example of this property: 2868 DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY, 2869 UPDATEPARTSTATUS,DEFAULTOWNER 2871 8.15 DENY Property 2873 Property Name: DENY 2875 Purpose: This property identifies the UPN(s) being denied access in 2876 the "VRIGHT" component. 2878 Value Type: UPN-FILTER 2880 Property Parameters: Non-standard property parameters can be 2881 specified on this property. 2883 Conformance: This property can be specified in "VRIGHT" components. 2885 Description: This property is used in the "VRIGHT" component to 2886 define the CU or UG being denied access. 2888 Formal Definition: The property is defined by the following notation: 2890 deny = "DENY" other-params ":" upn-filter CRLF 2892 Example: The following are examples of this property: 2894 DENY:* 2896 DENY:bob@example.com 2898 8.16 EXPAND property 2900 Property Name: EXPAND 2902 Purpose: This property is to notify the CS if it should or should not 2903 expand any component with recurrence rules into multiple instances in 2904 a query reply. 2906 Value Type: BOOLEAN 2908 Property Parameters: Non-standard property parameters can be 2909 specified on this property. 2911 Conformance: This property can be specified in "VQUERY" components. 2913 Description: If a CUA wishes to see all of the instances of a 2914 recurring component the CUA sets EXPAND=TRUE in the "VQUERY" 2915 component. If not specified, the default is "FALSE". Note that if 2916 the CS has its "RECUR-EXPAND" CS property value set to "FALSE" then 2917 the "EXPAND" property will be ignored and the result will be as if 2918 the "EXPAND" value was set to "FALSE". The results will be bounded 2919 by any date range or other limits in the query. 2921 Formal Definition: The property is defined by the following notation: 2923 expand = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF 2925 Example: The following are examples of this property: 2927 EXPAND:FALSE 2928 EXPAND:TRUE 2930 8.17 GRANT Property 2932 Property Name: GRANT 2934 Purpose: This property identifies the UPN(s) being granted access in 2935 the "VRIGHT" component. 2937 Value Type: UPN-FILTER 2939 Property Parameters: Non-standard property parameters can be 2940 specified on this property. 2942 Conformance: This property can be specified in "VRIGHT" calendar 2943 components. 2945 Description: This property is used in the "VRIGHT" component to 2946 specify the CU or UG being granted access. 2948 Formal Definition: The property is defined by the following notation: 2950 grant = "GRANT" other-params ":" upn-filter CRLF 2952 Example: The following are examples of this property: 2954 GRANT:* 2956 GRANT:bob@example.com 2958 8.18 ITIP-VERSION Property 2960 Property Name: ITIP-VERSION 2962 Purpose: This property specifies the version of ITIP supported. 2964 Value Type: TEXT 2966 Property Parameters: Non-standard property parameters can be 2967 specified on this property. 2969 Conformance: This property is specified in the "VREPLY" component 2970 that is sent in response to a "GET-CAPABILITY" command. 2972 Description: This specifies the version of ITIP that the endpoint 2973 supports. The list is a comma separated list of RFC numbers 2974 supported. The list MUST contain at least 2446 to mean [iTIP] 2976 Formal Definition: The property is defined by the following notation: 2978 itip-version = "ITIP-VERSION" other-params ":" text CRLF 2980 Example: The following are examples of this property: 2982 ITIP-VERSION:2446 2984 8.19 MAX-COMP-SIZE Property 2986 Property Name: MAX-COMP-SIZE 2988 Purpose: This property specifies the largest size of any object 2989 accepted. 2991 Value Type: TEXT 2993 Property Parameters: Non-standard property parameters can be 2994 specified on this property. 2996 Conformance: This property is specified in the "VREPLY" component 2997 that is sent in response to a "GET-CAPABILITY" command. 2999 Description: A positive integer value that specifies the size of the 3000 largest iCalendar object that can be accepted in octets. Objects 3001 larger than this will be rejected. A value of zero (0) means no 3002 limit. This is also the maximum value of any [BEEP] payload that 3003 will be accepted or sent. 3005 Formal Definition: The property is defined by the following notation: 3007 max-comp-size = "MAX-COMP-SIZE" other-params ":" posint0 CRLF 3009 Example: The following are examples of this property: 3011 MAX-COMP-SIZE:1024 3013 8.20 MAXDATE Property 3015 Property Name: MAXDATE 3017 Purpose: This property specifies the date/time in the future beyond 3018 which the CS or CUA cannot represent. 3020 Value Type: DATE-TIME 3022 Property Parameters: Non-standard property parameters can be 3023 specified on this property. 3025 Conformance: The property can be specified in the "VCALSTORE" 3026 component. 3028 Description: The date and time MUST BE a UTC value and end with 'Z'. 3030 Formal Definition: The property is defined by the following notation: 3032 maxdate = "MAXDATE" other-params ":" date-time CRLF 3034 Example: The following is an example of this property: 3036 MAXDATE:20990101T000000Z 3038 8.21 MINDATE Property 3040 Property Name: MINDATE 3042 Purpose: This property specifies the date/time in the past prior to 3043 which the server cannot represent. 3045 Value Type: DATE-TIME 3047 Property Parameters: Non-standard property parameters can be 3048 specified on this property. 3050 Conformance: The property can be specified in the "VCALSTORE" 3051 component. 3053 Description: The date and time MUST BE a UTC value and end with 'Z'. 3055 Formal Definition: The property is defined by the following notation: 3057 mindate = "MINDATE" other-params ":" date-time CRLF 3058 ; 3059 date-time = ; As defined in [iCAL] 3061 Example: The following is an example of this property: 3063 MINDATE:19710101T000000Z 3065 8.22 MULTIPART Property 3067 Property Name: MULTIPART 3069 Purpose: This property provides a comma separated list of supported 3070 MIME multipart types supported by the sender. 3072 Value Type: TEXT 3074 Property Parameters: Non-standard property parameters can be 3075 specified on this property. 3077 Conformance: This property is specified in the "VREPLY" component 3078 that is sent in response to a "GET-CAPABILITY" command. 3080 Description: This property is used in the in the "GET-CAPABILITY" 3081 command reply to indicated the MIME multipart types supported. A CS 3082 and CUA SHOULD support all registered MIME multipart types. 3084 Formal Definition: The property is defined by the following notation: 3086 multipart = "MULTIPART" other-params ":" text *( "," text) CRLF 3088 Example: The following is an example of this property: 3090 MULTIPART:related,alternate,mixed 3092 8.23 NAME Property 3094 Property Name: NAME 3096 Purpose: This property provides a localizable display name for a 3097 component. 3099 Value Type: TEXT 3101 Property Parameters: Non-standard property parameters can be 3102 specified on this property. 3104 Conformance: This property can be specified in a component. 3106 Description: This property is used in the in component to specify a 3107 localizable display name. If more than one "NAME" properties are in 3108 a component, then they MUST have unique "LANG" parameters. If the 3109 "LANG" parameter is not supplied, then it defaults to the "VAGENDA" 3110 components "DEFAULT-LOCALE" first value as the default. If the 3111 component is a "VAGENDA" then the default value is the "VAGENDA"s 3112 components "DEFAULT-LOCALE" first value as the default. A 3113 "VCALSTORE" components "DEFAULT-LOCALE" first value is the default if 3114 the component is stored at the "VCALSTORE" level. 3116 Formal Definition: The property is defined by the following notation: 3118 name = "NAME" nameparam ":" text CRLF 3119 ; 3120 nameparam = other-params [ ";" languageparam ] other-params 3121 ; 3122 languageparam = ; As defined in [iCAL]. 3124 Example: The following is an example of this property: 3126 NAME:Restrict Guests From Creating VALARMs On VEVENTs 3128 8.24 OWNER Property 3130 Property Name: OWNER 3132 Purpose: The property specifies an owner of the component. 3134 Value Type: UPN 3136 Property Parameters: Non-standard, alternate text representation and 3137 language property parameters can be specified on this property. 3139 Conformance: The property MUST BE specified at in a "VAGENDA" 3140 component. 3142 Description: A multi-instanced property indicating the calendar 3143 owner. 3145 Formal Definition: The property is defined by the following notation: 3147 owner = "OWNER" other-params ":" upn CRLF 3149 Example: The following is an example of this property: 3151 OWNER:jsmith@example.com 3152 OWNER:jdough@example.com 3154 8.25 PERMISSION Property 3156 Property Name: PERMISSION 3158 Purpose: This property defines a permission that is granted or denied 3159 in a "VRIGHT" component. 3161 Value Type: TEXT 3163 Property Parameters: Non-standard property parameters can be 3164 specified on this property. 3166 Conformance: This property can be specified in "VRIGHT" components. 3168 Description: This property is used in the "VRIGHT" component to 3169 define a permission that is granted or denied. 3171 Formal Definition: The property is defined by the following notation: 3173 permmission = "PERMISSION" other-params ":" permvalue CRLF 3174 ; 3175 permvalue = ( "SEARCH" / "CREATE" / "DELETE" 3176 / "MODIFY" / "MOVE" / all 3177 / iana-cmd / x-cmd ) 3178 ; 3179 all = "*" 3180 ; 3181 iana-cmd = ; Any command registered by IANA directly or 3182 ; included in an RFC that may be applied as 3183 ; a command. 3184 ; 3185 x-cmd = ; Any experimental command that starts with 3186 ; "x-" or "X-". 3188 Example: The following is an example of this property: 3190 PERMISSION:SEARCH 3192 8.26 QUERY property 3194 Property Name: QUERY 3196 Purpose: Specifies the query for the component. 3198 Value Type: CAL-QUERY 3200 Property Parameters: Non-standard property parameters can be 3201 specified on this property. 3203 Conformance: This property can be specified in "VQUERY" components. 3205 Description: A "QUERY" is used to specify the "CAL-QUERY" 3206 (Section 6.1.1 for the query. 3208 Formal Definition: The property is defined by the following notation: 3210 query = "QUERY" other-params ":" cal-query CRLF 3212 Example: The following is an example of this property: 3214 QUERY:SELECT * FROM VEVENT 3216 8.27 QUERYID property 3218 Property Name: QUERYID 3220 Purpose: Specifies a unique ID for a query in the targeted container. 3222 Value Type: TEXT 3224 Property Parameters: Non-standard property parameters are specified 3225 on this property. 3227 Conformance: This property can be specified in "VQUERY" components. 3229 Description: A "QUERYID" property is used to specify the unique id 3230 for a query. A "QUERYID" property value is unique per container. 3232 Formal Definition: The property is defined by the following notation: 3234 queryid = "QUERYID" other-params ":" text CRLF 3236 Example: The following are examples of this property: 3238 QUERYID:Any Text String 3239 QUERYID:fetchUnProcessed 3241 8.28 QUERY-LEVEL Property 3243 Property Name: QUERY-LEVEL 3245 Purpose: This property specifies the level of query supported. 3247 Value Type: TEXT 3249 Property Parameters: Non-standard property parameters can be 3250 specified on this property. 3252 Conformance: The property can be specified in the "VREPLY" component 3253 in response to a "GET-CAPABILITY" command. 3255 Description: Indicates level of query support. CAL-QL-NONE is for 3256 CS's that allow ITIP methods only to be deposited and nothing else. 3258 Formal Definition: The property is defined by the following notation: 3260 query-level = "QUERY-LEVEL" other-params 3261 ":" ( "CAL-QL-1" / "CAL-QL-NONE") CRLF 3263 Example: The following is an example of this property: 3265 QUERY-LEVEL:CAL-QL-1 3267 8.29 RECUR-ACCEPTED Property 3269 Property Name: RECUR-ACCEPTED 3271 Purpose: This property specifies if the endpoint supports recurring 3272 instances. 3274 Value Type: BOOLEAN 3276 Property Parameters: Non-standard property parameters can be 3277 specified on this property. 3279 Conformance: The property can be specified in the "VREPLY" component 3280 in response to a "GET-CAPABILITY" command. 3282 Description: Indicates if recurrence rules are supported. If "FALSE" 3283 then the endpoint can not process any kind of recurring rules. 3285 Formal Definition: The property is defined by the following notation: 3287 recur-accepted = "RECUR-ACCEPTED" other-params ":" boolean CRLF 3289 Example: The following is an example of this property: 3291 RECUR-ACCEPTED:TRUE 3292 RECUR-ACCEPTED:FALSE 3294 8.30 RECUR-LIMIT Property 3296 Property Name: RECUR-LIMIT 3298 Purpose: This property specifies the maximum number of instances the 3299 endpoint will expand instances into at query or storage time. 3301 Value Type: INTEGER 3303 Property Parameters: Non-standard property parameters can be 3304 specified on this property. 3306 Conformance: The property can be specified in the "VREPLY" component 3307 in response to a "GET-CAPABILITY" command. 3309 Description: For implementations that have the "STORES-EXPANDED" 3310 value set to "TRUE", then this value specifies the maximum number of 3311 instances that will be stored and fetched. For all implementations 3312 this is the maximum number of instances that will be returned when 3313 the "EXPAND" parameter is specified as "TRUE" and the results contain 3314 a infinite or large number of recurring instances. 3316 Formal Definition: The property is defined by the following notation: 3318 recur-limit = "RECUR-LIMIT" other-params ":" posint1 CRLF 3319 Example: The following is an example of this property: 3321 RECUR-LIMIT:1000 3323 8.31 RECUR-EXPAND Property 3325 Property Name: RECUR-EXPAND 3327 Purpose: This property specifies if the endpoint can expand 3328 recurrences into multiple objects. 3330 Value Type: BOOLEAN 3332 Property Parameters: Non-standard property parameters can be 3333 specified on this property. 3335 Conformance: The property can be specified in the "VREPLY" component 3336 in response to a "GET-CAPABILITY" command. 3338 Description: If "TRUE" then the endpoint can expand an object into 3339 multiple instances as defined by its recurrence rules when the 3340 "EXPAND" property is supplied. If "FALSE" then the endpoint ignores 3341 the "EXPAND" property. 3343 Formal Definition: The property is defined by the following notation: 3345 recur-expand = "RECUR-EXPAND" other-params ":" boolean CRLF 3347 Example: The following is an example of this property: 3349 RECUR-EXPAND:TRUE 3350 RECUR-EXPAND:FALSE 3352 8.32 RESTRICTION Property 3354 Property Name: RESTRICTION 3356 Purpose: This property defines restrictions on the result value of 3357 new or existing components. 3359 Value Type: CAL-QUERY 3361 Property Parameters: Non-standard property parameters can be 3362 specified on this property. 3364 Conformance: This property can be specified in "VRIGHT" components, 3365 but only when the "PERMISSION" property is set to "CREATE", "MODIFY", 3366 or "*" property value. 3368 Description: This property is used in the "VRIGHT" component to 3369 define restrictions on the components that can be written (i.e., by 3370 using the "CREATE" or "MOVE" commands) as well as on the values that 3371 may take existent calendar store properties, calendar properties, 3372 components, and properties (i.e., by using the "MODIFY" command). 3373 Accepted values MUST match any specified "RESTRICTION" property 3374 values. 3376 Formal Definition: The property is defined by the following notation: 3378 restriction = "RESTRICTION" other-params ":" cal-query CRLF 3380 Example: The following are examples of this property: 3382 RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' 3384 RESTRICTION:SELECT * FROM VEVENT WHERE 3385 SELF() IN ORGANIZER 3387 RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN 3388 CATEGORIES 3390 8.33 SCOPE Property 3392 Property Name: SCOPE 3394 Purpose: This property identifies the objects in the CS to which the 3395 access rights applies. 3397 Value Type: CAL-QUERY 3399 Property Parameters: Non-standard property parameters can be 3400 specified on this property. 3402 Conformance: This property can be specified in "VRIGHT" components. 3404 Description: This property is used in the "VRIGHT" component to 3405 define the set of objects subject to the access right being defined. 3407 Formal Definition: The property is defined by the following notation: 3409 scope = "SCOPE" other-params ":" cal-query CRLF 3411 Example: The following is an example of this property: 3413 SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' 3415 8.34 STORES-EXPANDED Property 3417 Property Name: STORES-EXPANDED 3419 Purpose: This property specifies if the sending endpoint expands 3420 recurrence rules prior to storing them into the CS. 3422 Value Type: BOOLEAN 3424 Property Parameters: Non-standard property parameters can be 3425 specified on this property. 3427 Conformance: This property can be specified in a "VREPLY" component 3428 in response to a "GET-CAPABILITY" command. 3430 Description: If the value is "TRUE" then the endpoint expands 3431 recurrence rules and then stores the results into the CS. If this is 3432 "TRUE" then the "RECUR-LIMIT" property is significant because an 3433 infinitely recurring appointment will be stored no more than "RECUR- 3434 LIMIT" property values into the CS and all other instances will be 3435 lost. 3437 Formal Definition: The property is specified by the following 3438 notation: 3440 stores-expanded = "STORES-EXPANDED" other-params ":" boolean CRLF 3441 The following is an example of this property: 3443 STORES-EXPANDED:TRUE 3444 STORES-EXPANDED:FALSE 3446 8.35 TARGET Property 3448 Property Name: TARGET 3450 Purpose: This property defines the container that the command that is 3451 issued will act upon. Its value is a capurl as defined in Section 5. 3453 Value Type: URI 3455 Property Parameters: Non-standard property parameters can be 3456 specified on this property. 3458 Conformance: This property can be specified in a command component. 3460 Description: This property value is used to specify the container 3461 that the command will effect. When used in a command, the command 3462 will be performed on the container which has a capurl matching the 3463 value. 3465 Formal Definition: The property is specified by the following 3466 notation: 3468 target = "TARGET" other-params ":" ( capurl / relcalid ) CRLF 3470 The following is an example of this property: 3472 TARGET:cap://mycal.example.com 3473 TARGET:SomeRelCalid 3475 8.36 TRANSP Property 3477 Property Name: TRANSP 3478 Purpose: This property defines whether an component is transparent or 3479 not to busy time searches. This is a modification to [iCAL] "TRANSP" 3480 property in that it adds some values. 3482 Value Type: TEXT 3484 Property Parameters: Non-standard property parameters can be 3485 specified on this property. 3487 Conformance: This property can be specified in a component. 3489 Description: Time Transparency is the characteristic of an object 3490 that determines whether it appears to consume time on a calendar. 3491 Objects that consume actual time for the individual or resource 3492 associated with the calendar SHOULD be recorded as "OPAQUE", allowing 3493 them to be detected by free-busy time searches. Other objects, which 3494 do not take up the individual's (or resource's) time SHOULD be 3495 recorded as "TRANSPARENT", making them invisible to free-busy time 3496 searches. 3498 Formal Definition: The property is specified by the following 3499 notation: 3501 transp = "TRANSP" other-params ":" transvalue CRLF 3502 ; 3503 transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. 3504 / "TRANSPARENT" ;Transparent on busy time searches. 3505 / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time 3506 ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects 3507 ; can overlap it. 3508 ; 3509 / "OPAQUE-NOCONFLICT" ; Opaque on busy time 3510 ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects 3511 ; can overlap it. 3512 ; 3513 ; Default value is OPAQUE 3515 The following is an example of this property for an object that is 3516 opaque or blocks on free/busy time searches plus no other object can 3517 overlap it: 3519 TRANSP:OPAQUE-NOCONFLICT 3521 9. New Components 3523 9.1 VAGENDA Component 3525 Component Name: VAGENDA 3527 Purpose: Provide a grouping of properties that defines an agenda. 3529 Formal Definition: There are two formats of the "VAGENDA" component. 3530 (1) When it is being created, and (2) how it exists in the 3531 "VCALSTORE" component. 3533 A "VAGENDA" component in a "VCALSTORE" component is defined by the 3534 following notes and ABNF notation: 3536 CALSCALE - The value MUST BE from the "VCALSTORE" "CALSCALE" 3537 property list. The default is the first entry in the VCALSTORE 3538 CALSCALE list. 3540 CREATED - The timestamp of the calendar's create date. This is a 3541 READ ONLY property in a "VAGENDA". 3543 LAST-MODIFIED - The timestamp of any change to the "VAGENDA" 3544 properties or when any component was last created, modified, or 3545 deleted. 3547 agenda = "BEGIN" ":" "VAGENDA" CRLF 3548 agendaprop 3549 *(icalobject) ; as defined in [iCAL] 3550 "END" ":" "VAGENDA" CRLF 3551 ; 3552 agendaprop = *( 3553 ; The following MUST occur exactly once. 3554 ; 3555 allow-conflict / relcalid / calscale / created 3556 / default-charset / default-locale 3557 / default-tzid / last-mod 3558 ; 3559 ; The following MUST occur at least once. 3560 ; and the value MUST NOT be empty. 3561 ; 3562 / owner 3563 ; 3564 ; The following are optional, 3565 ; and MAY occur more than once. 3566 ; 3567 / name / related-to / other-props / x-comp 3568 ) 3570 icalobject = ; As defined in [iCAL] 3571 ; 3572 created = ; As defined in [iCAL] 3573 ; 3574 related-to = ; As defined in [iCAL] 3576 When creating a VAGENDA, use the following notation: 3578 agendac = "BEGIN" ":" "VAGENDA" CRLF 3579 agendacprop 3580 *(icalobject) ; as defined in [iCAL] 3581 "END" ":" "VAGENDA" CRLF 3582 ; 3583 agendacprop = *( 3584 ; The following MUST occur exactly once. 3585 ; 3586 allow-conflict / relcalid / calscale 3587 / default-charset / default-locale 3588 / default-tzid 3589 ; 3590 ; The following MUST occur at least once. 3591 ; and the value MUST NOT be empty. 3592 ; 3593 / owner 3594 ; 3595 ; The following are optional, 3596 ; and MAY occur more than once. 3597 ; 3598 / name / related-to / other-props / x-comp 3599 ) 3601 To fetch all of the properties from the targeted "VAGENDA" component. 3602 This does not fetch any components: 3604 SELECT * FROM VAGENDA 3606 To fetch all of the properties from the targeted VAGENDA and all of 3607 the contained components, use the special '*.*' value: 3609 SELECT *.* FROM VAGENDA 3611 9.2 VCALSTORE Component 3613 Component Name: VCALSTORE 3615 Purpose: Provide a grouping of properties that defines a calendar 3616 store. 3618 Formal Definition: A "VCALSTORE" component is defined by the 3619 following table and ABNF notation. The creation of a "VCALSTORE" 3620 component is an administrative task and not part of the CAP protocol. 3622 The following are notes to some of the properties in the "VCALSTORE" 3623 component. 3625 CALSCALE - A comma separated list of CALSCALEs supported by this CS. 3626 All "VAGENDA" component calendar CALSCALE properties MUST BE from 3627 this list. This list MUST contain at least "GREGORIAN". The 3628 default for newly created "VAGENDA" components is the first entry. 3630 RELATED-TO - This is a multiple instance property. There must be a 3631 "RELATED-TO" property MUST for each of the "VAGENDA" components 3632 contained in the "VCALSTORE" component each with the "RELTYPE" 3633 parameter value set to "CHILD". Other "RELATED-TO" properties may 3634 be included. 3636 CREATED - The timestamp of the CS creation time. This is a READ 3637 ONLY property. 3639 CSID - The CSID of this calendar store. MUST NOT be empty. How 3640 this property is set in the VCALSTORE is an administrative or 3641 implementation specific issue and is not covered in CAP. This is 3642 a READ ONLY property. A suggested value is the fully qualified 3643 host name or a fully qualified virtual host name supported by the 3644 system. 3646 LAST-MODIFIED - The timestamp when the Properties of the "VCALSTORE" 3647 component were last updated or calendars were created or deleted. 3648 This is a READ ONLY PROPERTY. 3650 calstorec = "BEGIN" ":" "VCALSTORE" CRLF 3651 calstoreprop 3652 *(vagendac) 3653 "END" ":" "VCALSTORE" CRLF 3654 ; 3655 calstoreprop = *( 3656 ; the following MUST occur exactly once 3657 ; 3658 allow-conflict / calscale / calmaster 3659 / created / csid / default-charset 3660 / default-locale / default-vcars 3661 / default-tzid / last-mod / maxdate / mindate 3662 ; 3663 ; the following are optional, 3664 ; and MAY occur more than once 3665 ; 3666 / name / related-to / other-props / x-comp 3667 ) 3668 ; 3669 vagendac = ; As defined in [iCAL]. 3670 ; 3671 last-mod = ; As defined in [iCAL]. 3673 To fetch all of the properties from the targeted VCALSTORE and not 3674 fetch the calendars that it contains: 3676 SELECT * FROM VCALSTORE 3678 To fetch all of the properties from the targeted "VCALSTORE" 3679 component and all of the contained calendars and all of those 3680 calendars contained properties and components, use the special '*.*' 3681 value: 3683 SELECT *.* FROM VCALSTORE 3685 9.3 VCAR Component 3687 Component Name: VCAR 3689 Purpose: Provide a grouping of calendar access rights. 3691 Formal Definition: A "VCAR" component is defined by the following 3692 notation: 3694 carc = "BEGIN" ":" "VCAR" CRLF 3695 carprop 1*rightc 3696 "END" ":" "VCAR" CRLF 3697 ; 3698 carprop = 1*( 3699 ; 3700 ; 'carid' is REQUIRED, 3701 ; but MUST NOT occur more than once 3702 ; 3703 carid / 3704 ; 3705 ; the following are OPTIONAL, 3706 ; and MAY occur more than once 3707 ; 3708 name / decreed / other-props 3709 ) 3711 Description: A "VCAR" component is a grouping of properties, and 3712 "VRIGHT" components, that represents access rights granted or denied 3713 to UPNs. 3715 The "CARID" property specifies the local identifier for the "VCAR" 3716 component. The "NAME" property specifies a localizable display name. 3718 Example: In the following example, the UPN "foo@example.com" is given 3719 search access to the "DTSTART" and "DTEND" VEVENT properties. No 3720 other access is specified: 3722 BEGIN:VCAR 3723 CARID:View Start and End Times 3724 NAME:View Start and End Times 3725 BEGIN:VRIGHT 3726 GRANT:foo@example.com 3727 PERMISSION:SEARCH 3728 SCOPE:SELECT DTSTART,DTEND FROM VEVENT 3729 END:VRIGHT 3730 END:VCAR 3732 In this example, all UPNs are given search access to "DTSTART" and 3733 "DTEND" properties of VEVENT components. "All CUs and UGs" are 3734 specified by the UPN value "*". Note that this enumerated UPN value 3735 is not in quotes: 3737 BEGIN:VCAR 3738 CARID:ViewStartEnd2 3739 NAME:View Start and End Times 2 3740 BEGIN:VRIGHT 3741 GRANT:* 3742 PERMISSION:SEARCH 3743 SCOPE:SELECT DTSTART,DTEND FROM VEVENT 3744 END:VRIGHT 3745 END:VCAR 3747 In these examples, full calendar access rights are given to the CAL- 3748 OWNERS(), and a hypothetical administrator is given access rights to 3749 specify calendar access rights. If no other rights are specified, 3750 only these two UPNs can specify calendar access rights: 3752 BEGIN:VCAR 3753 CARID:some-id-3 3754 NAME:Only OWNER or ADMIN Settable VCARs 3755 BEGIN:VRIGHT 3756 GRANT:CAL-OWNERS() 3757 PERMISSION:* 3758 SCOPE:SELECT * FROM VAGENDA 3759 END:VRIGHT 3760 BEGIN:VRIGHT 3761 GRANT:cal-admin@example.com 3762 PERMISSION:* 3763 SCOPE:SELECT * FROM VCAR 3764 RESTRICTION:SELECT * FROM VCAR 3765 END:VRIGHT 3766 END:VCAR 3768 In this example, rights to write, search, modify or delete calendar 3769 access rights are denied to all UPNs. This example would disable 3770 providing different access rights to the calendar store or calendar. 3771 This calendar access right should be specified with great care, as it 3772 removes the ability to change calendar access; even for the owner or 3773 administrator. It could be used by small devices that do not support 3774 the changing of any VCAR: 3776 BEGIN:VCAR 3777 CARID:VeryRestrictiveVCAR-2 3778 NAME:No CAR At All 3779 BEGIN:VRIGHT 3780 DENY:* 3781 PERMISSION:* 3782 SCOPE:SELECT * FROM VCAR 3783 END:VRIGHT 3784 END:VCAR 3786 9.4 VRIGHT Component 3788 Component Name: "VRIGHT" 3790 Purpose: Provide a grouping of properties that describe an access 3791 right (granted or denied). 3793 Formal Definition: A "VRIGHT" component is defined by the following 3794 notation: 3796 rightc = "BEGIN" ":" "VRIGHT" CRLF 3797 rightprop 3798 "END" ":" "VRIGHT" CRLF 3799 ; 3800 rightprop = 2*( 3801 ; 3802 ; either 'grant' or 'deny' MUST 3803 ; occur at least once 3804 ; and MAY occur more than once 3805 ; 3806 grant / deny / 3807 ; 3808 ; 'permission' MUST occur at least once 3809 ; and MAY occur more than once 3810 ; 3811 permission / 3812 ; 3813 ; the following are optional, 3814 ; and MAY occur more than once 3815 ; 3816 scope / restriction / other-props 3817 ) 3819 Description: A "VRIGHT" component is a grouping of calendar access 3820 right properties. 3822 The "GRANT" property specifies the UPN that is being granted access. 3823 The "DENY" property specifies the UPN is being denied access. The 3824 "PERMISSION" property specifies the actual permission being set. The 3825 "SCOPE" property identifies the calendar store properties, calendar 3826 properties, components, or properties to which the access right 3827 applies. The "RESTRICTION" property specifies restriction on the 3828 value that may take calendar store properties, calendar properties, 3829 calendar components, and properties after a "CREATE" or "MODIFY" 3830 command. Values MUST match all the instances of the "RESTRICTION" 3831 property to be valid. 3833 9.5 VREPLY Component 3835 Component Name: "VREPLY" 3837 Purpose: Provide a grouping of arbitrary properties and components 3838 that are the data set result from an issued command. 3840 Formal Definition: A "VREPLY" component is defined by the following 3841 notation: 3843 replyc = "BEGIN" ":" "VREPLY" CRLF 3844 any-prop-or-comp 3845 "END" ":" "VREPLY" CRLF 3846 ; 3847 any-prop-or-comp = ; Zero or more iana or experimental 3848 ; properties and components, in any order. 3850 Description: Provide a grouping of arbitrary properties and 3851 components that are the data set result from an issued command. 3853 A query can return a predictable set of arbitrary properties and 3854 components. This component is used by query and other commands to 3855 return data that does not fit into any other component. It may 3856 contain any valid property or component, even if they are not 3857 registered. 3859 9.6 VQUERY Component 3861 Component Name: VQUERY 3863 Purpose: A component describes a set of objects to be acted upon. 3865 Formal Definition: A "VQUERY" component is defined by the following 3866 notation: 3868 queryc = "BEGIN" ":" "VQUERY" CRLF 3869 queryprop 3870 "END" ":" "VCAR" CRLF 3871 ; 3872 queryprop = 1*( 3873 ; 3874 ; 'queryid' is OPTIONAL but MUST NOT occur 3875 ; more than once. If the "TARGET" property 3876 ; is supplied then the "QUERYID" property 3877 ; MUST BE supplied. 3878 ; 3879 queryid / target 3880 ; 3881 ; 'expand' is OPTIONAL but MUST NOT occur 3882 ; more than once. 3883 ; 3884 expand 3885 ; 3886 ; the following are OPTIONAL, and MAY occur 3887 ; more than once 3888 ; 3889 / name / other-props 3890 ; 3891 ; the following MUST occur at least once if 3892 ; queryid is not supplied. 3893 ; 3894 / query 3895 ) 3897 Description: A "VQUERY" contains properties that describe which 3898 properties and components the CS is requested to act upon. 3900 The "QUERYID" property specifies the local identifier for a "VQUERY" 3901 component. 3903 For a search, if the "TARGET" property is supplied in a "VQUERY" 3904 component, then the CS is to search for the query in the CALID 3905 supplied by the "TARGET" property value. 3907 For a create the "TARGET" property MUST NOT be supplied as the 3908 destination container is already supplied in the "TARGET" property of 3909 the "VCALENDAR" component. 3911 For examples, see Section 6.1.1. 3913 10. Commands and Responses 3915 CAP commands and responses are described in this section. 3917 10.1 CAP Commands (CMD) 3919 All commands are send using the CMD property. 3921 Property Name: CMD 3923 Purpose: The property defines the command to be sent. 3925 Value Type: TEXT 3927 Property Parameters: Non-standard, id, localize, latency, action or 3928 options. 3930 Conformance: This property is the method used to specify the commands 3931 to a CS and can exist in any object sent to the CS. 3933 Description: All of the commands to the CS are supplied in this 3934 property. The "OPTIONS" parameter is overloaded and its meaning is 3935 dependent on the CMD value supplied. 3937 Formal Definition: The property is defined by the following notation: 3939 cmd = "CMD" ( 3940 abort-cmd 3941 / continue-cmd 3942 / create-cmd 3943 / delete-cmd 3944 / generate-uid-cmd 3945 / get-capability-cmd 3946 / identify-cmd 3947 / modify-cmd 3948 / move-cmd 3949 / reply-cmd 3950 / search-cmd 3951 / set-locale-cmd 3952 / iana-cmd 3953 / x-cmd 3954 ) CRLF 3955 ; 3956 option-value = "OPTION" "=" paramtext 3957 ; 3958 paramtext ; As defined in [iCAL] 3959 Calendaring commands allow a CUA to directly manipulate a calendar. 3961 Calendar access rights can be granted or denied for any commands. 3963 10.1.1 Bounded Latency 3965 A CAP command can have an associated maximum latency time by 3966 specifying the "LATENCY" parameter. If the command is unable to be 3967 completed in the specified amount of time (as specified by the 3968 "LATENCY" parameter value with an "ACTION" parameter set to the "ASK" 3969 value), then a "TIMEOUT" command MUST BE sent on the same channel" to 3970 which there MUST BE a an "ABORT" or a "CONTINUE" command reply. If 3971 the CUA initiated the original command, then the CS would issue the 3972 "TIMEOUT" command and the CUA would then have to issue an "ABORT" or 3973 "CONTINUE" command. If the CS initiated the original command then 3974 the CUA would have to issue the "TIMEOUT" and the CS would send the 3975 "ABORT" or "CONTINUE". 3977 Upon receiving an "ABORT" command, the command must then be 3978 terminated. Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE" 3979 commands can not be aborted. The "ABORT", "TIMEOUT", and "REPLY" 3980 commands MUST NOT have latency set. 3982 Upon receiving a "CONTINUE" command the work continues as if it had 3983 not been delayed or stopped. Note that a new latency time MAY BE 3984 included in a "CONTINUE" command indicating to continue the original 3985 command until the "LATENCY" parameter value expires or the results of 3986 the original command can be returned. 3988 Both the "LATENCY" parameter and the "ACTION" parameter MUST BE 3989 supplied to any "CMD" property, or nether can be added to the "CMD" 3990 property. The "LATENCY" parameter MUST BE set to the maximum latency 3991 time in seconds. The "ACTION" parameter accepts the following 3992 values: "ASK" and "ABORT" parameters. 3994 If the maximum latency time is exceeded and the "ACTION" parameter is 3995 set to the "ASK" value, then "TIMEOUT" command MUST BE sent. 3996 Otherwise if the "ACTION" parameter is set to the "ABORT" value then 3997 the command MUST BE terminated and return a REQUEST-STATUS code of 3998 2.0.3 for the original command. 4000 If a CS can both start sending the reply to a command and guarantee 4001 that all of the results can be sent from a command (short of 4002 something like network or power failure) prior to the "LATENCY" 4003 timeout value then the "LATENCY" time has not expired. 4005 Example: 4007 In this example the initiator asks for the listeners capabilities. 4009 I: Content-Type: text/calendar 4010 I: 4011 I: BEGIN:VCALENDAR 4012 I: VERSION:2.0 4013 I: PRODID:The CUA's PRODID 4014 I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY 4015 I: END:VCALENDAR 4017 # After 3 seconds 4019 L: Content-Type: text/calendar 4020 L: 4021 L: BEGIN:VCALENDAR 4022 L: PRODID:-//someone's prodid 4023 L: VERSION:2.0 4024 L: CMD;ID=xyz12346:TIMEOUT 4025 L: END:VCALENDAR 4027 In order to continue and give the CS more time then the CUA would 4028 issue a "CONTINUE" command: 4030 I: Content-Type: text/calendar 4031 I: 4032 I: BEGIN:VCALENDAR 4033 I: VERSION:2.0 4034 I: PRODID:-//someone's prodid 4035 I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE 4036 I: END:VCALENDAR 4038 L: Content-Type: text/calendar 4039 L: 4040 L: BEGIN:VCALENDAR 4041 L: VERSION:2.0 4042 L: PRODID:-//someone's prodid 4043 L: CMD;ID=xyz12346:REPLY 4044 L: BEGIN:VREPLY 4045 L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds 4046 L: END:VREPLY 4047 L: END:VCALENDAR 4049 Above the "2.0.3" status is returend because it is not an error, it 4050 is a progress status sent in reply to the "CONTINUE" command. 4052 To abort the command and not wait any further then issue an "ABORT" 4053 command: 4055 I: Content-Type: text/calendar 4056 I: 4057 I: BEGIN:VCALENDAR 4058 I: VERSION:2.0 4059 I: PRODID:-//someone's prodid 4060 I: CMD;ID=xyz12346:ABORT 4061 I: END:VCALENDAR 4063 # Which would result in a 2.0.3 reply. 4065 L: Content-Type: text/calendar 4066 L: 4067 L: BEGIN:VCALENDAR 4068 L: VERSION:2.0 4069 L: PRODID:-//someone's prodid 4070 L: CMD;ID=xyz12346:REPLY 4071 L: BEGIN:VREPLY 4072 L: REQUEST-STATUS:2.0.3;Aborted As Requested. 4073 L: END:VREPLY 4074 L: END:VCALENDAR 4076 If the "ACTION" value had been set to "ABORT", then the listiner 4077 would send a "7.0" error on timeout in the reply to the command that 4078 initiated the command that timed out. 4080 10.2 ABORT Command 4082 CMD: ABORT 4084 Purpose: The "ABORT" command is sent to request that the named or 4085 only in process command be aborted. Latency MUST not be supplied 4086 with the "ABORT" command. 4088 Formal Definition: An "ABORT" command is defined by the following 4089 notation: 4091 abort-cmd = abortparam ":" "ABORT" 4092 ; 4093 abortparam = *( 4094 ; 4095 ; the following are optional, 4096 ; but MUST NOT occur more than once 4097 ; 4098 id-param 4099 / localize-param 4100 ; 4101 ; the following is optional, 4102 ; and MAY occur more than once 4103 ; 4104 / other-params 4105 ) 4107 The REPLY of any "ABORT" command is: 4109 abort-reply = "BEGIN" ":" "VCALENDAR" CRLF 4110 calprops 4111 abort-vreply 4112 "END" ":" "VCALENDAR" CRLF 4113 ; 4114 abort-vreply = "BEGIN" ":" "VREPLY" CRLF 4115 rstatus 4116 other-props 4117 "END" ":" "VREPLY" CRLF 4119 10.3 CONTINUE Command 4121 CMD: CONTINUE 4123 Purpose: The "CONTINUE" command is only sent after a "TIMEOUT" 4124 command has been received to inform the other end of the session to 4125 resume working on a command. 4127 Formal Definition: A "CONTINUE" command is defined by the following 4128 notation: 4130 continue-cmd = continueparam ":" "CONTINUE" 4131 ; 4132 continueparam = *( 4133 ; 4134 ; the following are optional, 4135 ; but MUST NOT occur more than once 4136 ; 4137 id-param 4138 / localize-param 4139 / latency-param 4140 ; 4141 ; the following MUST occur exactly once and only 4142 ; when the latency-param has been supplied and 4143 ; MUST NOT be supplied if the latency-param is 4144 ; not supplied. 4145 ; 4146 / action-param 4147 ; 4148 ; the following are optional, 4149 ; and MAY occur more than once 4150 ; 4151 / other-params 4152 ) 4154 The REPLY of any "CONTINUE" command is: 4156 continue-reply = "BEGIN" ":" "VCALENDAR" CRLF 4157 calprops 4158 continue-vreply 4159 "END" ":" "VCALENDAR" CRLF 4160 ; 4161 continue-vreply = "BEGIN" ":" "VREPLY" CRLF 4162 rstatus 4163 other-props 4164 "END" ":" "VREPLY" CRLF 4166 10.4 CREATE Command 4168 CMD: CREATE 4170 Purpose: The "CREATE" command is used to create one or more 4171 iCalendar objects in the store in the "BOOKED" or "UNPROCESSED" 4172 state. 4174 A CUA MAY send a "CREATE" command to a CS. The "CREATE" command MUST 4175 BE implemented by all CSs. 4177 The CS MUST NOT send a "CREATE" command to any CUA. 4179 Formal Definition: A "CREATE" command is defined by the following 4180 notation and the hierarchy restrictions as defined in Section 3.2: 4182 create-cmd = createparam ":" "CREATE" 4183 ; 4184 createparam = *( 4185 ; 4186 ; the following are optional, 4187 ; but MUST NOT occur more than once 4188 ; 4189 id-param 4190 / localize-param 4191 / latency-param 4192 ; 4193 ; the following MUST occur exactly once and only 4194 ; when the latency-param has been supplied and 4195 ; MUST NOT be supplied if the latency-param is 4196 ; not supplied. 4197 ; 4198 / action-param 4199 ; 4200 ; the following is optional, 4201 ; and MAY occur more than once 4202 ; 4203 / other-params 4204 ) 4206 Response: 4208 One iCalendar object per TARGET property MUST BE returned. 4210 The REPLY of any "CREATE" command is: 4212 Restriction Table for the iCalendar section of a reply that contains 4213 an iCalendar object is any valid [iTIP] response plus any from this 4214 ABNF: 4216 create-reply = "BEGIN" ":" "VCALENDAR" CRLF 4217 creply-props 4218 1*(create-vreply) 4219 "END" ":" "VCALENDAR" CRLF 4220 ; 4221 create-vreply = "BEGIN" ":" "VREPLY" CRLF 4222 created-id 4223 rstatus 4224 other-props 4225 "END" ":" "VREPLY" CRLF 4226 ; 4227 ; Where the id is appropriate for the 4228 ; type of object created: 4229 ; 4230 ; VAGENDA = relcalid 4231 ; VALARM = sequence 4232 ; VCAR = carid 4233 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 4234 ; VQUERY = queryid 4235 ; VTIMEZONE = tzid 4236 ; x-comp = x-id 4237 ; 4238 created-id = ( relcalid / carid / uid / queryid / 4239 tzid / sequence / x-id) 4240 ; 4241 tzid = ; As defined in [iCAL] 4242 ; 4243 sequence = ; As defined in [iCAL] 4244 ; 4245 uid = ; As defined in [iCAL] 4246 ; 4247 x-id = ; An ID for an x-component. 4248 ; 4249 creply-props = 4*( 4250 ; These are REQUIRED and MUST NOT occur 4251 ; more than once. 4252 ; 4253 prodid /version / target / reply-cmd 4254 ; 4255 ; These are optional, and may occur more 4256 ; than once. 4257 ; 4258 other-props ) 4260 For a "CREATE" command the "TARGET" property specifies the containers 4261 where the components will be created. 4263 If the iCalendar object being created does not have a "METHOD" 4264 property, then is not an [iTIP] object, then its state will be 4265 "BOOKED". Use the "DELETE" command to set the state of an object to 4266 the "DELETED" state (tagged for deletion). A CUA can not use the 4267 "CREATE" command to create an object in the "DELETED" state. 4269 If the intention is to book an [iTIP] object then the "METHOD" 4270 property MUST NOT BE supplied. Otherwise any [iTIP] object MUST have 4271 a valid [iTIP] "METHOD" property value and it is a scheduling request 4272 being deposited into the CS and will have its state set to 4273 "UNPROCESSED" state. 4275 ABNF for a "CREATE" object is: 4277 create-object = "BEGIN" ":" "VCALENDAR" CRLF 4278 ; If 'calprops' contain the "METHOD" property 4279 ; then this 'create-object' component MUST 4280 ; conform to [iTIP] restrictions. 4281 ; 4282 ; calprops MUST include 'create-cmd' 4283 ; 4284 calprops 4285 other-props 4286 1*(create-comp) 4287 "END" ":" "VCALENDAR" CRLF 4289 ; NOTE: The 'VCALSTORE' component is not included in 4290 ; 'create-comp' as it is out of scope for CAP to create 4291 ; a new CS. 4292 ; 4293 create-comp = agendac / carc / queryc 4294 / timezonec / freebusyc 4295 / eventc / todoc / journalc 4296 / iana-comp / x-comp 4297 ; 4298 freebusyc = ; As defined in [iCAL] 4299 ; 4300 eventc = ; As defined in [iCAL] 4301 ; 4302 journalc = ; As defined in [iCAL] 4303 ; 4304 timezonec = ; As defined in [iCAL] 4305 ; 4306 todoc = ; As defined in [iCAL] 4308 In the following example two new top level "VAGENDA" components are 4309 created. Note that the "CSID" value of the server is 4310 cal.example.com which is where the new "VAGENDA" components are 4311 going to be created. 4313 C: Content-Type: text/calendar 4314 C: 4315 C: BEGIN:VCALENDAR 4316 C: PRODID:-//someone's prodid 4317 C: VERSION:2.0 4318 C: CMD;ID=creation01:CREATE 4319 C: TARGET:cal.example.com 4320 C: BEGIN:VAGENDA <- data for 1st new calendar 4321 C: CALID:relcalz1 4322 C: NAME;LANGUAGE=en_US:Bill's Soccer Team 4323 C: OWNER:bill 4324 C: CALMASTER:mailto:bill@example.com 4325 C: TZID:US/Pacific 4326 C: END:VAGENDA 4327 C: BEGIN:VAGENDA <- data for 2nd new calendar 4328 C: CALID:relcalz2 4329 C: NAME;LANGUAGE=EN-us:Mary's personal calendar 4330 C: OWNER:mary 4331 C: CALMASTER:mailto:mary@example.com 4332 C: TZID:US/Pacific 4333 C: END:VAGENDA 4334 C: END:VCALENDAR 4336 S: Content-Type: text/calendar 4337 S: 4338 S: BEGIN:VCALENDAR 4339 S: VERSION:2.0 4340 S: PRODID:-//someone's prodid 4341 S: CMD;ID=creation01:REPLY 4342 S: TARGET:cal.example.com 4343 S: BEGIN:VREPLY <- Reply for 1st calendar create 4344 S: CALID:relcalz1 4345 S: REQUEST-STATUS:2.0 4346 S: END:REPLY 4347 S: BEGIN:VREPLY <- Reply for 2nd calendar create 4348 S: CALID:relcalz2 4349 S: REQUEST-STATUS:2.0 4350 S: END:VREPLY 4351 S: END:VCALENDAR 4353 To create a new component in multiple containers simply name all of 4354 the containers in the "TARGET" in the create command. Here a new 4355 "VEVENT" component is created in two TARGET components. In this 4356 example, the "VEVENT" component is one new [iTIP] "REQUEST" to be 4357 stored in two calendars. The results would be iCalendar objects that 4358 conform to the [iTIP] replies as defined in [iTIP]. 4360 This example shows two [iTIP] "VEVENT" components being created in 4361 each of the two supplied "TARGET" properties and as it contains the 4362 "METHOD" property they will be stored in the "UNPROCESSED" state: 4364 C: Content-Type: text/calendar 4365 C: 4366 C: BEGIN:VCALENDAR 4367 C: VERSION:2.0 4368 C: PRODID:-//someone's prodid 4369 C: CMD;ID=creation02:CREATE 4370 C: METHOD:REQUEST 4371 C: TARGET:relcalz1 4372 C: TARGET:relcalz2 4373 C: BEGIN:VEVENT 4374 C: DTSTART:20030307T180000Z 4375 C: UID:FirstInThisExample-1 4376 C: DTEND:20030307T190000Z 4377 C: SUMMARY:Important Meeting 4378 C: END:VEVENT 4379 C: BEGIN:VEVENT 4380 C: DTSTART:20040307T180000Z 4381 C: UID:SecondInThisExample-2 4382 C: DTEND:20040307T190000Z 4383 C: SUMMARY:Important Meeting 4384 C: END:VEVENT 4385 C: END:VCALENDAR 4387 The CS sends the "VREPLY" commands in separate MIME objects, one per 4388 supplied "TARGET" property value. 4390 S: Content-Type: text/calendar 4391 S: 4392 S: BEGIN:VCALENDAR 4393 S: VERSION:2.0 4394 S: PRODID:-//someone's prodid 4395 S: CMD;ID=creation02:REPLY 4396 S: TARGET:relcalz1 <- 1st TARGET listed. 4397 S: BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET. 4398 S: UID:FirstInThisExample-1 4399 S: REQUEST-STATUS:2.0 4400 S: END:VREPLY 4401 S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET. 4402 S: UID:SecondInThisExample-2 4403 S: REQUEST-STATUS:2.0 4404 S: END:VREPLY 4405 S: END:VCALENDAR 4407 And the second reply for the 2nd TARGET: 4409 S: Content-Type: text/calendar 4410 S: 4411 S: BEGIN:VCALENDAR 4412 S: VERSION:2.0 4413 S: PRODID:-//someone's prodid 4414 S: CMD;ID=creation02:REPLY 4415 S: TARGET:relcalz2 <- 2nd TARGET listed 4416 S: BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET. 4417 S: UID:FirstInThisExample-1 4418 S: REQUEST-STATUS:2.0 4419 S: END:VREPLY 4420 S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET. 4421 S: UID:SecondInThisExample-2 4422 S: REQUEST-STATUS:2.0 4423 S: END:VREPLY 4424 S: END:VCALENDAR 4426 10.5 DELETE Command 4428 CMD: DELETE 4430 Purpose: The "DELETE" command physically removes the QUERY result 4431 from the store or marks it for deletion. 4433 A CUA MAY send a "DELETE" command to a CS. The "DELETE" command MUST 4434 BE implemented by all CSs. 4436 The CS MUST NOT send a "DELETE" command to any CUA. 4438 Formal Definition: A "DELETE" command is defined by the following 4439 notation: 4441 delete-cmd = deleteparam ":" "DELETE" 4442 ; 4443 deleteparam = *( 4444 ; 4445 ; the following are optional, 4446 ; but MUST NOT occur more than once 4447 ; 4448 id-param 4449 / localize-param 4450 / latency-param 4451 / option-param "MARK" 4452 ; 4453 ; The following MUST occur exactly once and only 4454 ; when the latency-param has been supplied and 4455 ; MUST NOT be supplied if the latency-param is 4456 ; not supplied. 4457 ; 4458 / action-param 4459 ; 4460 ; the following is optional, 4461 ; and MAY occur more than once 4462 ; 4463 / other-params 4464 ) 4466 The "DELETE" command is used to delete calendars or components. The 4467 included "VQUERY" component(s) specifies the container(s) to delete. 4469 If a component is to be marked for delete and not physically removed, 4470 then include the "OPTIONS" parameter with its value set to the "MARK" 4471 value in order to alter its state to "DELETED". 4473 When components are deleted, only the top most component "REQUEST- 4474 STATUS" properties are returned. No "REQUEST-STATUS" properties are 4475 returned for components inside of the selected components. There 4476 MUST BE one "VREPLY" component returned for each object that is 4477 deleted or marked for delete. Note that if no "VREPLY" components 4478 are returned then nothing matched and nothing was deleted. 4480 Restriction Table for the "REPLY" command for any "DELETE" command. 4482 delete-reply = "BEGIN" ":" "VCALENDAR" CRLF 4483 calprops ; MUST include 'reply-cmd' 4484 *(delete-vreply) 4485 "END" ":" "VCALENDAR" CRLF 4486 ; 4487 delete-vreply = "BEGIN" ":" "VREPLY" CRLF 4488 deleted-id 4489 rstatus 4490 "END" ":" "VREPLY" CRLF 4491 ; 4492 ; Where the id is appropriate for the 4493 ; type of object deleted: 4494 ; 4495 ; VAGENDA = relcalid 4496 ; VCAR = carid 4497 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 4498 ; VQUERY = queryid 4499 ; ALARM = sequence 4500 ; VTIMEZONE = tzid 4501 ; x-comp = x-id 4502 ; An instance = uid recurid 4503 ; 4504 deleted-id = ( relcalid / carid / uid / uid recurid 4505 / queryid / tzid / sequence / x-id ) 4507 Example to delete a "VEVENT" component with "UID" value of 4508 'abcd12345' from the calendar "relcald-22" from the current CS: 4510 C: Content-Type: text/calendar 4511 C: 4512 C: BEGIN:VCALENDAR 4513 C: TARGET:relcalid-22 4514 C: CMD;ID:"random but unique per CUA":DELETE 4515 C: BEGIN:VQUERY 4516 C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345' 4517 C: END:VQUERY 4518 C: END:VCALENDAR 4520 S: BEGIN:VCALENAR 4521 S: TARGET:relcalid-22 4522 S: CMD;ID:"random but unique per CUA":REPLY 4523 S: BEGIN:VREPLY 4524 S: UID:abcd12345 4525 S: REQUEST-STATUS:3.0 4526 S: END:VREPLY 4527 S: END:VCALENDAR 4529 One or more iCalendar objects will be returned that contain a 4530 "REQUEST-STATUS" properties for the deleted components. There could 4531 have been more than one component deleted. Any booked and any number 4532 of unprocessed [iTIP] scheduling components that matched the QUERY 4533 value in the above example. Each unique "METHOD" property value that 4534 was deleted from the store MUST BE in a separate iCalendar object. 4535 This is because only one "METHOD" property is allowed in a single 4536 "VCALENDAR" BEGIN/END block. 4538 10.6 GENERATE-UID Command 4540 CMD: GENERATE-UID 4542 Purpose: The "GENERATE-UID" command returns one or more unique 4543 identifiers which MUST BE globally unique. 4545 The "GENERATE-UID" command MAY BE sent to any CS. The "GENERATE-UID" 4546 command MUST BE implemented by all CSs. 4548 The "GENERATE-UID" command MUST NOT be sent to a CUA. 4550 Formal Definition: A "GENERATE-UID" command is defined by the 4551 following notation: 4553 generate-uid-cmd = genuidparam ":" "GENERATE-UID" 4554 ; 4555 genuidparam = *( 4556 ; 4557 ; The following are optional, 4558 ; but MUST NOT occur more than once. 4559 ; 4560 id-param 4561 / localize-param 4562 / latency-param 4563 ; 4564 ; The following MUST occur exactly once and only 4565 ; when the latency-param has been supplied and 4566 ; MUST NOT be supplied if the latency-param is 4567 ; not supplied. 4568 ; 4569 / action-param 4570 ; 4571 ; The following is optional, 4572 ; and MAY occur more than once. 4573 ; 4574 / other-params 4575 ; 4576 ; The following MUST BE supplied exactly once. 4577 ; The value specifies the number of UIDs to 4578 ; be returned. 4579 ; 4580 / option-param posint1 4581 ) 4583 Response: 4585 gen-reply = "BEGIN" ":" "VCALENDAR" CRLF 4586 calprops ; Which MUST include 'reply-cmd' 4587 1*(gen-vreply) 4588 "END" ":" "VCALENDAR" CRLF 4590 gen-vreply = "BEGIN" ":" "VREPLY" CRLF 4591 1*(uid) 4592 rstatus 4593 "END" ":" "VREPLY" CRLF 4595 Example: 4597 C: BEGIN:VCALENDAR 4598 C: VERSION:2.0 4599 C: PRODID:-//someone's prodid 4600 C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID 4601 C: END:VCALENDAR 4603 S: Content-Type: text/calendar 4604 S: 4605 S: BEGIN:VCALENDAR 4606 S: VERSION:2.0 4607 S: PRODID:-//someone's prodid 4608 S: CMD;ID=unique-per-cua-124:REPLY 4609 S: BEGIN:VREPLY 4610 S: UID:20011121T120000Z-12340@cal.example.com 4611 S: UID:20011121T120000Z-12341@cal.example.com 4612 S: UID:20011121T120000Z-12342@cal.example.com 4613 S: UID:20011121T120000Z-12343@cal.example.com 4614 S: UID:20011121T120000Z-12344@cal.example.com 4615 S: REQUEST-STATUS:2.0 4616 S: END:VREPLY 4617 S: END:VCALENDAR 4619 10.7 GET-CAPABILITY Command 4621 CMD: GET-CAPABILITY 4623 Purpose: The "GET-CAPABILITY" command returns the capabilities of the 4624 other end point of the session. 4626 A CUA MUST send a "GET-CAPABILITY" command to a CS after the initial 4627 connection. A CS MUST send a "GET-CAPABILITY" command to a CUA after 4628 the initial connection. The "GET-CAPABILITY" command and reply MUST 4629 BE implemented by all CSs and CUAs. 4631 Formal Definition: A "GET-CAPABILITY" command is defined by the 4632 following notation: 4634 get-capability-cmd = capibiltyparam ":" "GET-CAPABILITY" 4635 ; 4636 capibiltyparam = *( 4637 ; 4638 ; the following are optional, 4639 ; but MUST NOT occur more than once 4640 ; 4641 id-param / localize-param / latency-param 4642 ; 4643 ; the following MUST occur exactly once and only 4644 ; when the latency-param has been supplied and 4645 ; MUST NOT be supplied if the latency-param is 4646 ; not supplied. 4647 ; 4648 / action-param 4649 ; 4650 ; the following is optional, 4651 ; and MAY occur more than once 4652 ; 4653 / other-params 4654 ) 4656 Response: 4658 The "GET-CAPABILITY" command returns information about the Calendar 4659 other end of the session given the current state of the connection. 4660 The values returned may differ depending on current user identify and 4661 the security level of the connection. 4663 Client implementations SHOULD NOT require any capability element 4664 beyond those defined in this specification or future RFC publications 4665 , and MAY ignore any nonstandard, experimental capability elements. 4666 The "GET-CAPABILITY" reply may return different results depending on 4667 the UPN and if the UPN is authenticated. 4669 When sending a reply to a "GET-CAPABILITY" command, all of these MUST 4670 BE supplied. The following properties are returned in response to a 4671 "GET-CAPABILITY" command: 4673 cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF 4674 ; The following properties may be in any order. 4675 ; 4676 prodid 4677 version 4678 reply-cmd 4679 other-props 4680 "BEGIN" ":" "VREPLY" CRLF 4681 ; The following properties may be in any order. 4682 ; 4683 cap-version 4684 car-level 4685 components 4686 stores-expanded 4687 maxdate 4688 mindate 4689 itip-version 4690 max-comp-size 4691 multipart 4692 query-level 4693 recur-accepted 4694 recur-expand 4695 recur-limit 4696 other-props 4697 "END" ":" "VREPLY" CRLF 4698 "END" ":" "VCALENDAR" CRLF 4700 Example: 4702 I: Content-Type: text/calendar 4703 I: 4704 I: BEGIN:VCALENDAR 4705 I: VERSION:2.0 4706 I: PRODID:-//someone's prodid 4707 I: CMD;ID=unique-per-cua-125:GET-CAPABILITY 4708 I: END:VCALENDAR 4710 L: Content-Type: text/calendar 4711 L: 4712 L: BEGIN:VCALENDAR 4713 L: VERSION:2.0 4714 L: PRODID:-//someone's prodid 4715 L: CMD;ID=unique-per-cua-125:REPLY 4716 L: BEGIN:VREPLY 4717 L: CAP-VERSION:1.0 4718 L: PRODID:The CS prodid 4719 L: QUERY-LEVEL:CAL-QL-1 4720 L: CAR-LEVEL:CAR-FULL-1 4721 L: MAXDATE:99991231T235959Z 4722 L: MINDATE:00000101T000000Z 4723 L: MAX-COMPONENT-SIZE:0 4724 L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR, 4725 L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY 4726 L: ITIP-VERSION:2446 4727 L: RECUR-ACCEPTED:TRUE 4728 L: RECUR-EXPAND:TRUE 4729 L: RECUR-LIMIT:0 4730 L: STORES-EXPANDED:FALSE 4731 L: X-INET-PRIVATE-COMMANDS:1.0 4732 L: END:VREPLY 4733 L: END:VCALENDAR 4735 10.8 IDENTIFY Command 4737 CMD: IDENTIFY 4739 Purpose: The "IDENTIFY" command allows the CUA to set a new identity 4740 to be used for calendar access. 4742 A CUA MAY send an "IDENTIFY" command to a CS. The "IDENTIFY" command 4743 MUST BE implemented by all CSs. A CS implementation MAY reject all 4744 "IDENTIFY" commands. 4746 The CS MUST NOT send a "IDENTIFY" command to any CUA. 4748 Formal Definition: A "IDENTIFY" command is defined by the following 4749 notation: 4751 identify-cmd = identifyparam ":" "IDENTIFY" 4752 ; 4753 identifyparam = *( 4754 ; 4755 ; the following are optional, 4756 ; but MUST NOT occur more than once 4757 ; 4758 id-param 4759 / localize-param 4760 / latency-param 4761 ; 4762 ; the following MUST occur exactly once and only 4763 ; when the latency-param has been supplied and 4764 ; MUST NOT be supplied if the latency-param is 4765 ; not supplied. 4766 ; 4767 / action-param 4768 ; 4769 ; the following is optional, 4770 ; and MAY occur more than once 4771 ; 4772 / other-params 4773 ; 4774 ; The value is the UPN of the requested 4775 ; identity. If option is not supplied it is 4776 ; a request to return to the original authenticated 4777 ; identity. 4778 ; 4779 / option-param upn 4780 ) 4782 Response: 4784 A "REQUEST-STATUS" property wrapped in a "VREPLY" component with only one of the following 4785 request-status codes: 4787 2.0 Successful. 4789 6.4 Identity not permitted. VCAR restriction. 4791 The CS determines through an internal mechanism if the credentials 4792 supplied at authentication permit the operation as the selected 4793 identity. If they do, the session assumes the new identity, 4794 otherwise a security error is returned. 4796 Example: 4798 C: Content-Type: text/calendar 4799 C: 4800 C: BEGIN:VCALENDAR 4801 C: VERSION:2.0 4802 C: PRODID:-//someone's prodid 4803 C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY 4804 C: END:VCALENDAR 4806 S: Content-Type: text/calendar 4807 S: 4808 S: BEGIN:VCALENDAR 4809 S: VERSION:2.0 4810 S: PRODID:-//someone's prodid 4811 S: BEGIN:VREPLY 4812 S: REQUEST-STATUS:2.0;Request Approved 4813 S: END:VREPLY 4814 S: END:VCALENDAR 4816 Or if denied: 4818 S: Content-Type: text/calendar 4819 S: 4820 S: BEGIN:VCALENDAR 4821 S: PRODID:-//someone's prodid 4822 S: VERSION:2.0 4823 S: BEGIN:VREPLY 4824 S: REQUEST-STATUS:6.4;Request Denied 4825 S: END:VREPLY 4826 S: END:VCALENDAR 4828 And for the CUA to return to its original authenticated identity 4829 the OPTIONS parameter is omitted: 4831 C: Content-Type: text/calendar 4832 C: 4833 C: BEGIN:VCALENDAR 4834 C: VERSION:2.0 4835 C: PRODID:-//someone's prodid 4836 C: CMD;ID=unique-per-cua-995:IDENTIFY 4837 C: END:VCALENDAR 4839 The CS may accept (2.0) or deny (6.4) the request to return to the 4840 original identity. 4842 If a CS considers the "IDENTIFY" command an attempt to violate 4843 security, the CS MAY terminate the [BEEP] session without any further 4844 notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. 4846 10.9 MODIFY Command 4848 CMD: MODIFY 4850 Purpose: The "MODIFY" command is used to modify existing components. 4852 A CUA MAY send a "MODIFY" command to a CS. The "MODIFY" command MUST 4853 BE implemented by all CSs. 4855 The CS MUST NOT send a "MODIFY" command to any CUA. 4857 Formal Definition: A "MODIFY" command is defined by the following 4858 notation: 4860 modify-cmd = modifyparam ":" "MODIFY" 4861 ; 4862 modifyparam = *( 4863 ; 4864 ; the following are optional, 4865 ; but MUST NOT occur more than once 4866 ; 4867 id-param 4868 / localize-param 4869 / latency-param 4870 ; 4871 ; the following MUST occur exactly once and only 4872 ; when the latency-param has been supplied and 4873 ; MUST NOT be supplied if the latency-param is 4874 ; not supplied. 4875 ; 4876 / action-param 4877 ; 4878 ; the following is optional, 4879 ; and MAY occur more than once 4880 ; 4881 / other-params 4882 ) 4884 The "MODIFY" command is used to modify existing components. The 4885 TARGET property specifies the calendars where the components exist 4886 that are going to be modified. 4888 The format of the request is three components inside of "VCALENDAR" 4889 component: 4891 BEGIN:VCALENDAR 4892 ... 4893 BEGIN:VQUERY 4894 ... 4895 END:VQUERY 4896 BEGIN:XXX 4897 ...old-values... 4898 END:XXX 4899 BEGIN:XXX 4900 ...new-values... 4901 END:XXX 4902 END:VCALENDAR 4904 The "VQUERY" component selects the components that are to be 4905 modified. 4907 Where "XXX" above is a named component type (VEVENT, VTODO, ...). 4908 Both the old and new components MUST BE of the same type. 4910 The old-values is a component and the contents of that component are 4911 going to change and may contain information that helps uniquely 4912 identify the original component (SEQUENCE in the example below). If 4913 the CS can not find a component that matches the QUERY and does not 4914 have at least all of the OLD-VALUES, then a 6.1 error is returned. 4916 The new-values is a component of the same type as old-values and new- 4917 values contains the new data for each selected component. Any data 4918 that is in old-values and not in new-values is deleted from the 4919 selected component. Any values in new-values that was not in old- 4920 values is added to the component. 4922 In this example the "VEVENT" component with a "UID" property value of 4923 'unique-58' has; the "LOCATION" property and "LAST-MODIFIED" property 4924 changed, the "VALARM" component with the "SEQUENCE" property with a 4925 value of "3" has its "TRIGGER" property disabled, the "X-LOCAL" 4926 property is removed from the "VEVENT" component, and a "COMMENT" 4927 property is added. 4929 Because "SEQUENCE" property is used to locate the "VALARM" component 4930 in this example, both the old-values and the new-values contain the 4931 "SEQUENCE" property with a value of "3" and if the "SEQUENCE" 4932 property were to be left out of new-values, it would have been 4933 deleted. 4935 Example: 4937 C: Content-Type: text/calendar 4938 C: 4939 C: BEGIN:VCALENDAR 4940 C: VERSION:2.0 4941 C: PRODID:-//someone's prodid 4942 C: TARGET:my-cal 4943 C: CMD:ID=unique-mod:MODIFY 4944 C: BEGIN:VQUERY <- Query to select data set. 4945 C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58' 4946 C: END:VQUERY 4947 C: BEGIN:VEVENT <- Start of old data. 4948 C: LOCATION:building 3 4949 C: LAST-MODIFIED:20020101T123456Z 4950 C: X-LOCAL:some private stuff 4951 C: BEGIN:VALARM 4952 C: SEQUENCE:3 4953 C: TRIGGER;RELATED=END:PT5M 4954 C: END:VALARM 4955 C: END:VEVENT <- End of old data. 4956 C: BEGIN:VEVENT <- Start of new data. 4957 C: LOCATION:building 4 4958 C: LAST-MODIFIED:20020202T010203Z 4959 C: COMMENT:Ignore global trigger. 4960 C: BEGIN:VALARM 4961 C: SEQUENCE:3 4962 C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M 4963 C: END:VALARM 4964 C: END:VEVENT <- End of new data. 4965 C: END:VCALENDAR 4967 The "X-LOCAL" property was not supplied in the new-values, so it was 4968 deleted. The "LOCATION" property value was altered, as was the 4969 "LAST-MODIFIED" value. The "VALARM" component with a "SEQUENCE" 4970 property value of "3" had its "TRIGGER" property disabled, and the 4971 "SEQUENCE" property value did not change so it was not effected. The 4972 "COMMENT" property was added. 4974 When it comes to inline ATTACHMENTs, the CUA only needs to uniquely 4975 identify the contents of the ATTACHMENT value in the old-values in 4976 order to delete them. When the CS compares the attachment data it is 4977 compared in its binary form. The ATTACHMENT value supplied by the 4978 CUA MUST BE valid encoded information. 4980 For example, to delete the same huge inline attachment from every 4981 VEVENT in 'my-cal' that has an "ATTACH" property value with the old- 4982 values: 4984 BEGIN:VCALENDAR 4985 VERSION:2.0 4986 PRODID:-//someone's prodid 4987 TARGET:my-cal 4988 CMD:MODIFY 4989 BEGIN:VQUERY 4990 QUERY:SELECT ATTACH FROM VEVENT 4991 END:VQUERY 4992 BEGIN:VEVENT 4993 ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: 4994 MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U 4995 EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE 4996 ...< remainder of attachment data NOT supplied >.... 4997 END:VEVENT 4998 BEGIN:VEVENT 4999 END:VEVENT 5000 END:VCALENDAR 5002 Above the new-values is empty, so everything in the old-values is 5003 deleted. 5005 Furthermore, the following additional restrictions apply: 5007 1. One can not change the "UID" property of a component. 5009 2. If a contained component is changed inside of a selected 5010 component, and that contained component has multiple instances, 5011 then old-values MUST contain information that uniquely identifies 5012 the instance or instances that are changing. It is valid to 5013 change more than one. As all contained components that match 5014 old-values will be modified. In the first modify example above, 5015 if "SEQUENCE" properties were to be deleted from both the old- 5016 values and new-values, then all "TRIGGER" properties that matched 5017 the old-values in all "VALARM" components in the selected 5018 "VEVENT" components would be disabled. 5020 3. The result of the modify MUST BE a valid iCalendar object. 5022 Response: 5024 A "VCALENDAR" component is returned with one ore more "REQUEST- 5025 STATUS" property values. 5027 If any error occurred: 5029 No component will be changed at all. That is, it will appear just 5030 as it was prior to the modify and the CAP server SHOULD return a 5031 "REQUEST-STATUS" property for each error that occurred. 5033 There MUST BE at least one error reported. 5035 If multiple components are selected, then what uniquely identified 5036 the component MUST BE returned (UID, QUERYID, ...) if the component 5037 contains a unique identifier. If not, sufficient information to 5038 uniquely identify the modified components MUST BE returned in the 5039 reply. 5041 S: Content-Type: text/calendar 5042 S: 5043 S: BEGIN:VCALENDAR 5044 S: TARGET:relcalid 5045 S: CMD;ID=delete#1:REPLY 5046 S: BEGIN:VREPLY 5047 S: BEGIN:VEVENT 5048 S: UID:123 5049 S: REQUEST-STATUS:2.0 5050 S: END:VEVENT 5051 S: END:VREPLY 5052 S: END:VCALENDAR 5054 10.10 MOVE Command 5056 CMD: MOVE 5058 Purpose: The "MOVE" command is used to move components within the CS. 5060 A CUA MAY send a "MOVE" command to a CS. The "MOVE" command MUST BE 5061 implemented by all CSs. 5063 The CS MUST NOT send a "MOVE" command to any CUA. 5065 Formal Definition: A "MOVE" command is defined by the following 5066 notation: 5068 move-cmd = moveparam ":" "MOVE" 5069 ; 5070 moveparam = *( 5071 ; 5072 ; the following are optional, 5073 ; but MUST NOT occur more than once 5074 ; 5075 id-param 5076 / localize-param 5077 / latency-param 5078 ; 5079 ; the following MUST occur exactly once and only 5080 ; when the latency-param has been supplied and 5081 ; MUST NOT be supplied if the latency-param is 5082 ; not supplied. 5083 ; 5084 / action-param 5085 ; 5086 ; the following is optional, 5087 ; and MAY occur more than once 5088 ; 5089 / other-params 5090 ; 5091 ) 5093 Response: 5094 The REQUEST-STATUS in a VCALENDAR object. 5096 The content of each "result" is subject to the result restriction 5097 table defined below. 5099 The access control on the "VAGENDA" component after it has been moved 5100 to its new location in the calstore MUST BE at least as secure as it 5101 was prior to the move. If the CS is not able to ensure the same 5102 level of security, a permission denied "REQUEST-STATUS" property 5103 value MUST BE returned and the "MOVE" command not performed. 5105 The "TARGET" property value specifies the new location, and the 5106 "VQUERY" component specifies the old location. 5108 Restriction Table for the "REPLY" command of any "MOVE" command. 5110 move-reply = "BEGIN" ":" "VCALENDAR" CRLF 5111 calprops 5112 1*(move-vreply) 5113 "END" ":" "VCALENDAR" CRLF 5115 move-vreply = "BEGIN" ":" "VREPLY" CRLF 5116 move-id 5117 rstatus 5118 "END" ":" "VREPLY" CRLF 5120 ; Where the id is appropriate for the 5121 ; type of object moved: 5122 ; 5123 ; VAGENDA = relcalid 5124 ; VCAR = carid 5125 ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid 5126 ; VQUERY = queryid 5127 ; ALARM = sequence 5128 ; An instance = uid recurid 5129 ; x-comp = x-id 5130 ; 5131 move-id = ( relcalid / carid / uid / uid recurid 5132 / queryid / tzid / sequence / x-id) 5134 Example: moving the VAGENDA Nellis to Area-51 5135 C: Content-Type: text/calendar 5136 C: 5137 C: BEGIN:VCALENDAR 5138 C: VERSION:2.0 5139 C: PRODID:-//someone's prodid 5140 C: CMD:MOVE 5141 C: TARGET:Area-51 5142 C: BEGIN:VQUERY 5143 C: QUERY: SELECT * FROM VAGENDA WHERE CALID='Nellis' 5144 C: END:VQUERY 5145 C: END:VCALENDAR 5147 S: Content-Type: text/calendar 5148 S: 5149 S: BEGIN:VCALENDAR 5150 S: VERSION:2.0 5151 S: PRODID:-//someone's prodid 5152 S: TARGET:Area-51 5153 S: BEGIN:VREPLY 5154 S: CALID:Nellis 5155 S: REQUEST-STATUS: 2.0 5156 S: END:VREPLY 5157 S: END:VCALENDAR 5159 10.11 REPLY Response to a Command 5161 CMD: REPLY 5163 Purpose: The "REPLY" value to the "CMD" property is used to return 5164 the results of all other commands to the CUA. 5166 A CUA MUST send a "REPLY" command to a CS for any command a CS MAY 5167 send to the CUA. The "REPLY" command MUST BE implemented by all CUAs 5168 that support getting the "GET-CAPABILITY" command. 5170 A CS MUST send a "REPLY" command to a CUA for any command a CUA MAY 5171 send to the CS. The "REPLY" command MUST BE implemented by all CSs. 5173 Formal Definition: A "REPLY" command is defined by the following 5174 notation: 5176 reply-cmd = replyparam ":" "REPLY" 5177 ; 5178 replyparam = *( 5179 ; 5180 ; The 'id' parameter value MUST BE exactly the 5181 ; same as the value sent in the original 5182 ; CMD property. If the original CMD did 5183 ; not have an 'id' parameter, then the 'id' 5184 ; MUST NOT be supplied in the REPLY. 5185 ; 5186 id-param 5187 ; 5188 ; the following is optional, 5189 ; and MAY occur more than once 5190 ; 5191 / other-params 5192 ) 5194 10.12 SEARCH Command 5196 CMD: SEARCH 5198 Purpose: The "SEARCH" command is used to return selected components 5199 to the CUA. 5201 A CUA MAY send a "SEARCH" command to a CS. The "SEARCH" command MUST 5202 BE implemented by all CSs. 5204 The CS MUST NOT send a "SEARCH" command to any CUA. 5206 Formal Definition: A "SEARCH" command is defined by the following 5207 notation: 5209 search-cmd = searchparam ":" "SEARCH" 5210 ; 5211 searchparam = *( 5212 ; 5213 ; the following are optional, 5214 ; but MUST NOT occur more than once 5215 ; 5216 id-param 5217 / localize-param 5218 / latency-param 5219 ; 5220 ; the following MUST occur exactly once and only 5221 ; when the latency-param has been supplied and 5222 ; MUST NOT be supplied if the latency-param is 5223 ; not supplied. 5224 ; 5225 / action-param 5226 ; 5227 ; the following is optional, 5228 ; and MAY occur more than once 5229 ; 5230 / other-params 5231 ) 5233 The format of the request is the search command (search-cmd) followed 5234 by one or more (query) "VQUERY" components 5236 Response: 5238 The data in each result set contains one or more iCalendar components 5239 composed of all the selected results enclosed in a single "VREPLY" 5240 component per "QUERY". 5242 Only "REQUEST-STATUS" property and the properties mentioned in the 5243 "SELECT" clause of the QUERY are included in the components. Each 5244 "VCALENDAR" component is tagged with the "TARGET" property. 5246 Searching for objects 5248 In the example below objects on March 10,1999 between 080000Z and 5249 190000Z are read. In this case only 4 properties for each objects 5250 are returned. Two calendars are specified. Only booked (vs 5251 scheduled) entries are to be returned (this example only selected 5252 VEVENT objects): 5254 C: Content-Type: text/calendar 5255 C: 5256 C: BEGIN:VCALENDAR 5257 C: VERSION:2.0 5258 C: PRODID:-//someone's prodid 5259 C: CMD:SEARCH 5260 C: TARGET:relcal2 5261 C: TARGET:relcal3 5262 C: BEGIN:VQUERY 5263 C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID 5264 C: FROM VEVENT 5265 C: WHERE DTEND >= '19990310T080000Z' 5266 C: AND DTSTART <= '19990310T190000Z' 5267 C: AND STATE() = 'BOOKED' 5268 C: END:VQUERY 5269 C: END:VCALENDAR 5271 The return values are subject to VCAR filtering. That is, if the 5272 request contains properties to which the UPN does not have access, 5273 those properties will not appear in the return values. If the UPN 5274 has access to at least one property of the component, but has been 5275 denied access to all properties called out in the request, the 5276 response will contain a single "REQUEST-STATUS" property indicating 5277 the error. 5279 Here the request was successful, however one of the "VEVENT" 5280 components contents were not accessible (4.1). 5282 S: Content-Type: text/calendar 5283 S: 5284 S: BEGIN:VCALENDAR 5285 S: TARGET:relcalid 5286 S: CMD:REPLY 5287 S: VERSION:2.0 5288 S: PRODID:-//someone's prodid 5289 S: BEGIN:VREPLY 5290 S: BEGIN:VEVENT 5291 S: REQUEST-STATUS:4.1 5292 S: END:VEVENT 5293 S: BEGIN:VEVENT 5294 S: REQUEST-STATUS:2.0 5295 S: UID:123 5296 S: DTEND:19990310T080000Z 5297 S: DSTART:19990310T190000Z 5298 S: SUMMARY: Big meeting 5299 S: END:VEVENT 5300 S: END:VREPLY 5301 S: END:VCALENDAR 5303 If the UPN has no access to any components at all, the response will 5304 simply be an empty data set. The response looks the same if there 5305 the particular components did not exist. 5307 S: Content-Type: text/calendar 5308 S: 5309 S: BEGIN:VCALENDAR 5310 S: VERSION:2.0 5311 S: PRODID:-//someone's prodid 5312 S: CMD:REPLY 5313 S: TARGET:ralcalid 5314 S: BEGIN:VREPLY 5315 S: REQUEST-STATUS:2.0 5316 S: END:VREPLY 5317 S: END:VCALENDAR 5319 If there are multiple targets, each iCalendar reply is contained 5320 within its own iCalendar object. 5322 10.12.1 Searching for VFREEBUSY 5324 If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the 5325 "VFREEBUSY" component in the "COMPONENTS" value in a reply to the 5326 "GET-CAPABILITY" command, then it is the CS's responsibility and not 5327 the CUA's responsibility to provide the correct "VFREEBUSY" 5328 information for a calendar. 5330 If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return success 5331 and not store the "VFREEBUSY" component as the results would never be 5332 used. 5334 Such a CS MUST dynamically create the results of a search for 5335 "VFREEBUSY" components at search time when searching for STATE() = 5336 'BOOKED' items. 5338 If a CUA searches for "VFREEBUSY" components with STATE() = 5339 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. 5341 If a CUA searches for "VFREEBUSY" components without specifying the 5342 STATE, such a CS MUST return the same result as if STATE()='BOOKED' 5343 had been specified. 5345 For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE" 5346 and have the "VFREEBUSY" component in the "COMPONENTS" value in the 5347 "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on 5348 the CS. These CSs then MUST return a "VFREEBUSY" component 5349 calculated from the stored components. If no "VFREEBUSY" information 5350 is available for the "TARGET" calendar, then a "VFREEBUSY" with no 5351 blocked out time will be returned with a success code. A CUA sets 5352 the "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY" 5353 component without a "METHOD" creating a "BOOKED" entry. 5355 If a CS does not set the "VFREEBUSY" value in the "COMPONENTS" 5356 "CAPABILITY" value, the CS does not support the "VFREEBUSY" component 5357 and all creation and searching for a "VFREEBUSY" component MUST fail. 5358 Examples of calendars that may be in this category are public event 5359 calendars that will never require scheduling with other UPNs. 5361 10.13 SET-LOCALE Command 5363 CMD: SET-LOCALE 5365 Purpose: The "SET-LOCALE" command is used to select the locale that 5366 will be used in error codes used in the "REQUEST-STATUS" property. 5368 A CUA MAY send a "SET-LOCALE" command to a CS. The SET-LOCALE 5369 command MUST BE implemented by all CSs. 5371 The CS MUST NOT send a "SET-LOCALE" command to any CUA. 5373 Formal Definition: A "SET-LOCALE" command is defined by the following 5374 notation: 5376 setlocale-cmd = setlocaleparam ":" "SET-LOCALE" 5377 ; 5378 setlocaleparam = *( 5379 ; 5380 ; the following are optional, 5381 ; but MUST NOT occur more than once 5382 ; 5383 id-param 5384 / localize-param 5385 / latency-param 5386 / setlocale-option 5387 ; 5388 ; the following MUST occur exactly once and only 5389 ; when the latency-param has been supplied and 5390 ; MUST NOT be supplied if the latency-param is 5391 ; not supplied. 5392 ; 5393 / action-param 5394 ; 5395 ; the following is optional, 5396 ; and MAY occur more than once 5397 ; 5398 / other-params ) 5400 setlocale-option = option-param newlocale 5401 ; 5402 newlocale = ; Any locale supplied in the initial [BEEP] 5403 ; "greeting" "localize" parameter and 5404 ; and any charset supported by the CS 5405 ; and listed in the DEFAULT-CHARSET property 5406 ; of the VCALSTORE. 5408 Examples: 5410 CMD:OPTIONS=en_US.UTF-8:SET-LOCALE 5411 CMD:OPTIONS=th_TH.ISO8859-11:SET-LOCALE 5412 CMD:OPTIONS=es_MX.ISO8859-1:SET-LOCALE 5414 Restriction Table for the "REPLY" command of any "SET-LOCALE" 5415 command. 5417 setlocale-reply = "BEGIN" ":" "VCALENDAR" CRLF 5418 calprops 5419 1*(setlocale-vreply) 5420 "END" ":" "VCALENDAR" CRLF 5422 setlocale-vreply = "BEGIN" ":" "VREPLY" CRLF 5423 rstatus 5424 "END" ":" "VREPLY" CRLF 5426 10.14 TIMEOUT Command 5428 CMD: TIMEOUT 5430 Purpose: The "TIMEOUT" command is only sent after a command has been 5431 sent with a latency value set. When received it means the command 5432 could not be completed in the time allowed. 5434 Formal Definition: A "TIMEOUT" command is defined by the following 5435 notation: 5437 timeout-cmd = timeoutparam ":" "TIMEOUT" 5439 timeoutparam = *( 5440 ; the following are optional, 5441 ; but MUST NOT occur more than once 5442 id-param 5443 / localize-param 5444 / other-params 5445 ) 5447 10.15 Response Codes 5449 Numeric response codes are returned using the "REQUEST-STATUS" 5450 property. 5452 The format of these codes is described in [iCAL], and extend in 5453 [iTIP] and [iMIP]. The following describes new codes added to this 5454 set and how existing codes apply to CAP. 5456 At the application layer response codes are returned as the value of 5457 a "REQUEST-STATUS" property. The value type of this property is 5458 modified from that defined in [iCAL], in order to make the 5459 accompanying "REQUEST-STATUS" property text optional. 5461 Code Description 5462 -------------------------------------------------------------- 5463 2.0 Success. The parameters vary with the 5464 operation and are specified. 5466 2.0.3 In response to the client issuing an 5467 "abort" reply, this reply code indicates 5468 that any command currently underway was 5469 successfully aborted. 5471 3.1.4 Capability not supported. 5473 4.1 Calendar store access denied. 5475 6.1 Container not found. 5477 6.2 Attempt to create or modify an object 5478 such that it would overlap another object 5479 in either of the following two circumstances: 5481 (a) One of the objects has a TRANSP 5482 property set to OPAQUE-NOCONFLICT or 5483 TRANSPARENT-NOCONFLICT. 5485 (b) The calendar's ALLOW-CONFLICT 5486 property is set to FALSE. 5488 6.3 Bad args. 5490 6.4 Permission denied - VCAR restriction. 5491 A VCAR exists and the CS will not perform 5492 the operation. 5494 7.0 A timeout has occurred. The server was 5495 unable to complete the operation in the 5496 requested time. 5498 8.0 A failure has occurred in the CS 5499 that prevents the operation from 5500 succeeding. 5502 8.1 A query was performed and the query is 5503 too complex for the CS. The operation 5504 was not performed. 5506 8.2 Used to signal that an iCalendar object has 5507 exceeded the server's size limit 5509 8.3 A DATETIME value was too far in the future 5510 represented on this Calendar. 5512 8.4 A DATETIME value was too far in the past 5513 to be represented on this Calendar. 5515 8.5 An attempt was made to create a new 5516 object but the unique UID specified is 5517 already in use. 5519 9.0 An unrecognized command was received. 5520 Or an unsupported command was received. 5522 10.4 The operation has not been performed 5523 because it would cause the resources 5524 (memory, disk, CPU, etc) to exceed the 5525 allocated quota. 5527 -------------------------------------------------------------- 5529 11. Object Registration 5531 This section provides the process for registration of new or modified 5532 properties, parameters, commands, or other modifications, additions, 5533 or deletions to objects. 5535 11.1 Registration of New and Modified Entities 5537 New objects are registered by the publication of an IETF Request for 5538 Comment (RFC). Changes to a objects are registered by the 5539 publication of a revision to the RFC in a new RFC. 5541 11.2 Post the item definition 5543 The object description MUST BE posted to the new object discussion 5544 list: ietf-calendar@imc.org. 5546 11.3 Allow a comment period 5548 Discussion on a new object MUST BE allowed to take place on the list 5549 for a minimum of two weeks. Consensus MUST BE reached on the object 5550 before proceeding to the next step. 5552 11.4 Release a new RFC 5554 The new object will be submitted for publication as any other 5555 internet draft requesting RFC status. 5557 12. BEEP and CAP 5559 12.1 BEEP Profile Registration 5561 Beep replies will be one to one (1:1 MSG/RPY) if possible and one to 5562 many (1:many MSG/ANS) when the "TARGET" property value changes. No 5563 more than one "TARGET" property value per reply. 5565 Profile Identification: specify a [URI] that authoritatively 5566 identifies this profile. 5568 http://iana.org/beep/cap/1.0 5570 Message Exchanged during Channel Creation: 5572 CUAs SHOULD supply the BEEP "localize" attributes in the BEEP 5573 "greeting" messages. 5575 CSs SHOULD supply the BEEP "localize" attributes in the BEEP 5576 "greeting" messages. 5578 CUAs SHOULD supply the BEEP "serverName" attribute at channel 5579 creation time to the CS so that if the CS is performing virtual 5580 hosting the CS can determine the intended virtual host. CSs that do 5581 not support virtual hosting may ignore the BEEP "serverName" 5582 attribute. 5584 Messages starting one-to-one exchanges: 5586 The initial message after authentication each direction MUST BE 5587 single "text/calendar" object containing a CAP "CAPABILITY" CMD and 5588 must not be part of a MIME multipart message. 5590 After the initial message then a BEEP "MSG" may contain one or more 5591 MIME objects at least one of which MUST be "text/calendar" and each 5592 "text/calendar" MIME object MUST contain a CAP "CMD" property. 5594 Multiple iCal objects may be sent in a single BEEP message by either 5595 representing them as separate MIME text/calendar parts contained 5596 within a MIME multipart/mixed part or by simple concatenation within 5597 a single text/calendar MIME object. 5599 In either case, all iCal objects transmitted together must have the 5600 same TARGET property. 5602 The sending of multipart MIME entities over BEEP is not permitted for 5603 CAP unless the other endpoint has indicated its ability to accept 5604 them via the appropriate CAPABILITY. 5606 Messages in positive replies: 5608 After the initial message then a BEEP "RPY" may contain one or more 5609 MIME objects at least one of which MUST be "text/calendar" and each 5610 "text/calendar" MIME object MUST contain a CAP "CMD" property. All 5611 "text/calendar" MIME objects in a single BEEP "RPY" messages MUST 5612 have the same "TARGET" property value. 5614 Multiple iCal objects may be sent in a single BEEP message by either 5615 representing them as separate MIME text/calendar parts contained 5616 within a MIME multipart/mixed part or by simple concatenation within 5617 a single text/calendar MIME object. 5619 In either case, all iCal objects transmitted together must have the 5620 same TARGET property. 5622 The sending of multipart MIME entities over BEEP is not permitted for 5623 CAP unless the other endpoint has indicated its ability to accept 5624 them via the appropriate CAPABILITY. 5626 Messages in negative replies: 5628 Any valid "text/calendar" MIME object that contains CAP "REQUEST- 5629 STATUS" property and a CAP "CMD" property with a property value of 5630 "REPLY". And where the CS has determined the requested operation to 5631 be a fatal error. And when the CS has performed NO operation that 5632 effected the contents of any part of the CS or any calendar 5633 controlled by the CS. 5635 Messages in one-to-many exchanges: 5637 After the initial message then a BEEP "MSG" may contain one or more 5638 MIME objects at least one of which MUST be "text/calendar" and each 5639 "text/calendar" MIME object MUST contain a CAP "CMD" property. 5641 The BEEP "MSG" messages can only contain MIME "multipart" MIME 5642 objects if the other endpoint has received a CAP "CAPABILITY" 5643 indicating the other endpoint supports multipart MIME objects. This 5644 does not prevent the endpoint from sending multiple [iCAL] 5645 'icalobject' objects in a single BEEP "MSG" so long as all of them 5646 have the same "TARGET" property value. 5648 Multiple iCal objects may be sent in a single BEEP message by either 5649 representing them as separate MIME text/calendar parts contained 5650 within a MIME multipart/mixed part or by simple concatenation within 5651 a single text/calendar MIME object. 5653 In either case, all iCal objects transmitted together must have the 5654 same TARGET property. 5656 The sending of multipart MIME entities over BEEP is not permitted for 5657 CAP unless the other endpoint has indicated its ability to accept 5658 them via the appropriate CAPABILITY. 5660 Message Syntax: 5662 They are CAP "text/calendar" MIME objects as specified in this memo. 5664 Message Semantics: 5666 As defined in this memo. 5668 12.2 BEEP Exchange Styles 5670 [BEEP] defines three styles of message exchange: 5672 MSG/ANS,ANS,...,NUL - For one to many exchanges. 5674 MSG/RPY - For one to one exchanges. 5676 MSG/ERR - For requests the cannot be processed due to an error. 5678 A CAP request targeted at more than one containers, MAY use a one- 5679 to-many exchange, with a distinct answer associated with each target. 5680 CAP request targeted at a single container MAY use a one-to-one 5681 exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when 5682 an error condition prevents the execution of the request on all the 5683 targeted calendars. 5685 12.3 BEEP connection details 5687 All CAP communications must be done securelsecurely. So the initial 5688 greeting includes the TLS profile. 5690 L: 5692 I: 5694 L: RPY 0 0 . 0 110 5695 L: Content-Type: application/beep+xml 5696 L: 5697 L: 5698 L: 5699 L: 5700 L: END 5702 I: RPY 0 0 . 0 52 5703 I: Content-Type: application/beep+xml 5704 I: 5705 I: 5706 I: END 5708 At this point the connection is secure. The TLS profile 'resets' the 5709 connection, so it resends the greetings. And advertise the CAP 5710 profiles supported. And reply with the profile selected (only one 5711 profile exists at this time): 5713 L: 5715 I: 5717 L: RPY 0 0 . 0 110 5718 L: Content-Type: application/beep+xml 5719 L: 5720 L: 5721 L: 5722 L: 5723 L: END 5725 I: RPY 0 0 . 0 110 5726 I: Content-Type: application/beep+xml 5727 I: 5728 I: 5729 I: 5730 I: 5731 I: END 5733 Then each channel must be authenticated before work can start. Now 5734 starting a channel involves authentication. Any SASL profile may be 5735 included such as these: 5737 5738 5739 5741 Example of anonymous channel: 5743 C: 5744 C: 5745 C: 5747 S: RPY 0 1 . 221 87 5748 S: Content-Type: application/beep+xml 5749 S: 5750 S: 5752 S: END 5754 Example of DIGEST-MD5 channel: 5756 C: 5757 C: 5758 C: 5760 S: RPY 0 1 . 221 87 5761 S: Content-Type: application/beep+xml 5762 S: 5763 S: 5765 S: END 5767 Piggybacking the "CAPABILITY" command. The "CAPABILITY" reply may be 5768 included during channel start (see RFC3080, section 2.3.1.2) as BEEP 5769 allows for the start command to include the initial data transfer. 5770 This reduces the number of round trips to initiate a CAP session. 5772 13. IANA Considerations 5774 This memo defines IANA registered extensions to the attributes 5775 defined by iCalendar, as defined in [iCAL], and [iTIP]. 5777 IANA registration proposals for iCalendar and [iTIP] are to be mailed 5778 to the registration agent for the "text/calendar" [MIME] content- 5779 type, using the format defined in 5780 section 7 of [iCAL]. 5782 If the IESG approves this memo for publication, then the IANA 5783 registers the profile specified in Section 12.1, and selects an IANA- 5784 specific URI, e.g., http://iana.org/beep/cap/1.0. 5786 14. Security Considerations 5788 Access rights should be granted cautiously. Without careful planning 5789 it is possible to open up access to a greater degree than desired. 5791 The "IDENTIFY" command should be carefully implemented. If done 5792 incorrectly UPNs may gain access as other unintended UPSs. The 5793 "IDENTIFY" command may not chain, that is the identity is always 5794 validated against the original UPN and not the new UPN. 5796 In addition, since CAP is a profile of [BEEP], consult [BEEP]'s 5797 Section 9 for a discussion of BEEP-specific security issues. 5799 There are risks of allowing anonymous UPNs to deposit REQUEST and 5800 REFRESH objects. (calendar spam and deninal of service for example) 5801 So implementations should consider methods to restrict anonymous 5802 requests to within acceptable usages. 5804 CS implementations might consider automatically creating VCARs that 5805 allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY 5806 objects for those UIDs if they otherwise do not have access rather 5807 then opening up world access. And they may consider also allowing 5808 COUNTER objects for those ATTENDEEs. 5810 When an object is booked by a CUA the CS reply may wish to include 5811 warning messages to the CUA for ATTENDEEs that have CAP urls that do 5812 not have local UPNs as those ATTENDEES may be unable to REPLY or 5813 REFRESH. Some CSs may wish this to be an error. 5815 Although service provisioning is a policy matter, at a minimum, all 5816 implementations must provide the following tuning profiles: 5818 for authentication: http://iana.org/beep/SASL/DIGEST-MD5 5820 for confidentiality: http://iana.org/beep/TLS (using the 5821 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) 5823 for both: http://iana.org/beep/TLS (using the 5824 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side 5825 certificates) 5827 Authors' Addresses 5829 Doug Royer 5830 IntelliCal, LLC 5831 267 Kentlands Blvd. #3041 5832 Gaithersburg, MD 20878 5833 US 5835 Phone: +1-866-594-8574 5836 Fax: +1-866-594-8574 5837 Email: Doug@IntelliCal.com 5838 URI: http://Royer.com/People/Doug 5840 George Babics 5841 Oracle 5842 2000 Peel Street 5843 Montreal, Quebec H3A 2W5 5844 CA 5846 Phone: +1-514-733-8500 x4201 5847 Fax: +1-514-733-8878 5848 Email: George.Babics@Oracle.com 5850 Paul Hill 5851 Massachusetts Institute of Technology 5852 W92-172 5853 77 Massachusetts Avenue 5854 Cambridge, MA 02139 5855 US 5857 Phone: +1-617-253-0124 5858 Fax: +1-617-258-8736 5859 Email: phb@mit.edu 5861 Steve Mansour 5862 AOL/Netscape 5863 466 Ellis Road 5864 Mountain View, CA 94043 5865 US 5867 Phone: +1-650-937-3351 5868 Email: sman@netscape.com 5870 Appendix A. Acknowledgments 5872 The following have individuals were major contributors in the 5873 drafting and discussion of this memo and are greatly appreciated: 5875 Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil 5876 Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag, 5877 Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan, 5878 Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt 5879 Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan 5880 Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol, 5881 David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank 5882 Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin, 5883 Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand, 5884 Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray, 5885 Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke, 5886 Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees 5887 Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence 5888 Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark 5889 Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle, 5890 Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max 5891 Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike 5892 Hixson, Murata Makoto, Natalia Syracuse, Nathaniel Borenstein, Ned 5893 Freed, Olivier Gutknecht, Patrice Lapierre, Patrice Scattolin, Paul 5894 Hoffman, Paul Sharpe, Payod Deshpande, Pekka Pessi, Peter Thompson, 5895 Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson, 5896 Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana 5897 Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon 5898 Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller, 5899 Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim 5900 Hare, Timo Sirainen, Vicky Oliver, Yael Shaham-Gafni 5902 Appendix B. Bibliography 5904 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF" 5905 RFC 2234, November 1997 5906 ftp://ftp.isi.edu/in-notes/rfc2234.txt 5908 [BEEP] Rose, M., "The Block Extensible Exchange Protocol Core", 5909 RFC 3080, March 2001 5910 ftp://ftp.isi.edu/in-notes/rfc3080.txt 5912 [BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001 5913 ftp://ftp.isi.edu/in-notes/rfc3081.txt 5915 [BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596-00244-0, 5916 O'Reilly & Associates, Inc. 5918 [CHARREG] Freed, N., Postel, J., "IANA Charset Registration Procedures", 5919 RFC 2278, January 1998, 5920 ftp://ftp.isi.edu/in-notes/rfc2278.txt 5922 [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages", 5923 RFC 2277, January 1998, 5924 ftp://ftp.isi.edu/in-notes/rfc2277.txt 5926 [GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet 5927 Calendaring", RFC 3283, June 2002, 5928 ftp://ftp.isi.edu/in-notes/rfc3283.txt 5930 [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and 5931 Scheduling Core Object Specification (iCalendar)", RFC 2445, 5932 November 1998 ftp://ftp.isi.edu/in-notes/rfc2445.txt 5934 [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., 5935 "iCalendar Transport-Independent Interoperability Protocol 5936 (iTIP) Events, BusyTime, To-dos and Journal Entries", 5937 RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc2446.txt 5939 [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar 5940 Message-Based Interoperability Protocol (iMIP)", RFC 2447, 5941 November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt 5943 [MIME] Borenstein, N. and Freed, N., "Multipurpose Internet Mail 5944 Extensions (MIME) Part One: Format of Internet Message Bodies", 5945 RFC 2045, November 1996 5946 ftp://ftp.isi.edu/in-notes/rfc2045.txt 5948 [RFCWORDS] Bradner, S., "Key words for use in RFCs to Indicate 5949 Requirement Levels", RFC 2119, BCP 14, March 1997 5950 ftp://ftp.isi.edu/in-notes/rfc2119.txt 5952 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 5953 RFC 2222, October 1997 5954 ftp://ftp.isi.edu/in-notes/rfc2222.txt 5956 [SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, 5957 aka ANSI X3.135-1992, aka FiPS PUB 127-2 5959 [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 5960 to ISO/IEC 9075: 1992, also adopted as Amendment 1 to 5961 ANSI X3.135.1992 5963 [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., 5964 "Guidelines for new URL Schemes", RFC 2718, November 1999, 5965 ftp://ftp.isi.edu/in-notes/rfc2718.txt 5967 [URI] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform Resource 5968 Identifiers (URI): Generic Syntax", RFC 2396, August 1998 5969 ftp://ftp.isi.edu/in-notes/rfc2396.txt 5971 [URL] Berners-Lee, T, Masinter, L. and McCahil, M., "Uniform 5972 Resource Locators (URL)", RFC 1738, December 1994 5973 ftp://ftp.isi.edu/in-notes/rfc1738.txt 5975 [X509CRL] Housley, R., Ford, W., Polk, W., Solo, D. "Internet X.509 5976 Public Key Infrastructure, Certificate and CRL Profile", 5977 RFC 2459, January 1999, 5978 ftp://ftp.isi.edu/in-notes/rfc2459.txt 5980 Intellectual Property Statement 5982 The IETF takes no position regarding the validity or scope of any 5983 Intellectual Property Rights or other rights that might be claimed to 5984 pertain to the implementation or use of the technology described in 5985 this document or the extent to which any license under such rights 5986 might or might not be available; nor does it represent that it has 5987 made any independent effort to identify any such rights. Information 5988 on the procedures with respect to rights in RFC documents can be 5989 found in BCP 78 and BCP 79. 5991 Copies of IPR disclosures made to the IETF Secretariat and any 5992 assurances of licenses to be made available, or the result of an 5993 attempt made to obtain a general license or permission for the use of 5994 such proprietary rights by implementers or users of this 5995 specification can be obtained from the IETF on-line IPR repository at 5996 http://www.ietf.org/ipr. 5998 The IETF invites any interested party to bring to its attention any 5999 copyrights, patents or patent applications, or other proprietary 6000 rights that may cover technology that may be required to implement 6001 this standard. Please address the information to the IETF at 6002 ietf-ipr@ietf.org. 6004 Disclaimer of Validity 6006 This document and the information contained herein are provided on an 6007 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6008 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 6009 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 6010 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 6011 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6012 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6014 Copyright Statement 6016 Copyright (C) The Internet Society (2005). This document is subject 6017 to the rights, licenses and restrictions contained in BCP 78, and 6018 except as set forth therein, the authors retain all their rights. 6020 Acknowledgment 6022 Funding for the RFC Editor function is currently provided by the 6023 Internet Society.