idnits 2.17.1 draft-ietf-calsch-cap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 5184 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 6304 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 101 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 681 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 2464 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2445]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 384: '...example, "events MUST be scheduled in ...' RFC 2119 keyword, line 521: '...flict, the realm SHOULD be postfixed w...' RFC 2119 keyword, line 571: '...ess. A CU's UPN MUST never be deliver...' RFC 2119 keyword, line 614: '... CS1 MAY play the role of a CUA a...' RFC 2119 keyword, line 616: '... CS1 MAY be able to play the role...' (69 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 693 has weird spacing: '...command whose...' == Line 729 has weird spacing: '...r entry to on...' == Line 733 has weird spacing: '...chedule a ca...' == Line 738 has weird spacing: '...stances to a...' == Line 741 has weird spacing: '... Cancel one ...' == (96 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 'SHOULD not' in this paragraph: The CS SHOULD not preserve UG expansions across operations. A UG may reference a static list of members, or it may represent a dynamic list. Each operation SHOULD generate its own expansion in order to recognize changes to UG membership. However, during fan out to other CSs, the originating CS SHOULD expand all UGs so that the target CS receives only a list of unique CUs. This is to prevent confusion when two CSs do not share the same UG database or directory. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Subsequent to the initial Anonymous Authentication with a CS, a CUA will have to provide a UPN for some CAP operations. For anonymous access the UPN that MUST be used by the CUA is "@", a UPN with a null username and null realm. The user's normal UPN MUST not be used for the subsequent CAP operations. == 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: When supporting virtual hosts, there could be more than one row in the CALSTORE table. And then the CSID MUST not be empty. -- 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 (March 10, 2000) is 8812 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? 'RFC2445' on line 5098 looks like a reference -- Missing reference section? 'RFC2119' on line 267 looks like a reference -- Missing reference section? 'RFC2446' on line 5101 looks like a reference -- Missing reference section? 'RFC2447' on line 5104 looks like a reference -- Missing reference section? 'RFC2396' on line 5095 looks like a reference -- Missing reference section? 'TLS' on line 5087 looks like a reference -- Missing reference section? 'RFC2222' on line 844 looks like a reference -- Missing reference section? 'RFC 2246' on line 953 looks like a reference -- Missing reference section? 'CAP' on line 3927 looks like a reference -- Missing reference section? 'SQL' on line 5107 looks like a reference -- Missing reference section? 'SASL' on line 1688 looks like a reference -- Missing reference section? 'VQUERY' on line 2346 looks like a reference -- Missing reference section? 'SQLCOM' on line 5112 looks like a reference -- Missing reference section? 'RFC2426' on line 5063 looks like a reference -- Missing reference section? 'RFC1521' on line 5082 looks like a reference -- Missing reference section? 'RFC2608' on line 5089 looks like a reference -- Missing reference section? 'RFC2609' on line 5092 looks like a reference -- Missing reference section? 'UNICODE' on line 5115 looks like a reference -- Missing reference section? 'US-ASCII' on line 5119 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft CAP March 10, 2000 4 Network Working Group Steve Mansour/Netscape 5 Internet Draft Frank Dawson/Lotus 6 Doug Royer/Software.com 7 Alexander Taler/CS&T 8 Paul Hill/MIT 9 Expires six months from: March 10, 2000 11 Calendar Access Protocol (CAP) 13 Status of this Memo 15 This memo is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt . 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this document is unlimited. 34 Copyright Statement 36 Copyright (C) The Internet Society 2000. All Rights Reserved. 38 Abstract 40 The Calendar Access Protocol (CAP) is an Internet protocol that 41 permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to 42 access an [RFC2445] based Calendar Store (CS). This memo defines the 43 CAP specification. 45 The CAP definition is based on requirements identified by the Internet 46 Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) 47 Working Group. More information about the IETF CALSCH Working Group 48 activities can be found on the IMC web site at 49 http://www.imc.org/ietf-calendar, and at the IETF web site at 51 Mansour/Dawson/Royer/Taler/Hill 1 Expires September 2000 52 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the 53 references within this memo for further information on how to access 54 these various documents. 56 Mansour/Dawson/Royer/Taler/Hill 2 Expires September 2000 57 Table of Contents 58 1. Introduction ................................................... 3 59 1.1. Formatting Conventions ....................................... 3 60 1.2. Related Documents ............................................ 3 61 1.3. Definitions .................................................. 4 62 2. CAP Design ..................................................... 10 63 2.1. System Model ................................................. 10 64 2.2. Calendar Store Object Model .................................. 11 65 2.3. Protocol Model ............................................... 11 66 2.4. Security Model ............................................... 13 67 2.4.1. Authentication, Credentials, and Identity .................. 14 68 2.4.2. Calendar User and UPNs ..................................... 14 69 2.4.2.1. UPNs and Certificates .................................... 15 70 2.4.2.2. Anonymous Users and Authentication ....................... 16 71 2.4.2.3. Required Security Mechanisms ............................. 16 72 2.4.2.4. TLS Ciphersuites ......................................... 17 73 2.4.3. User Groups ................................................ 17 74 2.4.4. Access Rights .............................................. 18 75 2.4.4.1. VCalendar Access Right (VCAR) ........................... 18 76 2.4.4.2. Decreed VCARs ............................................ 19 77 2.4.4.3. Inheritance .............................................. 19 78 2.4.5. CAP session identity ....................................... 19 79 2.5. Roles ........................................................ 20 80 2.6. Calendar Addresses ........................................... 21 81 2.7. Extensions to iCalendar ...................................... 21 82 2.8. Relationship of RFC 2446 (ITIP) to CAP ....................... 22 83 2.9. VCalendar Access Rights (VCARs) .............................. 23 84 2.10. Query Schema ................................................ 23 85 3. State Diagram .................................................. 23 86 4. Protocol Framework ............................................. 25 87 4.1. CAP Application Layer ........................................ 25 88 4.2. CAP Transfer Protocol ........................................ 25 89 4.3. Response Format .............................................. 25 90 4.4. Auto-logout Timer ............................................ 26 91 4.5. Bounded Latency .............................................. 26 92 4.6. Data Elements ................................................ 27 93 5. Formal Command Syntax .......................................... 27 94 5.1. Searching and Filtering ...................................... 27 95 5.1.1. Grammar For Search Mechanism ............................... 27 96 6. Access Rights .................................................. 28 97 6.1. VCAR Inheritance ............................................. 28 98 6.2. Access Control and NOCONFLICT ................................ 28 99 7. Commands and Responses ......................................... 29 100 7.1. Transfer Protocol Commands ................................... 29 101 7.1.1. Initial Connection ......................................... 29 102 7.1.2. ABORT Command .............................................. 30 103 7.1.3. AUTHENTICATE Command ....................................... 30 104 7.1.3.1. AUTHENTICATE ANONYMOUS ................................... 33 105 7.1.4. CALIDEXPAND Command ........................................ 34 106 7.1.5. CAPABILITY Command ......................................... 35 107 7.1.6. CONTINUE Command ........................................... 36 108 7.1.7. DISCONNECT Command ......................................... 37 109 7.1.8. IDENTIFY Command ........................................... 38 111 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 112 7.1.9. SENDDATA Command ........................................... 38 113 7.1.10. STARTTLS Command .......................................... 38 114 7.1.10.1. UPNEXPAND Method ........................................ 39 115 7.2. Application Protocol Commands ................................ 40 116 7.2.1. Calendaring Commands ....................................... 40 117 7.2.1.1. CREATE Method ............................................ 40 118 7.2.1.1.1. Creating New Calendars ................................. 41 119 7.2.1.2. DELETE Method ............................................ 43 120 7.2.1.3. GENERATEUID Method ....................................... 44 121 7.2.1.4. MODIFY Method ............................................ 44 122 7.2.1.5. MOVE Method .............................................. 45 123 7.2.1.6. NOOP Method .............................................. 46 124 7.2.1.7. READ Method .............................................. 46 125 7.2.2. Scheduling Commands ........................................ 50 126 7.2.2.1. Reading out scheduling components ........................ 50 127 7.2.2.2. PUBLISH .................................................. 51 128 7.2.2.3. REQUEST .................................................. 52 129 7.2.2.4. REPLY .................................................... 52 130 7.2.2.5. ADD ...................................................... 52 131 7.2.2.6. CANCEL ................................................... 52 132 7.2.2.7. REFRESH .................................................. 52 133 7.2.2.8. COUNTER .................................................. 52 134 7.2.2.9. DECLINECOUNTER ........................................... 52 135 7.2.3. iTIP Examples .............................................. 52 136 7.2.3.1. Sending and Receiving an iTIP request .................... 52 137 7.2.3.2. Handling an iTIP refresh ................................. 55 138 7.2.3.3. Sending and accepting an iTIP counter .................... 56 139 7.2.3.4. Declining an iTIP counter ................................ 57 140 8. Response Codes ................................................. 58 141 8.1. Minimum CS query implementation .............................. 60 142 8.1.1. Query by UID ............................................... 60 143 8.1.2. Query by Date / Date-Time range ............................ 60 144 8.1.2.1. Date/Date-Time query with subset of properties ........... 60 145 8.1.3. ...................................................... 60 146 9. Detailed SQL Schema ............................................ 60 147 9.1. iCalendar Store Schema ....................................... 62 148 9.1.1. ACTION schema .............................................. 62 149 9.1.2. ATTACH schema .............................................. 63 150 9.1.3. ATTENDEE schema ............................................ 63 151 9.1.4. CALSTORE schema ............................................ 63 152 9.1.5. CHILDREN schema ............................................ 64 153 9.1.6. CLASS schema ............................................... 64 154 9.1.7. CN schema .................................................. 64 155 9.1.8. COMMENT schema ............................................. 64 156 9.1.9. CONTACT schema ............................................. 64 157 9.1.10. CREATED schema ............................................ 65 158 9.1.11. CUTYPE schema ............................................. 65 159 9.1.12. DAYLIGHT_STANDARD schema .................................. 65 160 9.1.13. DESCRIPTION schema ........................................ 65 161 9.1.14. DIR schema ................................................ 66 162 9.1.15. DTEND schema .............................................. 66 163 9.1.16. DTSTAMP schema ............................................ 66 164 9.1.17. DUE schema ................................................ 66 166 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 167 9.1.18. DURATION schema ........................................... 67 168 9.1.19. EXDATE schema ............................................. 67 169 9.1.20. EXRULE schema ............................................. 67 170 9.1.21. FBTYPE schema ............................................. 67 171 9.1.22. FMTTYPE schema ............................................ 67 172 9.1.23. FREEBUSY schema ........................................... 68 173 9.1.24. GEO schema ................................................ 68 174 9.1.25. LANGUAGE schema ........................................... 68 175 9.1.26. LAST_MODIFIED schema ...................................... 68 176 9.1.27. MEMBER schema ............................................. 68 177 9.1.28. METHOD schema ............................................. 69 178 9.1.29. ORGANIZER schema .......................................... 69 179 9.1.30. OWNERS schema ............................................. 69 180 9.1.31. PARTSTAT schema ........................................... 69 181 9.1.32. PERCENT_COMPLETE schema ................................... 70 182 9.1.33. PRIORITY schema ........................................... 70 183 9.1.34. RDATE schema .............................................. 70 184 9.1.35. RECUR schema .............................................. 70 185 9.1.36. RECURRENCE_ID schema ...................................... 71 186 9.1.37. RELATED_TO schema ......................................... 72 187 9.1.38. REPEAT schema ............................................. 72 188 9.1.39. RESOURCES schema .......................................... 72 189 9.1.40. ROLE schema ............................................... 72 190 9.1.41. RRULE schema .............................................. 73 191 9.1.42. SEQUENCE schema ........................................... 73 192 9.1.43. STATUS schema ............................................. 73 193 9.1.44. SUMMARY schema ............................................ 73 194 9.1.45. TRANSP schema ............................................. 73 195 9.1.46. TRIGGER schema ............................................ 74 196 9.1.47. TZID schema ............................................... 74 197 9.1.48. UID schema ................................................ 74 198 9.1.49. URL schema ................................................ 74 199 9.1.50. VALARM schema ............................................. 75 200 9.1.51. VCALENDAR schema .......................................... 75 201 9.1.52. VCAR schema ............................................... 75 202 9.1.53. VEVENT schema ............................................. 75 203 9.1.54. VFREEBUSY schema .......................................... 76 204 9.1.55. VJOURNAL schema ........................................... 77 205 9.1.56. VQUERY schema ............................................. 77 206 9.1.57. VTIMEZONE schema .......................................... 78 207 9.1.58. VTODO schema .............................................. 78 208 9.1.59. X_PROP schema ............................................. 79 209 9.1.60. XPARAM schema ............................................. 79 210 9.2. Query example ................................................ 79 211 10. Examples ...................................................... 79 212 10.1. Authentication Examples ..................................... 79 213 10.1.1. Login Using Kerberos V4 ................................... 79 214 10.1.2. Error Scenarios ........................................... 80 215 10.2. Read Examples ............................................... 81 216 10.2.1. Read From A Single Calendar ............................... 81 217 10.2.2. Read From Multiple Calendars .............................. 82 218 10.2.3. Timeouts .................................................. 83 219 10.2.4. Using the Calendar Parent, Children Properties ............ 84 221 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 222 10.2.5. An example that depends on VEVENT.DTSTART and VALARM.DT- 223 START ........................................................ 84 224 11. Implementation Issues ......................................... 84 225 12. Properties .................................................... 84 226 12.1. Calendar Store Properties ................................... 84 227 12.2. Calendar Properties ......................................... 85 228 13. Security Considerations ....................................... 87 229 14. Changes to iCalendar .......................................... 87 230 14.1. Time Transparency ........................................... 88 231 14.2. RIGHTS Value Type ........................................... 89 232 14.3. VCAR Calendar Component ..................................... 92 233 14.4. GRANT Component Property .................................... 94 234 14.5. DENY Component Property ..................................... 94 235 14.6. VCAR Identifier Component Property .......................... 95 236 15. CAP Entities Registration ..................................... 96 237 15.1.1. Define the Entity ......................................... 97 238 15.1.2. Post the entity definition ................................ 98 239 15.1.3. Allow a comment period .................................... 98 240 15.1.4. Submit the entity for approval ............................ 98 241 15.2. Property Change Control ..................................... 98 242 16. IANA Considerations ........................................... 99 243 17. Acknowledgments ............................................... 99 244 18. Bibliography .................................................. 99 245 19. Author's Address .............................................. 100 246 20. Full Copyright Statement ...................................... 101 248 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 249 1. Introduction 251 This document specifies how a Calendar User Agent (CUA) interacts with a 252 Calendar Store (CS) to manage calendar information. In particular, it 253 specifies how to query, create, modify, and delete iCalendar components 254 (e.g., events, to-dos, or daily journal entries). It further specifies 255 how to search for available busy time information. 257 This protocol is based on request/response form of protocol data units, 258 sent from a client CUA to a calendar server. The protocol data units 259 leverage the standard iCalendar format [RFC2445] for conveying CS 260 related information. 262 1.1. Formatting Conventions 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 266 document are to be interpreted as described in [RFC2119]. 268 Calendaring and scheduling roles are referred to in quoted-strings of 269 text with the first character of each word in upper case. For example, 270 "Organizer" refers to a role of a "Calendar User" (CU) within the 271 protocol defined by this memo. Calendar components defined by [RFC2445] 272 are referred to with capitalized, quoted-strings of text. All calendar 273 components start with the letter "V". For example, "VEVENT" refers to 274 the event calendar component, "VTODO" refers to the to-do calendar 275 component and "VJOURNAL" refers to the daily journal calendar component. 276 Calendar access methods defined by this memo, as well as scheduling 277 methods defined by [RFC2446], are referred to with capitalized, quoted- 278 strings of text. For example, "CREATE" refers to the method for creating 279 a calendar component on a calendar, "READ" refers to the method for 280 reading calendar components. 282 Properties defined by this memo are referred to with capitalized, 283 quoted-strings of text, followed by the word "property". For example, 284 "ATTENDEE" property refers to the iCalendar property used to convey the 285 calendar address of a "Calendar User". Property parameters defined by 286 this memo are referred to with lower case, quoted-strings of text, 287 followed by the word "parameter". For example, "value" parameter refers 288 to the iCalendar property parameter used to override the default data 289 type for a property value. Enumerated values defined by this memo are 290 referred to with capitalized text, either alone or followed by the word 291 "value". 293 In tables, the quoted-string text is specified without quotes in order 294 to minimize the table length. 296 1.2. Related Documents 298 Implementers will need to be familiar with several other memos that, 299 along with this one, describe the Internet calendaring and scheduling 301 Mansour/Dawson/Royer/Taler/Hill 3 Expires September 2000 302 standards. This document, 304 [RFC2445] specifies the objects, data types, properties and property 305 parameters used in the protocols, along with the methods for 306 representing and encoding them; 308 [RFC2446] specifies an interoperability protocol for scheduling between 309 different implementations. The related documents are: 311 [RFC2447] specifies an Internet email binding for [RFC2446]. 313 [iRIP] specifies a real-time binding for [RFC2446]. 315 This memo does not attempt to repeat the specification of concepts or 316 definitions from these other memos. Where possible, references are made 317 to the memo that provides for the specification of these concepts or 318 definitions. 320 1.3. Definitions 322 Authentication ID (AuthID) 324 A tuple of username, realm, and authentication method, used by the 325 Calendar Service internally to identify a successfully authenticated 326 CAP session. 328 Calendar 330 A collection of logically related objects or entities each of which 331 may be associated with a calendar date and possibly time of day. These 332 entities can include other calendar properties or calendar components. 333 In addition, a calendar might be hierarchically related to other sub- 334 calendars. A calendar is identified by its unique calendar identifier. 335 The [RFC2445] defines calendar properties, calendar components and 336 component properties that make up the content of a calendar. 338 Calendar Access Protocol (CAP) 340 The standard Internet protocol that permits a Calendar User Agent to 341 access and manipulate a calendar residing on a Calendar Store. 343 Calendar Access Rights (CAR) 345 The mechanism for specifying the CAP operations ("ACTIONS") that a 346 particular calendar user ("UPN") are granted or denied permission to 347 perform on a given calendar entity ("OBJECT"). The calendar access 348 rights are specified with the "VCAR" calendar components within a CS 349 and calendar. 351 Mansour/Dawson/Royer/Taler/Hill 4 Expires September 2000 352 Calendar Collection 354 A collection of Calendars, Resource Calendars, and/or other Calendar 355 Collections. These collections are expanded by the CS and may reside 356 either locally or in an external database or directory. The calendars 357 in the collection may be fixed or dynamic over time. 359 Calendar Component 361 An entity within a calendar. Some types of calendar components include 362 events, to-dos, journals, alarms, time zones and freebusy data. A 363 calendar component consists of component properties and possibly other 364 sub-components. For example, an event may contain an alarm component. 366 Calendar Component Properties 368 An attribute of a particular calendar component. Some calendar 369 component properties are applicable to different types of calendar 370 components. For example, DTSTART is applicable to VEVENT, VTODO, 371 VJOURNAL calendar components. Other calendar components are applicable 372 only to an individual type of calendar component. For example, TZURL 373 is only applicable to VTIMEZONE calendar components. 375 Calendar Identifier (CalID) 377 A globally unique identifier associated with a calendar. Calendars 378 reside within a CS. See Qualified Calendar Identifier and Relative 379 Calendar Identifier. 381 Calendar Policy 383 A CAP operational restriction on the access or manipulation of a 384 calendar. For example, "events MUST be scheduled in unit intervals of 385 one hour". 387 Calendar Properties 389 An attribute of a calendar. The attribute applies to the calendar, as 390 a whole. For example, CALSCALE specifies the calendar scale (e.g., 391 GREGORIAN) for the whole calendar. 393 Calendar Service 395 An implementation of a Calendar Store that manages one or more 396 calendars. 398 Mansour/Dawson/Royer/Taler/Hill 5 Expires September 2000 399 Calendar Store (CS) 401 The data and service model definition for a Calendar Service. 403 Calendar Store Identifier (CSID) 405 The globally unique identifier for an individual CS. A CSID consists 406 of the host and port portions of a "Common Internet Scheme Syntax" 407 part of a URL, as defined by [RFC2396]. 409 Calendar Store Components 411 Components maintained in a CS specify a grouping of calendar store- 412 wide information. Calendar store components can be accessed using CAP. 414 Calendar Store Properties 416 Properties maintained in a Calendar Store calendar store-wide 417 information. Calendar store properties can be accessed using CAP. 419 Calendar User (CU) 421 An entity (often biological) that uses a calendaring system. 423 Calendar User Agent (CUA) 425 The CUA is the client application that a CU or UG utilizes to access 426 and manipulate a calendar. 428 Calendaring and Scheduling System 430 The computer sub-system that provides the services for accessing, 431 manipulating calendars and scheduling calendar components. 433 CAP Session 435 An open communication channel between a CAP CUA and a CAP CS. 437 Connected Mode 439 A mobile computing mode where the CUA is directly connected to the CS. 441 Delegate 443 Mansour/Dawson/Royer/Taler/Hill 6 Expires September 2000 444 Is a calendar user (sometimes called the delegatee) who has been 445 assigned participation in a scheduled calendar component (e.g., 446 VEVENT) by one of the attendees in the scheduled calendar component 447 (sometimes called the delegator). An example of a delegate is a team 448 member told to go to a particular meeting. 450 Designate 452 Is a calendar user who is authorized to act on behalf of another 453 calendar user. An example of a designate is an assistant. 455 Disconnected Mode 457 A mobile computing mode where a CUA can be disconnected from a CS. 458 When the CUA is disconnected, it is in the disconnected mode. 460 Fan Out 462 The calendaring and scheduling process by which a calendar operation 463 on one calendar is also performed on every other calendar specified in 464 the operation. This may include the calendar associated with TARGET 465 calendar property. 467 Hierarchical Calendars 469 A CS feature where a calendar have a hierarchical relationship with 470 another calendar in the CS. The top-most calendar in the hierarchical 471 relationship has the CS as its parent. There may be multiple top-most 472 calendars in a given CS. Within a given hierarchical relationship, all 473 sub-calendars have a calendar with a "parent" topographical 474 relationship. In addition, sub-calendars may have a relationship with 475 another calendar that has a "child" topographical relationship. In 476 addition, a calendar may have a relationship such that one or more 477 calendars have a "sibling" topographical relationship with the 478 calendar. The hierarchical calendar feature is not a storage 479 relationship of the calendars within the CS. Instead it is a feature 480 that relates access control rights to calendar content between 481 different calendars in the CS. The hierarchical relationship of a 482 calendar is specified in the "PARENT" and "CHILDREN" calendar 483 properties. 485 High Bandwidth Connection 487 A communications connection supporting high transfer rates; transfer 488 rates commonly found within a LAN. 490 Mansour/Dawson/Royer/Taler/Hill 7 Expires September 2000 491 Local Store 493 A CS which is on the same platform as the CUA. 495 Low Bandwidth Connection 497 A communications connection supporting slow transfer rates; transfer 498 rates commonly found in remote access technology. 500 Overlapped Booking 502 A policy which indicates whether or not OPAQUE events can overlap one 503 another. When the policy is applied to a calendar it indicates whether 504 or not any OPAQUE events in the calendar can overlap. When applied to 505 an individual event, it indicates whether or not it can be overlapped 506 by any other OPAQUE event. 508 Owner 510 One or more CUs or UGs that have "OWNER" calendar access rights for a 511 calendar. The owner is specified in the "OWNER" calendar property. 513 Qualified Calendar Identifier (Qualified CalID) 515 A CalID where both the and are present. 517 Realm 519 A collection of calendar user accounts, identified by a string. The 520 name of the realm is only used in UPNs. In order to avoid namespace 521 conflict, the realm SHOULD be postfixed with an appropriate DNS domain 522 name. (eg: the foobar realm could be called foobar.example.com). 524 Relative Calendar Identifier (Relative CalID) 526 An identifier for an individual calendar in a calendar store. It is 527 unique within a calendar store. It is recommended to be globally 528 unique. A Relative CalID consists of the portion of the "scheme part" 529 of a Qualified CalID following the Calendar Store Identifier. This is 530 the same as the "URL path" of the "Common Internet Scheme Syntax" 531 portion of a URL, as defined by [RFC2396]. 533 Remote Store 535 A CS which is not on the same platform as the CUA. 537 Mansour/Dawson/Royer/Taler/Hill 8 Expires September 2000 538 Resource Calendar (RC) 540 A non-human Calendar, associated with an organizational resource. 541 There is no syntactic difference between an RC and a Calendar. 543 Session Identity 545 A UPN associated with a CAP session. A session gains an identity after 546 successful authentication. The identity is used in combination with 547 CAR to determine access to data in the CS. 549 Sub-calendars 551 Calendars that have a "child" hierarchical relationship with another 552 calendar, its "parent". 554 User Group (UG) 556 A collection of Calendar Users and/or User Groups. These groups are 557 expanded by the CS and may reside either locally or in an external 558 database or directory. The group membership may be fixed or dynamic 559 over time. 561 User Name 563 A name which denotes a Calendar User within a realm. This is part of a 564 UPN. 566 User Principal Name (UPN) 568 An identifier that denotes a unique CU. A UPN is an RFC 822 compliant 569 email address, with exceptions listed below, and in most cases it is 570 deliverable to the CU. In some cases it is identical to the CU's well 571 known email address. A CU's UPN MUST never be deliverable to a 572 different person. It consists of a realm in the form of a valid, and 573 unique, DNS domain name and a unique username. In it's simplest form 574 it looks like "user@example.com". 576 In certain cases a UPN will not be RFC 822 compliant. When anonymous 577 authentication is used, or anonymous authorization is being defined, 578 the special UPN "@" will be used. When authentication must be used, 579 but unique identity must be obscured, a UPN of the form @DNS-domain- 580 name may be used. For example, "@example.com". Usage of these special 581 cases is further discussed in the authentication and authorization 582 sections of this document. 584 Mansour/Dawson/Royer/Taler/Hill 9 Expires September 2000 585 2. CAP Design 587 2.1. System Model 589 The system model describes the high level components of a calendar 590 system and how they interact with each other. 592 CAP is used by a "Calendar User Agent" (CUA) to send commands to and 593 receive responses from a "Calendar Service" (CS). The CUA prepares an 594 MIME encapsulated iCalendar object containing a command, sends it to the 595 CS, and receives an iCalendar object as a response. There are two 596 distinct protocols in operation to accomplish this exchange. The 597 Transfer Protocol is used to move iCalendar objects between a CUA and a 598 CS. The Application Protocol defines the content and semantics of the 599 iCalendar objects sent between the CUA and the CS. This document defines 600 both the Transfer Protocol and the Application Protocol. 602 In the diagram below, a user uses CUA1 to communicate with CS1 using 603 CAP. The CUA must authenticate the Calendar User (CU) so that access to 604 calendars on CS1 can be controlled. The CUA can then view, create, edit, 605 and delete calendars, calendar properties, and calendar components 606 subject to the access rights. 608 CAP servers support fanout. Fanout allows a CUA to communicate with a 609 single CS to perform scheduling operations with calendars on multiple 610 CSs. That is, a Calendar User (CU) can book events on or read events 611 from calendars on other calendar stores. To accomplish this, a CAP 612 server has several options: 614 CS1 MAY play the role of a CUA and use CAP to access CS2; 616 CS1 MAY be able to play the role of a CUA and use [iRIP] to 617 interoperate with the possible iRIP support in CS2; 619 CS1 MUST be able play the role of a CUA and use [RFC2447] to 620 interoperate with other CUAs. 622 Storage Agent 624 +-----+ +-----+ 625 | | CAP | | CAP 626 CUA1 ------| CS1 |-----------| CS2 |--------- CUA2 627 | | | | A 628 | | | | | 629 | | | | | 630 +-----+ +-----+ | 631 | IMIP | 632 +---------------------------------+ 634 Mansour/Dawson/Royer/Taler/Hill 10 Expires September 2000 635 Note that the fanout feature in CAP is a convenience to the CUA. It 636 is perfectly valid for the CUA to assume the responsibility for 637 fanout if it wishes. That is, [RFC2447] messages could also be sent 638 from CUA1 to CUA2. 640 2.2. Calendar Store Object Model 642 The conceptual model for a calendar store is shown below. The calendar 643 store contains calendars, VTIMEZONEs, VCARs, and calendar store 644 properties. 646 Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, and 647 calendar properties. Calendars may also contain other calendars. 649 +---------Calendar Store-----------------------------+ 650 | | 651 | | 652 | VCARs | 653 | +--calendars-------------------------+ | 654 | Properties | | | 655 | | +--calendars--------+ VEVENTs | | 656 | VTIMEZONEs | | | VTODOs | | 657 | | | VEVENTs | VJOURNALs | | 658 | | | VCARs | VALARMs | | 659 | | | +---+ VTODOs | VCARs | | 660 | | | | | VALARMs | Calendar | | 661 | | | +---+ VJOURNALs | Properties | | 662 | | | VTIMEZONEs | VTIMEZONEs | | 663 | | | Calendar | VSCHEDULE | | 664 | | | Properties | | | 665 | | | VSCHEDULE | | | 666 | | +-------------------+ | | 667 | +------------------------------------+ | 668 +----------------------------------------------------+ 670 Calendars within a Calendar Store are identified by their Relative 671 CALID. 673 In this model, VSCHEDULE is a queue of scheduling messages that have not 674 yet been applied to the calendar. Items in VSCHEDULE are discussed in 675 more detail below. 677 2.3. Protocol Model 679 A generic transfer-layer, Calendar Server Transfer Protocol (CSTP), is 680 used to move data objects between a CUA and the CS. CSTP commands are 681 listed below and their usage and semantics are defined in section 7 of 682 this document. 684 Mansour/Dawson/Royer/Taler/Hill 11 Expires September 2000 685 CSTP Commands 686 ------------------------------------------------------------------------- 687 Command Description 688 ------------------------------------------------------------------------- 689 ABORT Stop a command whose latency time has been exceeded. 691 AUTHENTICATE Authenticate a UPN. 693 CONTINUE Continue the execution of a command whose latency 694 time has been exceeded. 696 IDENTIFY Set a new identity for calendar access. 698 DISCONNECT Terminate a connection with the server. 700 SENDDATA Send a data object MIME encapsulated iCalendar. 702 STARTTLS Negotiate transport level security using [TLS] 703 ------------------------------------------------------------------------- 705 Application-level commands are used to manipulate data on the calendar 706 store. They are listed below and discussed in detail in section 7. 708 CAP Calendaring Commands 709 ------------------------------------------------------------------------- 710 Command Description 711 ------------------------------------------------------------------------- 712 CREATE Create a new calendar or component 714 DELETE Delete a calendar or component 716 GENERATEUID Generate one or more unique ids 718 MODIFY Change a calendar or component 720 MOVE Move a calendar 722 READ Read a calendar properties or components 723 ------------------------------------------------------------------------- 725 CAP Scheduling Commands 726 ------------------------------------------------------------------------- 727 Command Description 728 ------------------------------------------------------------------------- 729 PUBLISH Publish a calendar entry to one 730 or more calendars. 732 Mansour/Dawson/Royer/Taler/Hill 12 Expires September 2000 733 REQUEST Schedule a calendar entry with 734 one or more calendars. 736 REPLY Response to a scheduling request. 738 ADD Add one or more instances to an 739 existing calendar entry. 741 CANCEL Cancel one or more instances to 742 an existing calendar entry. 744 REFRESH A request for the latest version 745 of a calendar entry. 747 COUNTER A request for a change (a 748 counter-proposal) to a calendar 749 entry. 751 DECLINECOUNTER Decline a counter proposal. 752 ------------------------------------------------------------------------- 754 2.4. Security Model 756 Authentication to the CS will be performed using SASL [RFC2222]. 758 As noted in the CAP system model section, a variety of connectivity 759 scenarios are possible. This complicates the security model 760 considerably, and a thorough familiarity with the concepts is required 761 to ensure interoperability. 763 Basic threats to a Calendaring and Scheduling System include: 765 (1) Unauthorized access to data via data-fetching operations, 766 (2) Unauthorized access to reusable client authentication 767 information by monitoring others' access, 768 (3) Unauthorized access to data by monitoring others' access, 769 (4) Unauthorized modification of data, 770 (5) Unauthorized or excessive use of resources (denial of 771 service), and 772 (6) Spoofing of CS: Tricking a client into believing that 773 information came from the CS when in fact it did not, either by 774 modifying data in transit or misdirecting the client's 775 connection. 777 Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), 778 and (3) are due to hostile agents on the path between client and server, 779 or posing as a server. 781 CAP can be protected with the following security mechanisms: 783 Mansour/Dawson/Royer/Taler/Hill 13 Expires September 2000 784 (1) Client authentication by means of the SASL [RFC2222] mechanism 785 set, possibly backed by the TLS credentials exchange mechanism, 786 (2) Client authorization by means of access control based on the 787 requestor's authenticated identity, 788 (3) Data integrity protection by means of the TLS protocol or 789 data-integrity SASL mechanisms, 790 (4) Protection against snooping by means of the TLS protocol or 791 data-encrypting SASL mechanisms, 792 (5) Resource limitation by means of administrative limits on service 793 controls, and 794 (6) Server authentication by means of the TLS protocol or SASL 795 mechanism. 797 Imposition of access controls (authorizations) is done by means of 798 VCARs, an overview is provided in section , and a detailed 799 syntax is provided in section . Authentication is explained in 800 detail in section . 802 2.4.1. Authentication, Credentials, and Identity 804 Generically, authentication credentials are the evidence supplied by one 805 party to another, asserting the identity of the supplying party (e.g. a 806 user) who is attempting to establish an association with the other party 807 (typically a server). Authentication is the process of generating, 808 transmitting, and verifying these credentials and thus the identity they 809 assert. An authentication identity is the name presented in a 810 credential. 812 There are many forms of authentication credentials. The form used 813 depends upon the particular authentication mechanism negotiated by the 814 parties. For example: X.509 certificates, Kerberos tickets, simple 815 identity and password pairs. Note that an authentication mechanism may 816 constrain the form of authentication identities used with it. 818 SASL only provides a protocol to negotiate a mutually acceptable 819 authentication mechanism. SASL itself does not constrain or dictate the 820 form of the authentication identities used to perform the 821 authentication. 823 2.4.2. Calendar User and UPNs 825 A Calendar User(CU) is an entity that can be authenticated. It is 826 represented in CAP as a UPN. A UPN is the owner of a calendar and the 827 subject of access rights. The UPN representation is independent of the 828 authentication mechanism used during a particular CUA/CS interaction. 829 This is because UPNs are used within VCARs. If the UPN were dependant on 830 the authentication mechanism, a VCAR could not be consistently 831 evaluated. A CU may use one mechanism while using one CUA but the same 832 CU may use a different authentication mechanism when using a different 834 Mansour/Dawson/Royer/Taler/Hill 14 Expires September 2000 835 CUA, or while connecting from a different location. 837 The user may also have multiple UPNs for various purposes. 839 Note that the immutability of the user's UPN may be achieved by using 840 SASL's authorization identity feature. (The transmitted authorization 841 identity may be different than the identity in the client's 842 authentication credentials.) [RFC2222, section 3] This also permits a CU 843 to authenticate using their own credentials, yet request the access 844 privileges of the identity for which they are proxying [RFC2222]. Also, 845 the form of authentication identity supplied by a service like TLS may 846 not correspond to the UPNs used to express a server's access control 847 policy, requiring a server-specific mapping to be done. The method by 848 which a server composes and validates an authorization identity from the 849 authentication credentials supplied by a client is implementation- 850 specific. 852 For Calendaring and Scheduling Systems that are integrated with a 853 directory system, the CS MUST support the ability to configure which 854 schema attribute stores the UPN. The CS MAY allow one or more attributes 855 to be searched for the UPN. 857 2.4.2.1. UPNs and Certificates 859 When using X.509 certificates for purposes of CAP authentication, the 860 UPN should appear in the certificate. Unfortunately there is no single 861 correct guideline for which field should contain the UPN. 863 From RFC-2459, section 4.1.2.6 (Subject): 865 If subject naming information is present only in the subjectAltName 866 extension (e.g., a key bound only to an email address or URI), then 867 the subject name MUST be an empty sequence and the subjectAltName 868 extension MUST be critical. 870 Implementations of this specification MAY use these comparison rules 871 to process unfamiliar attribute types (i.e., for name chaining). 872 This allows implementations to process certificates with unfamiliar 873 attributes in the subject name. 875 In addition, legacy implementations exist where an RFC 822 name is 876 embedded in the subject distinguished name as an EmailAddress 877 attribute. The attribute value for EmailAddress is of type 878 IA5String to permit inclusion of the character '@', which is not 879 part of the PrintableString character set. EmailAddress attribute 880 values are not case sensitive (e.g., "fanfeedback@redsox.com" is the 881 same as "FANFEEDBACK@REDSOX.COM"). 883 Conforming implementations generating new certificates with 884 electronic mail addresses MUST use the rfc822Name in the subject 885 alternative name field (see sec. 4.2.1.7 [of RFC 2459]) to describe 887 Mansour/Dawson/Royer/Taler/Hill 15 Expires September 2000 888 such identities. Simultaneous inclusion of the EmailAddress 889 attribute in the subject distinguished name to support legacy 890 implementations is deprecated but permitted. 892 Since no single method of including the UPN in the certificate will work 893 in all cases, CAP implementations MUST support the ability to configure 894 what the mapping will be by the CS administrator. Implementations MAY 895 support multiple mapping definitions, for example, the UPN may be found 896 in either the subject alternative name field, or the UPN may be embedded 897 in the subject distinguished name as an EmailAddress attribute. 899 Note: If a CS or CUA is validating data received via iMIP, if the 900 "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random 901 User:juser@example.com" then the email address should be checked against 902 the UPN, and the CN should also be checked. This is so the "ATTENDEE" 903 property couldn't be munged to something misleading like 904 "ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass 905 validation. This validation will also defeat other attempts at 906 confusion. 908 2.4.2.2. Anonymous Users and Authentication 910 Anonymous access is often desirable. For example an organization may 911 publish calendar information that does not require any access control 912 for viewing or login. Conversely, a user may wish to view unrestricted 913 calendar information without revealing their identity. 915 CAP implementations MUST support anonymous authentication, as defined in 916 section . 918 CAP implementations MAY support anonymous authentication with TLS, as 919 defined in section . 921 2.4.2.3. Required Security Mechanisms 923 The following implementation conformance requirements are in place: 925 (1) For a read-only, public CS, anonymous authentication, 926 described in section , can be used. 928 (2) Implementations providing password-based authenticated access 929 MUST support authentication using Digest, as described in 930 section . This provides client authentication with 931 protection against passive eavesdropping attacks, but does 932 not provide protection against active intermediary attacks. 934 (3) For a CS needing session protection and authentication, the Start 935 TLS extended operation, and either the simple authentication choice 936 or the SASL EXTERNAL mechanism, are to be used together. 938 Mansour/Dawson/Royer/Taler/Hill 16 Expires September 2000 939 Implementations SHOULD support authentication with a password as 940 described in section , and SHOULD support authentication 941 with a certificate as described in section . Together, 942 these can provide integrity and disclosure protection of 943 transmitted data, and authentication of client and server, 944 including protection against active intermediary attacks. 946 2.4.2.4. TLS Ciphersuites 948 The following ciphersuites defined in [RFC 2246] MUST NOT be used for 949 confidentiality protection of passwords or data: 951 TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA 953 The following ciphersuites defined in [RFC 2246] can be cracked easily 954 (less than a week of CPU time on a standard CPU in 1997). The client 955 and server SHOULD carefully consider the value of the password or data 956 being protected before using these ciphersuites: 958 TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 959 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 960 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 961 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 962 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 963 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 964 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 965 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA 967 The following ciphersuites are vulnerable to man-in-the-middle attacks, 968 and SHOULD NOT be used to protect passwords or sensitive data, unless 969 the network configuration is such that the danger of a man-in-the-middle 970 attack is tolerable: 972 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 973 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA 974 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 976 A client or server that supports TLS MUST support at least 977 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 979 2.4.3. User Groups 981 User Group is used to represent a collection of CUs or other UGs that 982 can be referenced in VCARS. A UG is represented in CAP as a UPN. The 983 CUA cannot distinguish between a UPN that represents a CU or a UG. 985 UGs are expanded as necessary by the CS. The CS MUST accept a CUA 986 request for UG expansion, although the CS may be configured to restrict 987 some responses. The CS MAY expand a UG (including nested UGs) to obtain 988 a list of unique CUs. Duplicate UPNs are filtered during expansion. 990 Mansour/Dawson/Royer/Taler/Hill 17 Expires September 2000 991 Incomplete expansion should be treated as a failure. 993 [ Editor's Note: We need to explore the issue and impact of directory 994 permissions and precedence.] 996 The CS SHOULD not preserve UG expansions across operations. A UG may 997 reference a static list of members, or it may represent a dynamic list. 998 Each operation SHOULD generate its own expansion in order to recognize 999 changes to UG membership. However, during fan out to other CSs, the 1000 originating CS SHOULD expand all UGs so that the target CS receives only 1001 a list of unique CUs. This is to prevent confusion when two CSs do not 1002 share the same UG database or directory. 1004 [Editor's Note: Doug had an issue here relating to multiple CUs not 1005 having a common directory. We think the above text resolves this] 1007 CAP does not define commands or methods for managing UGs. 1009 Examples: 1011 Small UG - The Three Stooges. There is only and always three at any 1012 one time. 1013 Large UG - The MIT graduating class of 1999. This is a static list. 1014 Dynamic UG - The IETF membership, which is a large and changing list 1015 of members. 1016 Nested UG - The National Football League, made up of the AFC and 1017 NFC, which are made up of 3 divisions each... 1019 2.4.4. Access Rights 1021 In simple terms, access rights are used to grant or deny access to a 1022 calendar for a CU. CAP defines a new component type called a VCalendar 1023 Access Right (VCAR). Specifically, a VCAR grants, or denies, UPNs the 1024 right to read and write components, properties, and parameters on 1025 calendars within a CS. 1027 The VCAR model does not put any restriction on the sequence in which the 1028 object and access rights are created. That is, an event associated with 1029 a particular VCAR might be created before or after the actual VCAR is 1030 defined. In addition, the VCAR and VEVENT definition might be created in 1031 the same iCalendar object and passed together in a single command. 1033 All rights MUST be denied unless specifically granted; individual VCARs 1034 MUST be specifically granted to an authenticated CU. 1036 2.4.4.1. VCalendar Access Right (VCAR) 1038 Access rights within CAP are specified with the "VCAR" calendar 1039 component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" 1040 component properties. 1042 Mansour/Dawson/Royer/Taler/Hill 18 Expires September 2000 1043 Properties within an iCalendar object are unordered. This also is the 1044 case for the "GRANT", "DENY" and "CARID" properties. Likewise, 1045 there is no implied ordering required for components of a "RIGHTS" value 1046 type other than that specified by the ABNF. [ editor's note, this 1047 requires a lot of review. We think that this paragraph may be incorrect. 1048 ] 1050 For details on the VCAR syntax please see section 1052 2.4.4.2. Decreed VCARs 1054 [editor's note: new concept. This will also require some syntax 1055 modification 14.4. This section is being actively discussed on the 1056 working group list, 2/3/2000.] 1058 A CS MAY choose to implement and allow persistent immutable VCARs, that 1059 are configured by the CS Administrator, which apply to all calendars on 1060 the server. 1062 When a user attempts to modify a decreed VCAR and error will be 1063 returned,indicating that the user has insufficient authorization to 1064 perform the operation. 1066 The CAP protocol does not define the semantics used to initially create 1067 a decreed VCAR. This administrative task is out side the scope of the 1068 CAP protocol. 1070 2.4.4.3. Inheritance 1072 Calendars inherit VCARs from their parent. 1074 VCARs specified in a calendar or a sub-calendar override all inherited 1075 VCARs. 1077 2.4.5. CAP session identity 1079 A CAP session has an associated set of authentication credentials, from 1080 which is derived a UPN. This UPN is the identity of the CAP session, and 1081 is used to determine access rights for the session. 1083 The CUA may change the identity of a CAP session by calling the 1084 "IDENTIFY" command. The Calendar Service only permits the operation if 1085 the session's authentication credentials are good for the requested 1086 identity. The method of checking this permission is implementation 1087 dependent, but may be thought of as a mapping from authentication 1088 credentials to UPNs. The "IDENTIFY" command allows a single set of 1089 authentication credentials to choose from multiple identities, and 1090 allows multiple sets of authentication credentials to assume the same 1091 identity. 1093 Mansour/Dawson/Royer/Taler/Hill 19 Expires September 2000 1094 For anonymous access the identity of the session is "@", a UPN with a 1095 null username and null realm. A UPN with a null username, but non-null 1096 realm, such as "@foo.com" may be used to mean any identity from that 1097 realm, which is useful to grant access rights to all users in a given 1098 realm. A UPN with a non-null username and null realm, such as "bob@" 1099 could be a security risk and must not be used. 1101 Since the UPN includes realm information it may be used to govern 1102 calendar store access rights across realms. However, governing access 1103 rights across realms is only useful if login access is available. This 1104 could be done through a trusted server relationship or a temporary 1105 account. 1107 The "IDENTIFY" command provides for a weak group implementation. By 1108 allowing multiple sets of authentication credentials belonging to 1109 different users to identify as the same UPN, that UPN essentially 1110 identifies a group of people, and may be used for group calendar 1111 ownership, or the granting of access rights to a group. 1113 Examples: 1115 Small UG - The Three Stooges. There will always be three, it will 1116 not change. 1118 Large UG - The MIT graduating class of 1999. This is a static list. 1120 Dynamic UG - The IETF membership, which is a large and changing 1121 list of members. 1123 Nested UG - The National Football League, made up of the AFC and 1124 NFC, which are made up of 3 divisions each... 1126 2.5. Roles 1128 CAP defines methods for managing [RFC2445] objects on a Calendar Store 1129 and exchanging [RFC2445] objects for the purposes of group calendaring 1130 and scheduling between "Calendar Users" (CUs) or "User Groups" (UGs). 1131 There are two distinct roles taken on by CUs in CAP. The CU who creates 1132 an initial event or to-do and invites other CUs or UGs as attendees 1133 takes on the role of "Organizer". The CUs or UGs asked to participate in 1134 the group event or to-do take on the role of "Attendee". Note that 1135 "role" is also a descriptive parameter to the "ATTENDEE" property. Its 1136 use is to convey descriptive context to an "Attendee" such as "chair", 1137 "REQ-PARTICIPANT" or NON- PARTICIPANT" and has nothing to do with the 1138 scheduling workflow. 1140 Mansour/Dawson/Royer/Taler/Hill 20 Expires September 2000 1141 2.6. Calendar Addresses 1143 Calendar addresses are URIs that are modeled after [RFC2396]. CAP uses 1144 the following forms of URI. 1146 [[]://[:]/] 1148 where: 1150 is "cap" 1152 is the Calendar Store ID. It is the network address of the 1153 computer on which the CAP server is running. 1155 is optional. Its default value is 5229. The port must be present 1156 if the CAP server does not listen on the default port. 1158 is an identifier that uniquely identifies the calendar 1159 on a particular calendar store. There is no implied structure in a 1160 Relative CALID. It is an arbitrary string of 7 bit ASCII characters. It 1161 may refer to the calendar of a user or of a resource such as a 1162 conference room. It MUST be unique within the calendar store. It is 1163 recommended that the Relative CALID be globally unique. 1165 If the and are present the calendar address is said to 1166 be "qualified". Senders are required to supply the 1167 portion of the address. A qualified calendar address is required when 1168 the of the target calendar address differs from that of the CAP 1169 server receiving the command. 1171 Examples: 1173 cap://calendar.example.com/user1 1174 ://calendar.example.com/user1 1175 user1 1176 cap://calendar.example.com/conferenceRoomA 1177 cap://calendar.example.com/89798-098-zytytasd 1179 For a user currently authenticated to a CAP server on 1180 calendar.example.com, the first three addresses refer to the same 1181 calendar. 1183 2.7. Extensions to iCalendar 1185 In mapping the CAP command set, query feature, and access rights onto 1186 the iCalendar format, several extended iCalendar methods and components 1187 are defined by this memo. 1189 * The search function is specified with the new iCalendar QUERY 1190 method. The QUERY method makes use of a new component, called 1191 VQUERY, that contains the search filter. The component consists of 1193 Mansour/Dawson/Royer/Taler/Hill 21 Expires September 2000 1194 a set of new properties: SCOPE, MAXRESULTS, MAXRESULTSSIZE, QUERY 1195 and QUERYNAME, that define the search filter. 1197 * Access control is specified the the new iCalendar VCAR component. 1199 * The iCalendar METHOD property format has been updated with new 1200 values. 1202 * A new iCalendar component, VCOMMAND, has been added. VCOMMANDs 1203 are needed to fully specify CAP commands. 1205 * TARGET is a new property within the VCOMMAND component. It 1206 indicates the calendars to which the command applies 1208 2.8. Relationship of RFC 2446 (ITIP) to CAP 1210 [RFC2446] describes scheduling methods which result in indirect 1211 manipulation of calendar components. CAP methods provide direct 1212 manipulation of calendar components. In the CAP calendar store model, 1213 scheduling messages are kept separate from other calendar components. 1214 This is modeled with the VSCHEDULE queue. Note that this is a conceptual 1215 model, the actual storage details are left to implementations. The model 1216 is shown pictorially as follows: 1218 +-----------------VCALENDAR-------------------+ 1219 | | 1220 | +-----------+ +-------VSCHEDULE---------+ | 1221 | | VEVENTs | | PUBLISH messages | | 1222 | | VTODOs | | REQUEST messages | | 1223 | | VJOURNALs | | REPLY messages | | 1224 | | | | ADD messages | | 1225 | | | | CANCEL messages | | 1226 | | | | REFRESH messages | | 1227 | | | | COUNTER messages | | 1228 | | | | DECLINECOUNTER messages | | 1229 | +-----------+ +-------------------------+ | 1230 +---------------------------------------------+ 1232 The METHOD is saved along with components. Scheduled components become 1233 booked components when the METHOD changes from an ITIP method to the CAP 1234 storage method. For example, a component whose METHOD is "REQUEST" is 1235 scheduled. The component becomes booked when the METHOD is changed to 1236 "CREATED". 1238 [ed note: need to clean up the terminology here. We havent discussed 1239 "booked"] 1241 Mansour/Dawson/Royer/Taler/Hill 22 Expires September 2000 1242 2.9. VCalendar Access Rights (VCARs) 1244 In simple terms, VCARs are used to grant or deny access to a calendar 1245 for a CU or UG. Specifically, they grant User Principal Names (UPNs) the 1246 rights to read and write components, properties, and parameters on 1247 calendars within a calendar store. 1249 The model does not put any restriction on the sequence in which the 1250 object and access rights are created. That is, an event associated with 1251 a particular VCAR might be created before or after the actual VCAR is 1252 defined. In addition, the VCAR and VEVENT definition might be created in 1253 the same iCalendar object and passed together in a single SENDDATA 1254 command. 1256 VCAR principals can be CU or UG UPNs. Whenever VCARs are evaluated, all 1257 referenced User Groups MUST be evaluated as an expanded list. UG 1258 expansion SHOULD NOT persist across operations. 1260 [Editor's Note: This is where we need to define precedence rules.] 1262 2.10. Query Schema 1263 breif paragraph on summary of VQUERY. 1265 3. State Diagram 1267 This section describes the states of the transport connection between a 1268 CUA and a CS. The state diagram is shown below. State names shown with 1269 first letter capitalized. The commands used to switch between states are 1270 shown next to an arrow connecting the states. The commands are listed in 1271 all capital letters. A condition that causes a state to change is shown 1272 in lower case letters. 1274 Mansour/Dawson/Royer/Taler/Hill 23 Expires September 2000 1275 STARTTLS / 1276 CAPABILITY 1277 +-------+ 1278 | | +---------------+ 1279 | +-----------+ AUTHENTICATE | | 1280 +-->| Connected |-------------->| Authenticated | 1281 +-----------+ | | 1282 | +---------------+ 1283 | | 1284 | | 1285 | | 1286 | | +-----+ STARTTLS / 1287 | V | | CAPABILITY / 1288 | +---------------+ | IDENTIFY 1289 | | |<-+ 1290 | | Identified |<----+ 1291 | +--------| | | 1292 | | +---------------+ | command 1293 | | | | completes 1294 V |DISCONNECT | | 1295 +--------------+ | |SENDDATA | 1296 | Disconnected |<--+ | | 1297 +--------------+ | | ABORT 1298 A | | 1299 | V | 1300 | DISCONNECT +---------------+ | 1301 +--------------------| Receive |--+ 1302 | |<--+ 1303 +---------------+ | 1304 | | CONTINUTE 1305 +----+ 1307 The connection begins the Connected state when a CUA connects to a CAP 1308 server. The capabilities of the CS are reported in the response from the 1309 CS. From this state, the CUA can issue the DISCONNECT command to 1310 terminate the connection, the CAPABILITY, STARTTLS, or AUTHENTICATE 1311 commands. One use of the CAPABILITY command at this stage is to 1312 determine the supported authentication mechanisms supported by the 1313 server. Once the STARTTLS command has been successfully executed from 1314 either the Connected or Authenticated state, it must not be executed 1315 again. 1317 If an AUTHENTICATE command is successful, the connection enters the 1318 Authenticated state and then immediately goes to the IDENTIFIED state. 1319 While in the Identified state, allow CALIDEXPAND and UPNEXPAND commands. 1320 From here the CUA can issue the CAPABILITY command. The capabilities the 1321 server offers in the Authenticated state may be different than those in 1322 the Connected state. The CUA can also use the IDENTIFY command to change 1323 the identity of the user subject to access control. The connection 1324 remains in the Authenticated state after the CAPABILITY command 1326 Mansour/Dawson/Royer/Taler/Hill 24 Expires September 2000 1327 completes. The CUA can issue the DISCONNECT command to terminate the 1328 connection. The SENDDATA command can be used to send a request to read, 1329 write, modify, or delete data on the server. 1331 After the SENDDATA command has been issued the connection enters the 1332 Receive state while the CUA awaits and reads a server reply. Normally, 1333 the server handles the command, sends a reply which is read by the CUA 1334 and the connection returns to the Authenticated state. The CUA may have 1335 issued the SENDATA command with a maximum latency time. This informs the 1336 server that the CUA expects a response within the maximum latency time, 1337 even if the command was not completed. When the server is unable to 1338 complete the command in the maximum latency time, it issues an 1339 appropriate reply code and waits for the CUA to tell it how to proceed. 1340 If the CUA issues a CONTINUE command the server continues processing the 1341 command and the connection remains in the Receive state. If the CUA 1342 issues the ABORT command the server need not process the command any 1343 further and the connection returns to the Authenticated state. The 1344 DISCONNECT command can also be issued from the Receive state. 1346 4. Protocol Framework 1348 4.1. CAP Application Layer 1350 The CAP application layer is used for the manipulation of the calendar 1351 store. Commands and responses are transmitted between the CUA and CS 1352 inside "VCALENDAR" component wrappers. Commands are specified as the 1353 value of a "METHOD" property, and responses are specified as the value 1354 of a "REQUEST-STATUS" property. 1356 4.2. CAP Transfer Protocol 1358 The CAP transfer protocol defines the format of data transmitted between 1359 a CUA and the CS. 1361 CAP transfer protocol commands are transmitted using the underlying 1362 transport. The transport used is a TCP/IP socket connection between the 1363 CUA and the CS. The default port that the CS listens for connections on 1364 is port 5229. 1366 Messages sent between the CUA and CS are formatted as a command followed 1367 by any associated data: 1369 [] 1371 4.3. Response Format 1373 Server responses consist of a response code and any parameters: 1375 [response args] [; debug text ; more 1377 Mansour/Dawson/Royer/Taler/Hill 25 Expires September 2000 1378 text] . [] . 1380 The response codes are defined in Section 8. The debug text is human- 1381 readable information for protocol debugging and is optional. 1383 The optional application-data begins on the next line. 1385 The response is terminated with the second "." sequence. 1386 Any "." sequences which appear in the transmitted data must be 1387 quoted by placing an additional "." between the and the ".". For 1388 example, the following sequences of characters in the application data: 1390 . 1391 ..2 1392 ...3 1394 are quoted as follows: 1396 .. 1397 ...2 1398 ....3 1400 No other tagged command sequence can be sent until the second special 1401 terminating character sequence . has been sent. 1403 4.4. Auto-logout Timer 1405 If a server has an inactivity auto-logout timer, that timer MUST be of 1406 at least 15 minutes duration. The receipt of ANY command from the client 1407 during that interval MAY reset the auto-logout timer, subject to CS 1408 administrators policy. A CUA may be discouraged from attempts to do 1409 usless things only to keep the connection alive. 1411 When a timeout occurs, the server drops the connection to the CUA. 1413 4.5. Bounded Latency 1415 [CAP] is designed so that the CUA can either obtain an immediate 1416 response from a request or discover within a specified amount of time 1417 that the request could not be completed in the requested amount of time. 1418 When the CUA initiates a command that the server cannot complete within 1419 the specified latency time, the server returns an appropriate response 1420 code. The CUA then issues either a CONTINUE or ABORT command. The ABORT 1421 command immediately terminates the command in progress and the 1422 connection returns to the Authenticated state. The CONTINUE command 1423 instructs the server to continue processing the command. 1425 Mansour/Dawson/Royer/Taler/Hill 26 Expires September 2000 1426 4.6. Data Elements 1428 The data elements for CAP are MIME encapsulated iCalendar objects. 1430 5. Formal Command Syntax 1432 5.1. Searching and Filtering 1434 This section describes CAPs searching and filtering entities within a 1435 remote store. It is based on the Standard Query Language (SQL) defined 1436 by [SQL]. 1438 The QUERY property value MUST be a valid QUERY value type. This new 1439 value type is defined to be a "name=value" value type grammar, similar 1440 in syntax to the format already in use for the iCalendar RECUR value 1441 type. Each "name" is the name of a valid SQL statement component (e.g., 1442 SELECT, WHERE, etc.). Each "value" is valid string associated with one 1443 of these SQL statement components. 1445 [Editor's note: We need to precisely define what part of SQL were using 1446 and why we chose what we did.] 1448 Examples needed: 1450 Grant someone access to June events 1451 Grant someone access to events during the month of June. (i.e., based 1452 on the current system date, if it's prior to June or after June you 1453 don't have access) 1455 Example for denying access to a specific property: 1457 DENY:UPN=FOO;ACTION=*;OBJECT=CLASS 1459 *scope vcar to a component *scope Grant, Deny of a VCAR 1461 5.1.1. Grammar For Search Mechanism 1463 SEARCH = "BEGIN:VQUERY" CRLF 1464 [scope] [maxresults] [maxsize] querycomp 1465 "END:VQUERY" CRLF 1467 scope = "SCOPE:" comp-name ("," comp-name)* 1469 comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" 1470 / "VALARM" / "VFREEBUSY" / "VCAR" / iana-name / x-name 1472 maxresults = integer 1474 maxsize = integer 1476 Mansour/Dawson/Royer/Taler/Hill 27 Expires September 2000 1477 querycomp = (query) / (queryname query) / queryname 1479 queryname = "QUERYNAME:" text 1481 query = "QUERY:" queryrule 1483 queryrule = capselect capwhere caporderby ... 1485 capselect = 1487 capwhere = 1489 caporderby = 1492 6. Access Rights 1494 Access rights within CAP are specified with the "VCAR" calendar 1495 component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" 1496 component properties. 1498 Individual calendar access rights MUST be specifically granted to an 1499 authenticated calendar user (i.e., UPN); all rights are denied unless 1500 specifically granted. 1502 Properties within a VCAR must be evaluated in the order provided. 1504 6.1. VCAR Inheritance 1506 Calendar access rights specified in a calendar store are inherited as 1507 default calendar access rights for any calendar in the parent calendar 1508 store. Likewise, any calendar access rights specified in a root calendar 1509 are inherited as default calendar access rights for any sub- calendar to 1510 the root calendar. By implication, calendar access rights specified in a 1511 sub-calendar are inherited as default calendar access rights for any 1512 calendars that are hierarchically below the sub- calendar. 1514 Calendar access rights specified in a calendar override any default 1515 calendar access rights. Calendar access rights specified within a sub- 1516 calendar override any default calendar access rights. 1518 6.2. Access Control and NOCONFLICT 1520 The TRANSP property can take on values (TRANSPARENT-NOCONFLICT, OPAQUE- 1521 NOCONFLICT) that prohibit other events from overlapping it. This setting 1522 overrides access While access control may allow a UPN to store an event 1523 on a particular calendar. , the CONFLICTS Calendar or component setting 1524 may prevent it, returning an error code "6.3" 1526 Mansour/Dawson/Royer/Taler/Hill 28 Expires September 2000 1527 7. Commands and Responses 1529 CAP commands and responses are described in this section. 1531 Command arguments, identified by "Arguments:" in the command 1532 descriptions below, are described by function, not by syntax. The 1533 precise syntax of command arguments is described in the Formal Syntax 1534 section. 1536 Some commands cause specific server data to be returned; these are 1537 identified by "Data:" in the command descriptions below. See the 1538 response descriptions in the Responses section for information on these 1539 responses, and the Formal Syntax section for the precise syntax of these 1540 responses. 1542 The "Result:" in the command description refers to the possible status 1543 responses to a command, and any special interpretation of these status 1544 responses. 1546 Commands have the general form: 1548 [arguments...] 1550 where is a command listed in the table above. A command MAY 1551 have arguments. Arguments are defined in the detailed command 1552 definitions below. 1554 Responses to commands have the following general form: 1556 responseCode [sep transportDescr sep [applicationDescr]] 1557 CRLF "." CRLF 1559 In the examples below, lines preceded with "S:" refer to the sender and 1560 lines preceded with "R:" refer to the receiver. Lines in which the first 1561 non-whitespace character is a "#" are editorial comments and are not 1562 part of the protocol. 1564 7.1. Transfer Protocol Commands 1566 7.1.1. Initial Connection 1568 Arguments: none 1570 Data: none 1572 Result: 2.0 - success. 1573 8.1 - server too busy 1575 Upon session startup, the server sends a response of 2.0 to indicate 1576 that it is ready to receive commands. A response of 8.1 indicates that 1577 the server is too busy to accept the connection. In addition, the 1579 Mansour/Dawson/Royer/Taler/Hill 29 Expires September 2000 1580 general capabilities of the CS are reported in the response from the CS. 1581 These capabilities may be different than those reported in the 1582 authenticated state. 1584 The supported authentication mechanisms. There may be 1 or more. 1586 CAPVERSION 1587 IRIPVERSION 1589 7.1.2. ABORT Command 1591 Arguments: none 1593 Data: none 1595 Result: 2.0 - success 1596 2.2 - no command is in progress 1598 The ABORT command is issued by the CUA to stop a command whose latency 1599 time has been exceeded. When the latency time is specified on the 1600 SENDATA command, the CS must issue a reply to the CUA within the 1601 specified time. It may be a reply code indicating that the CS has not 1602 yet processed the request. The CUA must then tell the server whether to 1603 continue or abort. 1605 The CUA can issue the ABORT command at any time after the SENDATA 1606 command has been completed but before receiving a reply. 1608 7.1.3. AUTHENTICATE Command 1610 Arguments: [] 1612 Data: continuation data may be requested 1614 Result: 1616 2.0 - Authenticate completed, now in authenticated 1617 state. 1618 6.0 - Failed authentication. 1619 6.1 - Authorization identity refused. 1620 6.2 - Sender aborted authentication, authentication 1621 exchange cancelled. 1622 6.3 - Unsupported Authentication Mechanism. 1623 6.x - Temporary failure (back end authentication 1624 server down). 1625 6.x - Authentication exchange cancelled. 1626 6.x - Authentication mechanism too weak. 1628 Mansour/Dawson/Royer/Taler/Hill 30 Expires September 2000 1629 6.x - Encryption required. 1630 6.x - Pass phrase expired. The pass phrase was 1631 correct but expired. The user will have to 1632 contact a pass phrase change server prior to 1633 authenticating. 1634 6.x - The user is valid but the server does not 1635 have an entry in the authentication database 1636 for the requested mechanism (e.g., DIGEST- 1637 MD5). If the user successfully authenticates 1638 using a plain text password, then the back 1639 end back end entry will be updated. Note 1640 that if the client chooses to fall back to 1641 plain text password authentication it should 1642 enable an encryption layer or get user-con- 1643 firmation that a one-time transition is ac- 1644 ceptable. 1645 6.x - User account disabled. The user will have to 1646 contact the system administrator to get the 1647 account re-enabled. 1648 9.1 - Unexpected command. 1650 The capabilities of the CS in the authenticated state are reported in 1651 the response from the CS. These may be different than the capabilities 1652 in the Connected, but unauthenticated state. 1654 The AUTHENTICATE command is used by the CUA to identify the user to the 1655 CS. CAP supports a number of authentication methods, the [SASL] 1656 specification for authentication is the preferred method. 1658 If STARTTLS is negotiated prior to the AUTHENTICATE command, the client 1659 MUST discard all information about the CS capabilities fetched prior to 1660 the TLS negotiation. In particular, the value of supported SASL 1661 Mechanisms MAY be different after TLS has been negotiated. 1663 If a SASL security layer is negotiated, the client MUST discard all 1664 information about the CS capabilities fetched prior to SASL. In 1665 particular, if the client is configured to support multiple SASL 1666 mechanisms, it SHOULD fetch supported SASL Mechanisms both before and 1667 after the SASL security layer is negotiated and verify that the value 1668 has not changed after the SASL security layer was negotiated. This 1669 detects active attacks which remove supported SASL mechanisms from the 1670 supported SASL Mechanisms list. 1672 is an optional parameter which can be used for mechanisms 1673 which require an initial response from the CUA. 1675 The AUTHENTICATE command is followed by an authentication protocol 1676 exchange, in the form of a series of CS challenges and CUA responses, 1677 per the relevant RFC that describes the specific SASL mechanism being 1678 used. 1680 Mansour/Dawson/Royer/Taler/Hill 31 Expires September 2000 1681 Cancelling the authentication process during its negotiation is 1682 implementation specific and not within scope of the CAP specification. 1684 If a security layer was negotiated it comes into effect for the CS 1685 starting with the first octet transmitted after the CRLF which follows 1686 the 2.0 reply code, and for the CUA starting with the first octet after 1687 the CRLF of its last response in the authentication exchange. Encrypted 1688 data is transmitted as described in [SASL]. 1690 The service name specified by this protocol's profile of SASL is "cap". 1691 [Note: this must be registered with IANA, has anyone done this yet?] 1693 The result of the AUTHENTICATE command includes data indicating the 1694 identity which has been assigned to the session, derived from the 1695 supplied authentication credentials, and/or authorization identifier. A 1696 CAP session does not have an identity until the CUA has issued the 1697 "AUTHENTICATE" command. 1699 The CUA may not issue the "AUTHENTICATE" command multiple times, even if 1700 the first attempt was aborted. If a CUA attempts to do this the CS must 1701 terminate the session. 1703 Data returned in response to a successful login is: 1705 The following examples illustrate the various possibilities for an 1706 authentication protocol exchange. 1708 Here are examples of a successful authentication: 1709 C: AUTHENTICATE KERBEROS_V4 1710 S: AmFYig== 1711 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 1712 S: or//EoAADZI= 1713 C: DiAF5A4gA+oOIALuBkAAmw== 1714 S: 2.0 1715 S: . 1716 S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII 1717 S: Content-Transfer-Encoding: 7bit 1719 S: 1720 S: BEGIN:VCALENDAR 1721 S: PRODID:-//ACME/CAPserver//EN 1722 S: VERSION:2.1 1723 S: IDENTITY=bill@example.com 1724 S: CAPVERSION=1.0 1725 S: ITIPVERSION=1.0 1726 S: AUTH=KERBEROS_V4 1727 S: AUTH=DIGEST_MD5 1728 S: CAR=CAR-FULL-1 1729 S: MINDATE=19700101T000000Z 1730 S: MAXDATE=20370201T000000Z 1731 S: END:VCALENDAR 1732 S: . 1734 Mansour/Dawson/Royer/Taler/Hill 32 Expires September 2000 1735 This example shows a failed authentication: 1737 C: AUTHENTICATE KERBEROS_V4 1738 S: AmFYig== 1739 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 1740 S: . 1741 S: 6.0 1742 S: . 1743 S: . 1745 7.1.3.1. AUTHENTICATE ANONYMOUS 1747 RFC-2245 defines the Anonymous SASL mechanism. This RFC states that "the 1748 mechanism consists of a single message from the client to the server. 1749 The client sends optional trace information in the form of a human 1750 readable string. The trace information should take one of three forms: 1751 an Internet email address, an opaque string which does not contain the 1752 '@' character and can be interpreted by the system administrator of the 1753 client's domain, or nothing. For privacy reasons, an Internet email 1754 address should only be used with permission from the user." 1756 RFC-2245 goes on to state, "A client which uses the user's correct email 1757 address as trace information without explicit permission may violate 1758 that user's privacy." Information about who accesses an anonymous CS on 1759 a sensitive subject (e.g., AA meeting times and locations) has strong 1760 privacy needs. "Clients should not send the email address without 1761 explicit permission of the user and should offer the option of supplying 1762 no trace token -- thus only exposing the source IP address and time." 1764 Example of CUA using the Capability command followed by an anonymous 1765 authentication: 1767 C: CAPABILITY 1768 S: 2.0 1769 S:CAPVERSION=1.0 1770 S:AUTH=KERBEROS_V4 1771 S:AUTH=DIGEST_MD5 1772 S:AUTH=ANONYMOUS 1773 S:. 1774 C:AUTHENTICATE ANONYMOUS 1775 S:+ 1776 C:c21yaGM= 1777 S:2.0 1779 Subsequent to the initial Anonymous Authentication with a CS, a CUA will 1780 have to provide a UPN for some CAP operations. For anonymous access the 1781 UPN that MUST be used by the CUA is "@", a UPN with a null username and 1782 null realm. The user's normal UPN MUST not be used for the subsequent 1783 CAP operations. 1785 Mansour/Dawson/Royer/Taler/Hill 33 Expires September 2000 1786 Note that the CS implementation may have internal audit logs that use 1787 the user's asserted UPN as trace information. However, this UPN will not 1788 appear on the wire after the initial SASL anonymous authentication. 1790 Use of the "@" UPN and wild-carding of UPNs within VCARs are covered in 1791 Section . 1793 7.1.4. CALIDEXPAND Command 1795 Arguments: CalID 1797 Data: no specific data for this command 1799 Result: 2.0 Successful, and requested data follows 1800 2.1 Permission Denied 1801 2.2 Requested CSID not found 1802 2.3 Result exceeds MAXEXPANDLIST 1803 2.4 Misc. EXPAND error 1805 Return the members of the argument CalID. Successful result yields one 1806 or more Calendars and/or Resource Calendars. More than one C or RC 1807 returned implies that the CalID was a CC. 1809 Example: 1811 Example #1: Request lookup of CSID which is a Calendar Collection 1813 C: CALIDEXPAND cap://cal.example.com/calid14 1814 S: 2.0 cap://cal.example.com/calid14 1815 S: cap://cal.example.com/calid2 1816 S: cap://cal.example.com/calid5 1817 S: cap://cal.example.com/calid66 1818 S: . 1820 Example #2: Request lookup of a CSID which is a Resource Calendar 1822 C: CALIDEXPAND cap://cal.example.com/conf5 1823 S: 2.0 cap://cal.example.com/conf5 1824 S: cap://cal.example.com/conf5 1825 S: . 1827 Example #3: Request CSID which exceeds MAXCALIDEXPANDLIST 1829 C: CALIDEXPAND cap://cal.example.com/calid76 1830 S: 2.0 cap://cal.example.com/calid76 1831 S: cap://cal.example.com/calid3 1832 S: cap://cal.example.com/calid12 1833 S: cap://cal.example.com/calid21 1834 S: cap://cal.example.com/calid33 1835 S: 2.3 Expansion resulted in too much data 1836 S: . 1838 Mansour/Dawson/Royer/Taler/Hill 34 Expires September 2000 1839 Example #4: CS loses contact with directory server during CALIDEXPAND 1841 C: CALIDEXPAND cap://cal.example.com/calid76 1842 S: 2.0 cap://cal.example.com/calid76 1843 S: cap://cal.example.com/calid3 1844 S: cap://cal.example.com/calid5 1845 S: 2.4 Lost contact with directory server 1846 S: . 1848 7.1.5. CAPABILITY Command 1850 Arguments: none 1852 Data: none 1854 Result: capabilities as described below 1856 The CAPABILTY command returns information about the CAP server given the 1857 current state of the connection with the client. The values returned may 1858 differ depending on whether the connection is in the Connected or the 1859 Authenticated state. The return values may also be different for a 1860 secure versus a non-secure connection. 1862 Client implementations SHOULD NOT require any capability name beyond 1863 those defined in this specification, and MAY ignore any non-standard, 1864 experimental capability names. Non-standard capability names are 1865 prefixed with the text "X-". The prefix SHOULD also include a short 1866 character vendor identifier For example, "X-FOO-BARCAPABILITY", for the 1867 non-standard "BARCAPABILITY" capability of the implementor "FOO". This 1868 command may return different results in the Connected state versus the 1869 Authenticated state. It may also return different results depending on 1870 the UPN. 1872 Capability Occurs Description 1873 ----------------------------------------------------------------------- 1874 CAPrev1 1 Revision of CAP, must be "CAPrev1" 1876 IRIPrev1 0 or 1 Revision of IRIP, MAY be present. If 1877 present, it MUST be "IRIPrev1" 1879 CAR 0 or 1 Indicates level of CAR support CAR-MIN 1880 or CAR-FULL-1 1882 Mansour/Dawson/Royer/Taler/Hill 35 Expires September 2000 1883 MAXICALOBJECTSIZE 0 or 1 An integer value that specifies The 1884 largest ICAL object the server will ac- 1885 cept in bytes. Objects larger than this 1886 will be rejected. A value of zero (0) 1887 indicates unlimited. 1889 MAXDATE 0 or 1 The datetime value beyond which the 1890 server cannot accept. 1892 MAXCALIDEXPANDLIST 0 or 1 An integer value that specifies the max- 1893 imum number of CalIDs that can be re- 1894 turned by the CALIDEXPAND Command. A 1895 value of zero (0) indicates unlimited. 1897 MAXUPNEXPANDLIST 0 or 1 An integer value that specifies the max- 1898 imum number of UPNs that can be returned 1899 by the UPNEXPAND Command. A value of 1900 zero (0) indicates unlimited. 1902 MINDATE 0 or 1 The datetime value prior to which the 1903 server cannot accept. 1905 Example: 1907 C: CAPABILTIY 1908 S: 2.0 1909 S: . 1910 S: CAPVERSION=1.0 1911 S: ITIPVERSION=1.0 1912 S: AUTH=KERBEROS_V4 1913 S: AUTH=DIGEST_MD5 1914 S: . 1916 7.1.6. CONTINUE Command 1918 Arguments: latency time in seconds (optional) 1920 Data: none 1922 Result: results from the command in progress 1923 2.0.2 - reply pending. 1925 The CONTINUE command is issued by the client in response to a SENDATA 1926 timeout. When a timeout value is specified on the SENDDATA command, the 1927 server must issue a reply to the client within the specified time. If 1928 the latency time has elapsed prior to the server completing the command 1929 it returns a timeout response code. If the client wants the server to 1930 continue processing the command it responds with the CONTINUE command. 1932 If latencyTime is present, it must be a positive integer that specifies 1934 Mansour/Dawson/Royer/Taler/Hill 36 Expires September 2000 1935 the maximum number of seconds the client will wait for the next 1936 response. If it is omitted, the receiver waits an indefinite period of 1937 time for the response. 1939 In this example, the client requests a response from the server every 10 1940 seconds. 1942 C: SENDDATA:10 1943 C: Content-Type:text/calendar; method=READ; component=VEVENT 1944 C: 1945 C: BEGIN:VCALENDAR 1946 # etc 1947 C: END:VCALENDAR 1948 C: . 1949 # after 10 seconds... 1950 S: . 1951 S: 2.0.2 1952 S: . 1953 S: . 1954 C: CONTINUE:10 1955 S: 2.0 1956 S: . 1957 S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; 1958 S: Optinfo=VERSION:2.1 1959 S: 1960 S: BEGIN:VCALENDAR 1961 S: VERSION:2.1 1962 S: CALID:cap://cal.example.com/relcal2 1963 # etc. 1964 S: END:VCALENDAR 1965 S: . 1967 7.1.7. DISCONNECT Command 1969 Arguments: none 1971 Data: 1973 Result: 2.0 1975 The DISCONNECT command is used by a client to terminate a connection. 1976 It always succeeds. 1978 Example: 1980 C: DISCONNECT 1981 # [ed. Note: should the client now wait for a response from the 1982 server 1983 # before disconnecting? ] 1984 S: 2.0 1985 S: . 1986 S: . 1988 Mansour/Dawson/Royer/Taler/Hill 37 Expires September 2000 1989 C: 1990 S: 1992 7.1.8. IDENTIFY Command 1994 Arguments: Identity to assume 1996 Data: None 1998 Result: 2.0 1999 6.4 Identity not permitted 2001 The "IDENTIFY" command allows the CUA to select a new identity to be 2002 used for calendar access. This command may only be called in the 2003 Identified State. 2005 The CS determines through an internal mechanism if the credentials 2006 supplied at authentication permit the assumption of the selected the 2007 identity. If they do the session assumes the new identity, otherwise a 2008 security error is returned. 2010 7.1.9. SENDDATA Command 2012 Arguments: [latencyTime] 2014 Data: a MIME encapsulated iCalendar object 2016 Result: 2.0.1 - Server will now accept input until . 2017 is encountered. 2019 The SENDDATA command is used to send calendar requests and commands to 2020 the server. After a response code of 2.0.1 is issued the CUA sends a 2021 MIME encapsulated iCalendar object to the server. The end of this MIME 2022 data is signaled by the special sequence . . 2024 7.1.10. STARTTLS Command 2026 Arguments: None 2028 Data: None 2030 Result: 2.0 2032 6.5 TLS not supported 2034 The "STARTTLS" command is issued by the CUA to indicate to the CS that 2035 it wishes to negotiate transport level security using [TLS]. If the CS 2036 does not support TLS it returns status code 6.5. If the CS supports TLS 2037 it issues an initial response of 2.0.12 indicating that the CUA should 2039 Mansour/Dawson/Royer/Taler/Hill 38 Expires September 2000 2040 proceed with TLS negotiation. Once the TLS negotiation is complete the 2041 server returns the response code 2.0. 2043 After issuing the "STARTTLS" command the CUA issues the "AUTHENTICATE" 2044 command. The SASL external mechanism may be used if the CUA wishes to 2045 use the authentication id which was used in the TLS negotiation. 2047 The CUA MUST NOT issue a "STARTTLS" if it has already issued an 2048 "AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does 2049 this the CS must terminate the session. 2051 The following examples illustrate the use of the "STARTTLS" command: 2053 Unsupported TLS: 2055 C: STARTTLS 2056 S: 6.5 2058 Supported TLS: 2060 C: STARTTLS 2061 S: 2.0.12 2062 2063 S: 2.0 2064 S: . 2065 S: . 2067 7.1.10.1. UPNEXPAND Method 2069 Arguments: UPN 2071 Data: no specific data for this command 2073 Result: 2.0 - success 2074 2.1 Permission Denied 2075 2.2 Requested UPN not found 2076 2.3 Result exceeds MAXUPNEXPANDLIST 2077 2.4 Misc. UPNEXPAND error 2079 Return the members of the argument UPN. Successful result yields one or 2080 more CalIDs. More than one CalID returned implies that the UPN was a 2081 UG. 2083 Example #1: Request lookup of a UPN which is a CU 2085 C: UPNEXPAND upn@example.com 2086 S: 2.0 upn@example.com 2087 S: cap://cal.example.com/calid3 2088 S: . 2090 Example #2: Request lookup of UPN which is a UG 2092 Mansour/Dawson/Royer/Taler/Hill 39 Expires September 2000 2093 C: UPNEXPAND group@example.com 2094 S: 2.0 group@example.com 2095 S: cap://cal.example.com/calid3 2096 S: cap://cal.example.com/calid6 2097 S: cap://cal.example.com/calid1342 2098 S: . 2100 Example #3: Request lookup exceeds MAXUPNEXPANDLIST 2102 C: UPNEXPAND group@example.com 2103 S: 2.0 group@example.com 2104 S: cap://cal.example.com/calid3 2105 S: cap://cal.example.com/calid12 2106 S: cap://cal.example.com/calid21 2107 S: cap://cal.example.com/calid33 2108 S: 2.3 Lookup resulted in too much data 2109 S: . 2111 Example #4: CS loses contact with directory server during UPNEXPAND 2113 C: UPNEXPAND group@example.com 2114 S: 2.0 group@example.com 2115 S: cap://cal.example.com/calid3 2116 S: cap://cal.example.com/calid5 2117 S: 2.4 Lost contact with directory server 2118 S: . 2120 7.2. Application Protocol Commands 2122 7.2.1. Calendaring Commands 2124 The following methods provide a set of calendaring commands in CAP. 2125 Calendaring commands (or methods) allow a CU to directly manipulate a 2126 calendar. 2128 Calendar access rights can be granted for the more generalized access 2129 provided by the calendar commands. 2131 7.2.1.1. CREATE Method 2133 Arguments: none 2135 Data: no specific data for this command 2137 Result: 2.0 - successfully created the component or calendar 2138 6.0 - Permission denied 2139 6.1 - Container(s) not found 2140 6.2 - Calendar or component already exists 2141 6.3 - 2142 Bad args 2144 Mansour/Dawson/Royer/Taler/Hill 40 Expires September 2000 2145 The CREATE method is used to create a new iCalendar object of type 2146 objtype. The property TARGET specifies the container(s) for the create. 2147 The type of object wrapped inside of the VCALENDAR/CREATE object is the 2148 object type(s) being created. When creating a new calendar at the top 2149 level, the CSID is specified. Otherwise the container will be a CalID. 2151 7.2.1.1.1. Creating New Calendars 2153 Example to create a new calendar named "Bill's Soccer Team" in several 2154 different containers. In the following example, the client is in the 2155 Authenticated state with CS cal.example.com. 2157 C: SENDDATA 2158 C: CONTENT-TYPE: text/calendar;method=CREATE;component=VCOMMAND 2159 C: Content-Transfer-Encoding:7bit 2160 C: 2161 C: BEGIN:VCALENDAR 2162 C: VERSION:2.1 2163 C: BEGIN:VCOMMAND 2164 C: METHOD:CREATE 2165 C: TARGET:cap://cal.example.com/ 2166 C: TARGET:relcal4 2167 C: TARGET://bobo.ex.com/ 2168 C: TARGET:relcal5 2169 C: TARGET:cap://cal.example.com/relcal8 2170 C: TARGET:relcal9 2171 C: BEGIN:VCALENDAR 2172 C: RELCALID:relcalz 2173 C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Bill's Soccer Team 2174 C: OWNER:bill 2175 C: OWNER:mary 2176 C: CALMASTER:mailto:bill@example.com 2177 C: TZID:US_PST 2178 C: BEGIN:VCAR 2179 C: CARID:12345 2180 C: GRANT:UPN=bill;ACTION=*;OBJECT=* 2181 C: GRANT:UPN=mary;ACTION=read;OBJECT=* 2182 C: END:VCAR 2183 C: END:VCALENDAR 2184 C: END:VCOMMAND 2185 C: END:VCALENDAR 2186 C: . 2187 S: 6.0 cap://cal.example.com/ 2188 S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/relcalz 2189 S: 3.1.4 cap://bobo.ex.com/ 2190 S: 6.2 cap://cal.example.com/relcal5 2191 S: 3.1.5 cap://cal.example.com/relcal8 2192 S: 7.0 cap://cal.example.com/relcal9 2194 If the example above, the Relative CALID is specified. The values for 2195 this property must be unique on a CS. That is the reason for the 3.1.5 2196 error response. 2198 Mansour/Dawson/Royer/Taler/Hill 41 Expires September 2000 2199 In the example below, the Relative CalID is not specified. So, the CAP 2200 server will generate one for each calendar successfully created. The 2201 value of the Relative CalID appears as the second parameter on the 2202 response code. 2204 S: 6.0 cap://cal.example.com/ 2205 S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/rand123 2206 S: 3.1.4 cap://bobo.ex.com/ 2207 S: 6.2 cap://cal.example.com/relcal5 2208 S: 3.1.4 cap://cal.example.com/relcal8 2209 S: 2.0 cap://cal.example.com/relcal9 cap://cal.example.com/rand456 2211 Example to create a new component. 2213 C: SENDDATA 2214 C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII 2215 C: Content-Transfer-Encoding:7bit 2216 C: 2217 C: BEGIN:VCALENDAR 2218 C: VERSION:2.1 2219 C: CMDID:abcde 2220 C: METHOD:CREATE 2221 C: TARGET:cap://cal.foo.com/relcal1 2222 C: TARGET:relcal2 2223 C: BEGIN:VEVENT 2224 C: DTSTART:19990307T180000Z 2225 C: UID:abcd12345 2226 C: DTEND:19990307T190000Z 2227 C: SUMMARY:Important Meeting 2228 C: END:VEVENT 2229 C: END:VCALENDAR 2230 C: . 2231 S: 2.0 2232 S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde" 2233 S: 2234 S: BEGIN:VCALENDAR 2235 S: VERSION:2.1 2236 S: CMDID:abcde 2237 S: METHOD:RESPONSE 2238 S: BEGIN:VEVENT 2239 S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal1 abcd12345 2240 S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal2 abcd12345 2241 S: END:VEVENT 2242 S: END:VCALENDAR 2244 The responce returns the calendar (CALID) and UID of the component so 2245 that the CUA can match up the REQUEST-STATUS from multiple objects 2246 created on multiple calendards (TARGETs). 2248 Mansour/Dawson/Royer/Taler/Hill 42 Expires September 2000 2249 7.2.1.2. DELETE Method 2251 Arguments: none 2253 Data: no specific data for this command 2255 Result: 2.0 - successfully deleted the component or calendar 2256 Permission 2257 Calendar or component not found 2258 Bad args 2259 Container(s) not found 2261 The DELETE method is used to delete a calendar or component. The TARGET 2262 properties specify the container(s) for the delete. When deleting a 2263 calendar at the top level, the CSID is specified. Otherwise the 2264 container will be a CalID. 2266 Example to delete a VEVENT with UID 'abcd12345': 2268 C: SENDDATA 2269 C: Content-Type:text/calendar; method=DELETE; component=VCOMMAND 2270 C: Content-Transfer-Encoding:7bit 2271 C: 2272 C: BEGIN:VCALENDAR 2273 C: BEGIN:VCOMMAND 2274 C: METHOD:DELETE 2275 C: TARGET:cap://cal.foo.com/bill 2276 C: BEGIN:VQUERY 2277 C: SCOPE:VEVENT 2278 C: QUERY SELECT="UID" 2279 C: WHERE (UID EQ abcd12345) 2280 C: END:VQUERY 2281 C: END:VCOMMAND 2282 C: END:VCALENDAR 2283 C: . 2284 S: 2.0 2285 S: . 2287 And an example to delete the 'MrBill' calendar: 2289 C: SENDDATA 2290 C: Content-Type:text/calendar; method=DELETE; component=VCOMMAND 2291 C: Content-Transfer-Encoding:7bit 2292 C: 2293 C: BEGIN:VCALENDAR 2294 C: BEGIN:VCOMMAND 2295 C: METHOD:DELETE 2296 C: TARGET:cap://cal.foo.com/MrBill 2297 C: END:VCOMMAND 2298 C: END:VCALENDAR 2299 C: . 2300 S: 2.0 2301 S: . 2303 Mansour/Dawson/Royer/Taler/Hill 43 Expires September 2000 2304 C: SENDDATA C: 2306 7.2.1.3. GENERATEUID Method 2308 Arguments: Number of UIDs to generate. 2310 Data: new uids 2312 Result: 2.0 2314 GENERATEUID returns one or more new unique identifier which MUST be 2315 unique on the server's calendar store. It is recommended that the return 2316 value be a globally unique id. 2318 Example: 2320 C: GENERATEUID 2 2321 S: 2.0 abcde1234567-asdf-lkhh abcde1234567-asdf-3455 2323 [Editors note: this example needs work. It's not packaged right] 2325 7.2.1.4. MODIFY Method 2327 Arguments: none 2329 Data: no specific data for this command 2331 Result: 2.0 - successfully modified the component or calendar 2332 Permission 2333 Calendar or component not found 2334 Bad args 2335 Container(s) not found 2337 The MODIFY method is used to change an existing calendar or component. 2338 TARGET specify the container(s) of the modification. When modifying a 2339 calendar at the top level, the CSID is specified. Otherwise the 2340 container will be a CalID. 2342 The format of the request is two or three containers inside of a 2343 VCOMMAND container: 2345 BEGIN:VCOMMAND 2346 [VQUERY] 2347 OLD-VALUES 2348 NEW-VALUES 2349 END:VCOMMAND 2351 If a VQUERY is present, then only objects matching the query results are 2352 modified. 2354 In the example below, the start and end time of the event with UID 2355 abcd12345 is changed and the LOCATION property is removed. 2357 Mansour/Dawson/Royer/Taler/Hill 44 Expires September 2000 2358 C: SENDDATA 2359 C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND 2360 C: 2361 C: BEGIN:VCALENDAR 2362 C: VERSION:2.1 2363 C: METHOD:MODIFY 2364 C: TARGET:relcal2 2365 C: BEGIN:VCOMMAND 2366 C: BEGIN:VQUERY 2367 C: SCOPE:VEVENT 2368 C: QUERY:SELECT UID WHERE (UID EQ abcd12345) 2369 C: END:VQUERY 2370 C: BEGIN:VEVENT 2371 C: DTSTART:19990421T160000Z 2372 C: DTEND:19990421T163000Z 2373 C: LOCATION:Joe's Diner 2374 C: END:VEVENT 2375 C: BEGIN:VEVENT 2376 C: DTSTART:19990421T160000Z 2377 C: DTEND:19990421T163000Z 2378 C: END:VEVENT 2379 C: END:VCOMMAND 2380 C: END:VCALENDAR 2381 C: . 2382 S: 2.0 cap://cal.example.com/relcal2 2384 And in this example, all instances of "Building 6" are replaced by "New 2385 office lobby" in VEVENTs: 2387 C: SENDDATA 2388 C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND 2389 C: 2390 C: BEGIN:VCALENDAR 2391 C: VERSION:2.1 2392 C: METHOD:MODIFY 2393 C: TARGET:relcal2 2394 C: BEGIN:VCOMMAND 2395 C: BEGIN:VEVENT 2396 C: LOCATION:Building 6 2397 C: END:VEVENT 2398 C: BEGIN:VEVENT 2399 C: LOCATION:New office lobby 2400 C: END:VEVENT 2401 C: END:VCOMMAND 2402 C: END:VCALENDAR 2403 C: . 2404 S: 2.0 cap://cal.example.com/relcal2 2406 7.2.1.5. MOVE Method 2408 Arguments: ContainerId 2410 Mansour/Dawson/Royer/Taler/Hill 45 Expires September 2000 2411 Data: data as described below 2413 Result: 2.0 - success 2414 2.2 - will attempt operation on the remote cap server 2415 Permission 2416 Calendar already exists 2417 Bad args 2418 Parent Calendar(s) not found 2420 This method is used to move a calendar within the CS's hierarchy of 2421 calendars. 2423 [Editors Note: there could be VCAR issues with this... if a VCAR's scope 2424 of influence is limited to a calendar, we are probably OK. We should 2425 discuss this one] 2427 7.2.1.6. NOOP Method 2429 Arguments: none 2431 Data: none 2433 Result: 2.0 - success 2435 This method does nothing. It can be sent to the server periodically to 2436 request that the CS not time out the session. 2438 7.2.1.7. READ Method 2440 Arguments: ContainerId 2442 Data: data as described below 2444 Result: 2.0 - successful and the requested data follows 2445 2.2 - will attempt read on the remote cap server 2446 Permission 2447 Bad args 2449 Read Events 2451 In the example below events on March 10,1999 between 080000Z and 190000Z 2452 are read. In this case only 4 properties for each event are returned. 2453 Two calendars are specified. Only booked (vs scheduled) entries are to 2454 be returned. 2456 C: SENDDATA 2457 C: Content-type:text/calendar; Method=READ; Component=VQUERY 2458 C: 2459 C: BEGIN:VCALENDAR 2460 C: VERSION:2.1 2461 C: METHOD:READ 2463 Mansour/Dawson/Royer/Taler/Hill 46 Expires September 2000 2464 C: CMDID:xyz12345 2465 C: TARGET:relcal2 2466 C: TARGET:cap://bobo.ex.com/relcal3 2467 C: BEGIN:VQUERY 2468 C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID) 2469 C: FROM VEVENT 2470 C: WHERE (DTEND >= 19990310T080000Z AND 2471 C: DTSTART <= 19990310T190000Z AND 2472 METHOD EQ CREATE) 2473 C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) 2474 C: END:VQUERY 2475 C: END:VCALENDAR 2476 C: . 2477 S: 2.0 cap://cal.example.com/relcal2 2478 S: Content-type:text/calendar; Method=RESPONSE; 2479 S: Optinfo=VERSION:2.1 2480 S: Content-Transfer-Encoding: 7bit 2481 S: 2482 S: BEGIN:VCALENDAR 2483 S: VERSION:2.1 2484 S: METHOD:RESPONSE 2485 S: BEGIN:VEVENT 2486 S: DTSTART:19990310T090000Z 2487 S: DTEND:19990310T100000Z 2488 S: UID:abcxyz12345 2489 S: SUMMARY:Meet with Sir Elton 2490 S: END:VEVENT 2491 S: BEGIN:VEVENT 2492 S: DTSTART:19990310T130000Z 2493 S: DTEND:19990310T133000Z 2494 S: UID:abcxyz8999 2495 S: SUMMARY:Meet with brave brave Sir Robin 2496 S: END:VEVENT 2497 S: END:VCALENDAR 2498 S: . 2499 S: 2.0 cap://bobo.ex.com/relcal3 2500 S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; 2501 S: Optinfo=VERSION:2.1 2502 S: Content-Transfer-Encoding: 7bit 2503 S: 2504 S: BEGIN:VCALENDAR 2505 S: VERSION:2.1 2506 S: METHOD:RESPONSE 2507 S: BEGIN:VDATA 2508 S: BEGIN:VEVENT 2509 S: DTSTART:19990310T140000Z 2510 S: DTEND:19990310T150000Z 2511 S: UID:123456asdf 2512 S: SUMMARY:Summer Budget 2513 S: END:VEVENT 2514 S: END:VDATA 2515 S: END:VCALENDAR 2516 S: . 2518 Mansour/Dawson/Royer/Taler/Hill 47 Expires September 2000 2519 The return values are subject to VCAR filtering. That is, if the request 2520 contains properties to which the UPN does not have access, those 2521 properties will not appear in the return values. If the UPN has access 2522 to at least one property of events, but has been denied access to all 2523 properties called out in the request, the response will contain a single 2524 RESPONSE-CODE property indicating the error. That is, the VEVENT 2525 components will be the following: 2527 S: 2.0 cap://bobo.ex.com/sally 2528 S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; 2529 S: Optinfo=VERSION:2.1 2530 S: Content-Transfer-Encoding: 7bit 2531 S: 2532 S: BEGIN:VCALENDAR 2533 S: VERSION:2.1 2534 S: BEGIN:VDATA 2535 S: BEGIN:VEVENT 2536 S: RESPONSE-CODE:3.8 2537 S: END:VEVENT 2538 S: END:VDATA 2539 S: END:VCALENDAR 2540 S: . 2542 If the UPN has no access to any events at all, the response will simply 2543 be an empty data set. The response looks the same if there are 2544 particular events to which the requester has been denied access. 2546 S: 2.0 cap://bobo.ex.com/sally 2547 S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; 2548 S: Optinfo=VERSION:2.1 2549 S: Content-Transfer-Encoding: 7bit 2550 S: 2551 S: BEGIN:VCALENDAR 2552 S: VERSION:2.1 2553 S: BEGIN:VDATA 2554 S: END:VDATA 2555 S: END:VCALENDAR 2556 S: . 2558 Find alarms within a range of time for booked (METHOD EQ CREATE) 2559 VEVENTs. 2561 C: SENDDATA 2562 C: Content-type:text/calendar; Method=READ; Component=VQUERY 2563 C: 2564 C: BEGIN:VCALENDAR 2565 C: VERSION:2.1 2566 C: METHOD:READ 2567 C: CMDID:xyz12345 2568 C: TARGET:relcal2 2569 C: TARGET:cap://bobo.ex.com/relcal3 2570 C: BEGIN:VQUERY 2571 C: QUERY:SELECT (VEVENT.DTSTART, 2573 Mansour/Dawson/Royer/Taler/Hill 48 Expires September 2000 2574 VEVENT.DTEND,VEVENT.SUMMARY, VEVENT.UID, 2575 VALARM.*) 2576 C: FROM VEVENT,VTODO 2577 C: WHERE (VALARM.TRIGGER >= 19990310T080000Z AND 2578 C: VALARM.TRIGGER <= 19990310T190000Z AND 2579 METHOD EQ CREATE) 2580 C: ORDERBY (VALARM.TRIGGER ASC) 2581 C: END:VQUERY 2582 C: END:VCALENDAR 2583 C: . 2584 S: 2.0 cap://bobo.ex.com/relcal3 2585 S: Content-type:text/calendar; Method=RESPONSE; 2586 S: Optinfo=VERSION:2.1 2587 S: Content-Transfer-Encoding: 7bit 2588 S: 2589 S: BEGIN:VCALENDAR 2590 S: VERSION:2.1 2591 S: METHOD:RESPONSE 2592 S: CMDID:xyz12345 2593 S: TARGET:cap://bobo.ex.com/relcal3 2594 S: BEGIN:VEVENT 2595 S: DTSTART:19990310T130000Z 2596 S: DTEND:19990310T133000Z 2597 S: UID:abcxyz8999 2598 S: SUMMARY:Meet with brave brave Sir Robin 2599 S: BEGIN:VALARM 2600 S: TRIGGER:19990310T132500Z 2601 S: SUMMARY:Almost time.. 2602 S: ACTION:DISPLAY 2603 S: END:VALARM 2604 S: END:VEVENT 2605 S: END:VCALENDAR 2606 S: . 2607 S: 2.0 cap://bobo.ex.com/relcal2 2608 S: Content-type:text/calendar; Method=RESPONSE; 2609 S: Optinfo=VERSION:2.1 2610 S: Content-Transfer-Encoding: 7bit 2611 S: 2612 S: BEGIN:VCALENDAR 2613 S: VERSION:2.1 2614 S: METHOD:RESPONSE 2615 S: CMDID:xyz12345 2616 S: TARGET:cap://bobo.ex.com/relcal2 2617 S: BEGIN:VEVENT 2618 S: REQUEST-STATUS:2.0 2619 S: END:VEVENT 2620 S: END:VCALENDAR 2621 S: . 2623 Mansour/Dawson/Royer/Taler/Hill 49 Expires September 2000 2624 7.2.2. Scheduling Commands 2626 The following provide a set of scheduling commands (or methods) in CAP. 2627 Scheduling commands allow a CU to indirectly manipulate a calendar by 2628 asking another CU to perform an operation on their calendar. For 2629 example, CU-A can request CU-B to add a meeting to their calendar; in 2630 effect inviting CU-B to the meeting. 2632 Calendar access rights can be granted for scheduling commands without 2633 granting rights for more generalized access with the calendar commands. 2635 [Editors Note: This section needs to be completed by adding the 2636 restriction tables for each of these iTIP methods. The basis for the 2637 text is to be taken from [RFC2446].] 2639 7.2.2.1. Reading out scheduling components 2641 A CU might be invided to a meeting. If the CU had been invided by CAP, 2642 the entry in the CU calendar will be scheduled, but not booked. So a 2643 CUA will need to look for scheduled entries in the calendar and present 2644 them to the CU or automaticly decide if the invitation is to be acceped 2645 or processed. 2647 Example: The little league coach places the teams entire schedule into 2648 your calendar. Lets say that every game and practice is on a Firday 2649 night and your calendar now has this iTIP scheduling data: 2651 BEGIN:VCALENDAR 2652 VERSION:2.0 2653 METHOD:PUBLISH 2654 BEGIN:VEVENT 2655 DTSTAMP;TZID=US/Pacific:20000229T180000 2656 DTSTART;TZID=US/Pacific:20000303T180000 2657 ORGANIZER:coach@little.league.com 2658 SUMMARY: Schedule of games and practice 2659 UID:1-coarch@little.league.com 2660 SEQUENCE:0 2661 DESCRIPTION:Please have your child at the field 2662 and ready to play by 6pm. 2663 RRULE:FREQ=WEEKLY;COUNT=10 2664 END:VEVENT 2665 END:VCALENDAR 2667 At this point the above VEVENT is not booked in your calendar, It is 2668 simpley scheduled. A CUA would fetch this and all other scheduled 2669 VEVENTs from your calendar with: 2671 C: SENDDATA 2672 C: Content-type:text/calendar; Method=READ; Component=VQUERY 2673 C: 2674 C: BEGIN:VCALENDAR 2675 C: VERSION:2.1 2677 Mansour/Dawson/Royer/Taler/Hill 50 Expires September 2000 2678 C: METHOD:READ 2679 C: CMDID:xyz12345 2680 C: TARGET:relcal2 2681 C: BEGIN:VQUERY 2682 C: QUERY:SELECT (VEVENT.*) 2683 C: FROM VEVENT 2684 C: WHERE (METHOD != CREATE) 2685 C: END:VQUERY 2686 C: END:VCALENDAR 2687 C: . 2689 The the CUA and CU could determine which scheduling items were to remain 2690 on the calendar. Each scheduling component could be deleted or updated 2691 with METHOD:MODIFY to change the METHOD from PUBLISH, REQUEST, REPLY, 2692 ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to what the CU and CUA 2693 had decided. 2695 In some cases the CUA could automaticly do the work and inform the CU. 2696 An example of this is CANCEL. If configured to process METHOD:CANCEL it 2697 could METHOD:DELETE the component an inform the CU that the booked 2698 component had been canceled. 2700 The CUA MUST process the scheduled components in the order sent. Some 2701 optimization could be done by the CUA. One example is if a PUBLISH and 2702 later a CANCEL for the same component with the same SEQUENCE number were 2703 scheduled, but not booked. The CUA might never inform the CU and just 2704 treat it as if the PUBLISH had never been received by doing a 2705 METHOD:DELETE on both entries. 2707 It is important to note that scheduled components do not show up in busy 2708 time as BUSY. Only when they are booked does the TRANSP:OPAQUE property 2709 take effect. A CS implementation could mark the time as TENTATIVE. 2710 This is an implementation and administrative choice. 2712 7.2.2.2. PUBLISH 2714 Arguments: 2716 Data: data as described below 2718 Result: 2.0 - success 2719 2.2 - will attempt operation on the remote cap server 2720 Permission 2721 Calendar already exists 2722 Bad args 2723 Parent Calendar(s) not found 2725 This method is used to move a calendar within the CS's hierarchy of 2726 calendars. If the CU wishes to keep the published entry. A 2727 METHOD:MODIFY changing the entries METHOD from PUBLISH to CREATE would 2728 be done, booking the entry. Or METHOD:DELETE if the CU did not wish 2729 this scheduled item to exist in their calendar. 2731 Mansour/Dawson/Royer/Taler/Hill 51 Expires September 2000 2732 7.2.2.3. REQUEST 2734 7.2.2.4. REPLY 2736 7.2.2.5. ADD 2738 7.2.2.6. CANCEL 2740 7.2.2.7. REFRESH 2742 7.2.2.8. COUNTER 2744 7.2.2.9. DECLINECOUNTER 2746 7.2.3. iTIP Examples 2748 The following examples describe scenarios for the handling of incoming 2749 iTIP data. An appropriate sort-order for the handling of incoming iTIP 2750 is by UID, Recurrence-id, sequence, dtstamp. This processing may be 2751 optimized, for instance, REFRESHs could be processed last. 2753 As an update to [RFC2446], data with the "COUNTER" method should be 2754 processed even if the Sequence number is stale. 2756 7.2.3.1. Sending and Receiving an iTIP request 2758 In this example A invites B and C to a meeting, B accepts the meeting 2759 and C rejects it. The calendars for A, B and C are relcal1, relcal2 and 2760 relcal3 respectively, and are all on the same server, "cal.foo.com". A 2761 lot of these described actions are performed by the CUAs and not the 2762 users themselves, the CUAs are called A-c, B-c and C-c respectively. 2764 A wishes to create a meeting with B and C, so A-c uses CAP to send the 2765 following iTIP request to relcal2 and relcal3, while logged in to 2766 "cal.foo.com". 2768 BEGIN:VCALENDAR 2769 VERSION:2.1 2770 CMDID:xhj-dd 2771 METHOD:REQUEST 2772 TARGET:cap://cal.foo.com/relcal2 2773 TARGET:relcal3 2774 BEGIN:VEVENT 2775 UID:abcd12345 2776 DTSTART:19990307T180000Z 2778 Mansour/Dawson/Royer/Taler/Hill 52 Expires September 2000 2779 DTEND:19990307T190000Z 2780 ORGANIZER:cap://cal.foo.com/relcal1 2781 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal2 2782 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 2783 SUMMARY:Important Meeting 2784 END:VEVENT 2785 END:VCALENDAR 2787 An incoming event (indicated by the value of the "METHOD" property) then 2788 appears in relcal2 and relcal3, with the following data: 2790 BEGIN:VEVENT 2791 METHOD:REQUEST 2792 UID:abcd12345 2793 DTSTART:19990307T180000Z 2794 DTEND:19990307T190000Z 2795 ORGANIZER:cap://cal.foo.com/relcal1 2796 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal2 2797 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 2798 SUMMARY:Important Meeting 2799 END:VEVENT 2801 B-c and C-c must search for such incoming events, they do so using the 2802 following CAP search: 2804 BEGIN:VCALENDAR 2805 VERSION:2.1 2806 METHOD:READ 2807 CMDID:xhr-de 2808 TARGET:relcal2 2809 # or TARGET:relcal3 2810 BEGIN:VQUERY 2811 QUERY:SELECT (ALL); 2812 FROM VEVENT; 2813 WHERE (METHOD == REQUEST); 2814 END:VQUERY 2815 END:VCALENDAR 2817 In response to this search they get the above event. B-c and C-c must 2818 then crack open the VEVENT, find the UID and determine if there is 2819 already an event on their calendar with that UID. To do this they use 2820 the following search: 2822 BEGIN:VCALENDAR 2823 VERSION:2.1 2824 METHOD:READ 2825 CMDID:xhr-df 2826 TARGET:relcal2 2827 BEGIN:VQUERY 2828 QUERY:SELECT (*) 2829 FROM VEVENT 2830 WHERE (UID == abcd12345 AND METHOD == CREATE) 2831 END:VQUERY 2833 Mansour/Dawson/Royer/Taler/Hill 53 Expires September 2000 2834 END:VCALENDAR 2836 We assume that the event is not already in their relcal2 or relcal3. 2838 B-c prompts B who decides to accept the meeting request, and B-c creates 2839 a copy of the event in relcal2, with the "PARTSTAT" parameter set to 2840 ACCEPTED. B-c also sends this copy to the Organizer at relcal1 as an 2841 iTIP REPLY, preserving the CMDID: 2843 BEGIN:VCALENDAR 2844 VERSION:2.1 2845 CMDID:xhj-dd 2846 METHOD:REPLY 2847 TARGET:cap://cal.foo.com/relcal1 2848 BEGIN:VEVENT 2849 UID:abcd12345 2850 DTSTART:19990307T180000Z 2851 DTEND:19990307T190000Z 2852 ORGANIZER:cap://cal.foo.com/relcal1 2853 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 2854 SUMMARY:Important Meeting 2855 END:VEVENT 2856 END:VCALENDAR 2858 C, on the other hand, decides to decline the meeting, and C-c sends a 2859 reply to the Organizer to that effect, as follows: 2861 BEGIN:VCALENDAR 2862 VERSION:2.1 2863 CMDID:xhj-dd 2864 METHOD:REPLY 2865 TARGET:cap://cal.foo.com/relcal1 2866 BEGIN:VEVENT 2867 UID:abcd12345 2868 DTSTART:19990307T180000Z 2869 DTEND:19990307T190000Z 2870 ORGANIZER:cap://cal.foo.com/relcal1 2871 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 2872 SUMMARY:Important Meeting 2873 END:VEVENT 2874 END:VCALENDAR 2876 It is preferable that C-c store the event in relcal3 even though it has 2877 been declined. Storing the event in relcal3 allows subsequent iTIP 2878 messages to be interpreted correctly. The "PARTSTAT" parameter indicates 2879 that the event was refused. 2881 After receiving the replies from relcal2 and relcal3, A-c updates the 2882 version of the event in relcal1 to indicate the new participation 2883 statii: 2885 BEGIN:VEVENT 2886 METHOD:REQUEST 2888 Mansour/Dawson/Royer/Taler/Hill 54 Expires September 2000 2889 UID:abcd12345 2890 DTSTART:19990307T180000Z 2891 DTEND:19990307T190000Z 2892 ORGANIZER:cap://cal.foo.com/relcal1 2893 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 2894 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 2895 SUMMARY:Important Meeting 2896 END:VEVENT 2898 A-c then sends a new iTIP request to relcal2 only, indicating the 2899 updated information. 2901 7.2.3.2. Handling an iTIP refresh 2903 A little bit later, C is thinking about accepting the event in the 2904 previous example, but first wants to check the current state of the 2905 event. To find the current state C-c uses the iTIP "REFRESH" method, 2906 sending the following to relcal1: 2908 BEGIN:VCALENDAR 2909 VERSION:2.1 2910 CMDID:xud-pn 2911 METHOD:REFRESH 2912 TARGET:cap://cal.foo.com/relcal1 2913 BEGIN:VEVENT 2914 UID:abcd12345 2915 ORGANIZER:cap://cal.foo.com/relcal1 2916 ATTENDEE:cap://cal.foo.com/relcal3 2917 DTSTAMP:19990306T202333Z 2918 END:VEVENT 2919 END:VCALENDAR 2921 A-c finds the refresh as an incoming iTIP, and searches for the 2922 corresponding event. Having found the event (with no changes since the 2923 last example) A-c then verifies that relcal3 is in fact an Attendee of 2924 the event and is thus allowed to request a refresh. (In the case of a 2925 published event things are more complicated.) A-c packages the event up 2926 as an iTIP request and sends it to relcal3: 2928 BEGIN:VCALENDAR 2929 VERSION:2.1 2930 CMDID: xud-pn 2931 METHOD:REQUEST 2932 TARGET:cap://cal.foo.com/relcal3 2933 BEGIN:VEVENT 2934 UID:abcd12345 2935 DTSTART:19990307T180000Z 2936 DTEND:19990307T190000Z 2937 ORGANIZER:cap://cal.foo.com/relcal1 2938 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 2939 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 2940 SUMMARY:Important Meeting 2942 Mansour/Dawson/Royer/Taler/Hill 55 Expires September 2000 2943 SEQUENCE:0 2944 DTSTAMP:19990306T204333Z 2945 END:VEVENT 2946 END:VCALENDAR 2948 [Ed. - should the CMDID match that of the REFRESH?] 2950 7.2.3.3. Sending and accepting an iTIP counter 2952 Having received the latest copy of the event C wishes to propose a venue 2953 for the event, using an iTIP COUNTER. To do this C-c sends the following 2954 to relcal1: 2956 BEGIN:VCALENDAR 2957 VERSION:2.1 2958 CMDID:zzykjjk 2959 METHOD:COUNTER 2960 TARGET:cap://cal.foo.com/relcal1 2961 BEGIN:VEVENT 2962 UID:abcd12345 2963 DTSTART:19990307T180000Z 2964 DTEND:19990307T190000Z 2965 ORGANIZER:cap://cal.foo.com/relcal1 2966 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 2967 SUMMARY:Important Meeting 2968 LOCATION:La Belle Province 2969 COMMENT:My favourite restaurant, I'll definitely go if it's there. 2970 END:VEVENT 2971 END:VCALENDAR 2973 Having sent the information to relcal1, C-c shouldn't store the new 2974 details in relcal3. If C-c updated the version in relcal3 and relcal1 2975 did not reply to the counter, then relcal3 would have incorrect 2976 information. Instead C-c preserves the correct information and waits for 2977 a response from relcal1. A CUA implementation may wish to preserve this 2978 information itself, externally to the CS. 2980 In order to receive an iTIP counter A-c follows the same search as for 2981 other iTIP data, first find the incoming message, next find any matching 2982 events in the calendar store. 2984 Having found the matching event, A reviews the proposed changes and 2985 decides to accept the COUNTER. To do this, A-c modifies the version in 2986 relcal1 (bumping the sequence number) to: 2988 BEGIN:VEVENT METHOD:CREATE UID:abcd12345 DTSTART:19990307T180000Z 2989 DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 2990 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 2991 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 SUMMARY:Important 2992 Meeting LOCATION:La Belle Province SEQUENCE:1 END:VEVENT 2994 A-c then sends the updated version as a request to both relcal2 and 2996 Mansour/Dawson/Royer/Taler/Hill 56 Expires September 2000 2997 relcal3: 2999 BEGIN:VCALENDAR 3000 VERSION:2.1 3001 CMDID:xup-po 3002 METHOD:REQUEST 3003 TARGET:cap://cal.foo.com/relcal2 3004 TARGET:cap://cal.foo.com/relcal3 3005 BEGIN:VEVENT 3006 UID:abcd12345 3007 DTSTART:19990307T180000Z 3008 DTEND:19990307T190000Z 3009 ORGANIZER:cap://cal.foo.com/relcal1 3010 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal2 3011 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 3012 SUMMARY:Important Meeting 3013 LOCATION:La Belle Province 3014 SEQUENCE:1 3015 DTSTAMP:19990307T054339Z 3016 END:VEVENT 3017 END:VCALENDAR 3019 7.2.3.4. Declining an iTIP counter 3021 B does not like the new location and also counters the event, B-c sends 3022 the following iTIP: 3024 BEGIN:VCALENDAR 3025 VERSION:2.1 3026 CMDID:xim-ef 3027 METHOD:COUNTER 3028 TARGET:cap://cal.foo.com/relcal1 3029 BEGIN:VEVENT 3030 UID:abcd12345 3031 DTSTART:19990307T180000Z 3032 DTEND:19990307T190000Z 3033 ORGANIZER:cap://cal.foo.com/relcal1 3034 ATTENDEE:cap://cal.foo.com/relcal2 3035 SUMMARY:Important Meeting 3036 LOCATION:Au Coin Dor=E9 3037 END:VEVENT 3038 END:VCALENDAR 3040 However, C does not accept the counter, and C-c replies with a decline 3041 counter: 3043 BEGIN:VCALENDAR 3044 VERSION:2.1 3045 CMDID:xim-ef 3046 METHOD:DECLINE-COUNTER 3047 TARGET:cap://cal.foo.com/relcal2 3048 BEGIN:VEVENT 3050 Mansour/Dawson/Royer/Taler/Hill 57 Expires September 2000 3051 DTSTAMP:19990307T093245Z 3052 UID:abcd12345 3053 ORGANIZER:cap://cal.foo.com/relcal1 3054 SEQUENCE:1 3055 END:VEVENT 3056 END:VCALENDAR 3058 Fortunately B-c kept the original information when sending the counter, 3059 and there is no problem when no information is returned in the DECLINE- 3060 COUNTER. 3062 8. Response Codes 3063 Numeric response codes are returned at both the transfer and application 3064 layer. The same set of codes is used in both cases. 3066 [Editors Note: Do we want to use the same set of codes?] 3068 The format of these codes is described in [RFC2445], and extend in 3069 [RFC2446] and [RFC2447]. The following describes new codes added to this 3070 set. 3072 At the application layer response codes are returned as the value of a 3073 "REQUEST-STATUS" property. The value type of this property is modified 3074 from that defined in [RFC2445], to make the accompanying text optional. 3076 Code Params Description 3077 ---------------------------------------------------------- 3078 2.0 varies Success, The parameters vary with the 3079 operation and are specified. 3081 2.0.1 none Success, send data, terminate with 3082 . 3084 2.0.2 A reply is pending. It could not be com- 3085 pleted in the specified amount of time. 3086 The server awaits a CONTINUE or ABORT 3087 command. 3089 2.0.3 In response to the client issuing an 3090 ABORT command, this reply code indicates 3091 that any command currently underway was 3092 successfully aborted. 3094 Mansour/Dawson/Royer/Taler/Hill 58 Expires September 2000 3095 2.0.6 An operation is being attempted on a re- 3096 mote server. This response indicates 3097 that the server has not yet been con- 3098 tacted but an attempt will be made to 3099 contact it after the command has been 3100 sent. 3102 3.1.4 Capability not supported. 3104 4.1 Calendar store access denied. 3106 6.1 Authenticate failure: unsupported au- 3107 thentication mechanism, credentials re- 3108 jected. 3110 6.2 Sender aborted authentication, authenti- 3111 cation exchange cancelled. 3113 6.3 Attempt to create or modify an event 3114 such that it would overlap another event 3115 in either of the following two circum- 3116 stances: 3118 (a) One of the events has a TRANSP prop- 3119 erty set to OPAQUE-NOCONFLICT or TRANS- 3120 PARENT-NOCONFLICT. 3122 (b) The calendar's ALLOW-CONFLICT prop- 3123 erty is set to NO. 3125 7.0 A timeout has occurred. The server was 3126 unable to complete the operation in the 3127 requested time. 3129 8.0 A failure has occurred in the Receiver 3130 that prevents the operation from suc- 3131 ceeding. 3133 8.1 Sent when a session cannot be estab- 3134 lished because the CAP Server is too 3135 busy. 3137 8.2 Used to signal that an ICAL object has 3138 exceeded the server's size limit 3140 8.3 A DATETIME value was too large to be 3141 represented on this Calendar. 3143 8.4 A DATETIME value was too far in the past 3144 to be represented on this Calendar. 3146 Mansour/Dawson/Royer/Taler/Hill 59 Expires September 2000 3147 8.5 An attempt was made to create a new ob- 3148 ject but the unique id specified is al- 3149 ready in use. 3151 8.6 ID clash 3153 9.0 An unrecognized command was received. 3155 10.1 Accompanied by an alternate address. The 3156 RECIPIENT specified should be contacted 3157 at the given alternate address. The re- 3158 ferral address MUST follow the reply 3159 code. 3161 10.2 The server is shutting down. 3163 10.4 The operation has not be performed be- 3164 cause it would cause the resources (mem- 3165 ory, disk,CPU, etc) to exceed the allo- 3166 cated quota. 3168 10.5 The ITIP message has been queued too too 3169 long. Delivery has been aborted. 3170 ---------------------------------------------------------- 3172 8.1. Minimum CS query implementation 3173 The following is a MUST for a CS implementation. 3175 8.1.1. Query by UID 3176 3178 8.1.2. Query by Date / Date-Time range 3179 3181 8.1.2.1. Date/Date-Time query with subset of properties 3182 3184 8.1.3. 3185 3187 9. Detailed SQL Schema 3189 This section describes a conceptual schema for object model in CAP. It 3190 is used as the basis for querying data managed by the CS. This is only a 3191 conceptual schema. Implementations can use any schema they like so long 3192 as they are prepared to map CAP queries that are expressed in this 3193 conceptual schema. Implementations are not required to use SQL database 3194 technology. The protocol is designed such that a CUA does not need to 3196 Mansour/Dawson/Royer/Taler/Hill 60 Expires September 2000 3197 understand SQL. The CUA just sends strings that happen to be valid SQL 3198 queries. 3200 This schema is based on SQL-92 [SQL] along with the [SQLCOM] 3201 corrections. 3203 Properties than can occur multiple times are intended to be put in 3204 separate tables. For example 3206 BEGIN:VEVENT 3207 UID:1 3208 DTSTART:19990326T201400Z 3209 ORGANIZER:mailto:sam@abc.COM 3210 SUMMARY:I have 2 attachments 3211 ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell.au 3212 ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell2.au 3213 END:VEVENT 3215 There are two ATTACHMENT properties each having a unique value. These 3216 are kept in separate tables. This is diagrammed below. The diagram is 3217 not a complete representation of the VEVENT table. It is an abbreviated 3218 table used to illustrate how properties that can occur multiple times 3219 are intended to be represented. 3221 +----------------------------------------------------------------------+ 3222 | ABBREVIATED VEVENT TABLE | 3223 +----+-----------------+---------------------+--------------+----------+ 3224 | | | | | | 3225 |UID |DTSTART |ORGANIZER |SUMMARY |ATTACH_KEY| 3226 +----+-----------------+---------------------+--------------+----------+ 3227 |1 |19990326T201400Z |mailto:sam@abc.com |I have 2 at- |123 | 3228 | | | |tachments | | 3229 +----+-----------------+---------------------+--------------+----------+ 3230 |999 |19700101T000000Z |mailto:user@host.com |I have no | | 3231 | | | |attachments | | 3232 +----+-----------------+---------------------+--------------+----------+ 3234 Mansour/Dawson/Royer/Taler/Hill 61 Expires September 2000 3235 +-----------------------------------------------------------------------+ 3236 | ABBREVIATED ATTACH_KEY TABLE | 3237 +------------+------------------------------------+---------------------+ 3238 | | | | 3239 |ATTACH_KEY |VALUE | INLINE_BLOB | 3240 +------------+------------------------------------+---------------------+ 3241 |123 |ftp://host.com/pub/sounds/bell.au | | 3242 +------------+------------------------------------+---------------------+ 3243 |123 |ftp://host.com/pub/sounds/bell2.au | | 3244 +------------+------------------------------------+---------------------+ 3245 |234 | | MIICajCCAdO-gAw- | 3246 | | | IBAgICBEU <...re- | 3247 | | | mainder of "BASE64" | 3248 | | | encoded binary da- | 3249 | | | ta...> | 3250 +------------+------------------------------------+---------------------+ 3252 9.1. iCalendar Store Schema 3254 The following defines the schema for an iCalendar object and the 3255 components, properties, and parameters defined and used in [RFC2445], 3256 [RFC2446], [RFC2447], and [CAP]. 3258 NOTES: 3260 CURRENT_DATETIME would not be stored in the database. It 3261 is selectable and read only. 3263 When supporting virtual hosts, there could be more than 3264 one row in the CALSTORE table. And then the CSID MUST 3265 not be empty. 3267 TIMESTAMP(14) is the SQL value equivelant of DATE-TIME. 3269 FLOAT(7,3) is an SQL 3x3 floating number (xxx.yyy). 3271 9.1.1. ACTION schema 3273 /* 3274 * If VALUE is NULL, then OTHER_VALUE contains non-rfc2445 value . 3275 */ 3276 CREATE TABLE ACTION ( 3277 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3278 VALUE ENUM("AUDIO", "DISPLAY", "EMAIL", 3279 "PROCEDURE") NOT NULL, 3280 OTHER_VALU TEXT, 3281 XPARAM INTEGER /* VALUE_KEY */ 3282 ); 3284 Mansour/Dawson/Royer/Taler/Hill 62 Expires September 2000 3285 9.1.2. ATTACH schema 3287 /* 3288 * VALUE is a FILE uri. The data is decoded (per ENCODING) prior to being 3289 * stored into the file 3290 */ 3291 CREATE TABLE ATTACH ( 3292 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3293 VALUE VARCHAR(255) NOT NULL, 3294 ISBINARY ENUM("T", "F") DEFAULT "F", 3295 FMTTYPE INTEGER, /* VALUE_KEY */ 3296 XPARAM INTEGER /* VALUE_KEY */ 3297 ); 3299 9.1.3. ATTENDEE schema 3301 CREATE TABLE ATTENDEE ( 3302 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3303 VALUE TEXT, 3304 CUTYPE INTEGER, /* VALUE_KEY */ 3305 MEMBER INTEGER, /* VALUE_KEY */ 3306 ROLE INTEGER, /* VALUE_KEY */ 3307 PARTSTAT INTEGER, /* VALUE_KEY */ 3308 RSVP ENUM("T", "F") DEFAULT "F", 3309 DELEGATED_TO INTEGER, /* VALUE_KEY */ 3310 DELEGATED_FROM INTEGER, /* VALUE_KEY */ 3311 CN INTEGER, /* VALUE_KEY */ 3312 DIR INTEGER, /* VALUE_KEY */ 3313 LANGUAGE INTEGER, /* VALUE_KEY */ 3314 XPARAM INTEGER /* VALUE_KEY */ 3315 ); 3317 9.1.4. CALSTORE schema 3319 CREATE TABLE CALSTORE ( 3320 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3321 CSID VARCHAR(255) NOT NULL, 3322 CALMASTER TINYTEXT NOT NULL, 3323 DEFAULT_VCAR INTEGER, /* VALUE_KEY */ 3324 MAXDATE TIMESTAMP(14) NOT NULL 3325 DEFAULT "99991231235959", 3326 MINDATE TIMESTAMP(14) NOT NULL 3327 DEFAULT "00000101000000", 3328 CURRENT_DATETIME TIMESTAMP(14) NOT NULL, 3329 RECUR_ACCEPTED ENUM("T", "F") NOT NULL DEFAULT "T", 3330 RECUR_EXPAND ENUM("T", "F") NOT NULL DEFAULT "T", 3331 RECUR_LIMIT INTEGER DEFAULT 0, 3332 VERSION VARCHAR(10) NOT NULL DEFAULT "2.0" 3333 ); 3335 Mansour/Dawson/Royer/Taler/Hill 63 Expires September 2000 3336 9.1.5. CHILDREN schema 3338 CREATE TABLE CHILDREN ( 3339 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, /* KEY_VALUE */ 3340 CALID VARCHAR(255) 3341 ); 3343 9.1.6. CLASS schema 3345 CREATE TABLE CLASS ( 3346 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3347 VALUE ENUM("PUBLIC", "PRIVATE", 3348 "CONFIDENTIAL", 3349 "") NOT NULL, 3350 OTHER_VALUE TEXT, 3351 XPARAM INTEGER /* VALUE_KEY */ 3352 ); 3354 9.1.7. CN schema 3356 CREATE TABLE CN ( 3357 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3358 VALUE VARCHAR(255) NOT NULL 3359 ); 3361 9.1.8. COMMENT schema 3363 CREATE TABLE COMMENT ( 3364 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3365 VALUE TEXT NOT NULL, 3366 ALTREP INTEGER, /* VALUE_KEY */ 3367 LANGUAGE INTEGER, /* VALUE_KEY */ 3368 XPARAM INTEGER /* VALUE_KEY */ 3369 ); 3371 9.1.9. CONTACT schema 3373 CREATE TABLE CONTACT ( 3374 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3375 VALUE TINYTEXT NOT NULL, 3376 ALTREP VARCHAR(255), 3377 LANGUAGE INTEGER, /* VALUE_KEY */ 3378 XPARAM INTEGER /* VALUE_KEY */ 3379 ); 3381 Mansour/Dawson/Royer/Taler/Hill 64 Expires September 2000 3382 9.1.10. CREATED schema 3384 CREATE TABLE CREATED ( 3385 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3386 VALUE TIMESTAMP(14) NOT NULL, 3387 VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ 3388 TZID INTEGER, /* VALUE_KEY */ 3389 XPARAM INTEGER /* VALUE_KEY */ 3390 ); 3392 9.1.11. CUTYPE schema 3394 CREATE TABLE CUTYPE ( 3395 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3396 VALUE ENUM("INDIVIDUAL", 3397 "GROUP", 3398 "RESOURCE", 3399 "ROOM", 3400 "UNKNOWN", 3401 "") NOT NULL, 3402 OTHER_VALUE TINYTEXT 3403 ); 3405 9.1.12. DAYLIGHT_STANDARD schema 3407 CREATE TABLE DAYLIGHT_STANDARD ( 3408 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3409 DTSTART INTEGER NOT NULL, /* VALUE_KEY */ 3410 TZOFFSETFROM INTEGER NOT NULL, /* SECONDS */ 3411 TZOFFSETTO INTEGER NOT NULL, /* SECONDS */ 3412 COMMENT INTEGER, /* VALUE_KEY */ 3413 RDATE INTEGER, /* VALUE_KEY */ 3414 RRULE INTEGER, /* VALUE_KEY */ 3415 TZNAME TINYTEXT, 3416 XPROP INTEGER /* VALUE_KEY */ 3417 ); 3419 9.1.13. DESCRIPTION schema 3421 CREATE TABLE DESCRIPTION ( 3422 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3423 VALUE TEXT, 3424 ALTREP INTEGER, /* VALUE_KEY */ 3426 Mansour/Dawson/Royer/Taler/Hill 65 Expires September 2000 3427 LANGUAGE INTEGER, /* VALUE_KEY */ 3428 XPARAM INTEGER /* VALUE_KEY */ 3429 ); 3431 9.1.14. DIR schema 3433 CREATE TABLE DIR ( 3434 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3435 VALUE TEXT 3436 ); 3438 9.1.15. DTEND schema 3440 CREATE TABLE DTEND ( 3441 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3442 VALUE TIMESTAMP(14) NOT NULL, 3443 VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ 3444 TZID INTEGER, /* VALUE_KEY */ 3445 XPARAM INTEGER /* VALUE_KEY */ 3446 ); 3448 9.1.16. DTSTAMP schema 3450 CREATE TABLE DTSTART ( 3451 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3452 VALUE TIMESTAMP(14) NOT NULL, 3453 VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ 3454 TZID INTEGER, /* VALUE_KEY */ 3455 XPARAM INTEGER /* VALUE_KEY */ 3456 ); 3458 9.1.17. DUE schema 3460 CREATE TABLE DUE ( 3461 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3462 VALUE TIMESTAMP(14) NOT NULL, 3463 VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ 3464 TZID INTEGER, /* VALUE_KEY */ 3465 XPARAM INTEGER /* VALUE_KEY */ 3466 ); 3468 Mansour/Dawson/Royer/Taler/Hill 66 Expires September 2000 3469 9.1.18. DURATION schema 3471 CREATE TABLE DURATION ( 3472 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3473 VALUE INTEGER, /* SECONDS */ 3474 XPARAM INTEGER /* VALUE_KEY */ 3475 ); 3477 9.1.19. EXDATE schema 3479 CREATE TABLE EXDATE ( 3480 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3481 VALUE TIMESTAMP(14) NOT NULL, 3482 VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ 3483 TZID INTEGER, /* VALUE_KEY */ 3484 XPARAM INTEGER /* VALUE_KEY */ 3485 ); 3487 9.1.20. EXRULE schema 3489 CREATE TABLE EXRULE ( 3490 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3491 VALUE INTEGER NOT NULL, /* VALUE_KEY (RECUR) */ 3492 XPARAM INTEGER /* VALUE_KEY */ 3493 ); 3495 9.1.21. FBTYPE schema 3497 CREATE TABLE FBTYPE ( 3498 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3499 VALUE ENUM("FREE", "BUSY", 3500 "BUSY-UNAVALIBLE", 3501 "BUSY-TENTATIVE", 3502 "") NOT NULL, 3503 OTHER_VALUE TINYTEXT 3504 ); 3506 9.1.22. FMTTYPE schema 3508 CREATE TABLE FMTTYPE ( 3509 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3510 VALUE TINYTEXT 3511 ); 3513 Mansour/Dawson/Royer/Taler/Hill 67 Expires September 2000 3514 9.1.23. FREEBUSY schema 3516 CREATE TABLE FREEBUSY ( 3517 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3518 VALUE_FROM TIMESTAMP(14) NOT NULL, 3519 VALUE_TO TIMESTAMP(14), 3520 DURATION INTEGER, /* SECONDS */ 3521 XPARAM INTEGER /* VALUE_KEY */ 3522 ); 3524 9.1.24. GEO schema 3526 CREATE TABLE GEO ( 3527 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3528 LATITUDE FLOAT(7,3), 3529 LONGITUDE FLOAT(7,3), 3530 XPARAM INTEGER /* VALUE_KEY */ 3531 ); 3533 9.1.25. LANGUAGE schema 3535 CREATE TABLE LANGUAGE ( 3536 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3537 VALUE TINYTEXT 3538 ); 3540 9.1.26. LAST_MODIFIED schema 3542 CREATE TABLE LAST_MODIFIED ( 3543 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3544 VALUE TIMESTAMP(14) NOT NULL, 3545 XPARAM INTEGER /* VALUE_KEY */ 3546 ); 3548 9.1.27. MEMBER schema 3550 CREATE TABLE MEMBER ( 3551 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3552 VALUE TEXT 3553 ); 3555 Mansour/Dawson/Royer/Taler/Hill 68 Expires September 2000 3556 9.1.28. METHOD schema 3558 CREATE TABLE METHOD ( 3559 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3560 VALUE ENUM("PUBLISH", 3561 "REQUEST", 3562 "REFRESH", 3563 "CANCEL", 3564 "ADD", 3565 "REPLY", 3566 "COUNTER", 3567 "DECLINE-COUNTER", 3568 "CREATE", 3569 "DELETE", 3570 "MODIFY", 3571 "MOVE", 3572 "READ", 3573 "") NOT NULL, 3574 OTHER_VALUE TEXT 3575 ); 3577 9.1.29. ORGANIZER schema 3579 CREATE TABLE ORGANIZER ( 3580 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3581 VALUE TEXT NOT NULL, 3582 CN INTEGER, /* VALUE_KEY */ 3583 DIR INTEGER, /* VALUE_KEY */ 3584 SENT_BY INTEGER, /* VALUE_KEY */ 3585 LANGUAGE INTEGER, /* VALUE_KEY */ 3586 XPARAM INTEGER /* VALUE_KEY */ 3587 ); 3589 9.1.30. OWNERS schema 3591 CREATE TABLE OWNERS ( 3592 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3593 VALUE TINYTEXT NOT NULL 3594 ); 3596 9.1.31. PARTSTAT schema 3598 CREATE TABLE PARTSTAT ( 3599 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3600 VALUE ENUM("NEEDS-ACTION", 3601 "ACCEPTED", 3602 "DECLINED", 3604 Mansour/Dawson/Royer/Taler/Hill 69 Expires September 2000 3605 "TENTATIVE", 3606 "DELEGATED", 3607 "COMPLETED", 3608 "IN-PROCESS", 3609 "") 3610 NOT NULL DEFAULT "NEEDS-ACTION", 3611 OTHER_VALUE TINYTEXT 3612 ); 3614 9.1.32. PERCENT_COMPLETE schema 3616 CREATE TABLE PERCENT_COMPLETE ( 3617 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3618 VALUE INTEGER NOT NULL, 3619 XPARAM INTEGER /* VALUE_KEY */ 3620 ); 3622 9.1.33. PRIORITY schema 3624 CREATE TABLE PRIORITY ( 3625 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3626 VALUE INTEGER NOT NULL, 3627 XPARAM INTEGER /* VALUE_KEY */ 3628 ); 3630 9.1.34. RDATE schema 3632 /* VALUETYPE (D) = DATE, (T) = DATE-TIME, (P) = PERIOD */ 3633 CREATE TABLE RDATE ( 3634 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3635 VALUE TIMESTAMP(14) NOT NULL, 3636 VALUETYPE ENUM("D", "T", "P") NOT NULL DEFAULT "T", 3637 TZID INTEGER, /* VALUE_KEY */ 3638 XPARAM INTEGER /* VALUE_KEY */ 3639 ); 3641 9.1.35. RECUR schema 3643 CREATE TABLE RECUR ( 3644 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3645 FREQ ENUM("SECONDLY", "MINUTELY", "HOURLY", 3646 "DAILY", "WEEKLY", "MONTHLY", "YEARLY"), 3647 UNTIL TIMESTAMP(14), 3648 COUNT INTEGER, 3649 INTERVAL_VAL INTEGER, 3651 Mansour/Dawson/Royer/Taler/Hill 70 Expires September 2000 3652 BYSECOND SET("1", "2", "3", "4", "5", "6", "7", "8", 3653 "9", "10", "11", "12", "13", "14", "15", 3654 "16", "17", "18", "19", "20", "21", "22", 3655 "23", "24", "25", "26", "27", "28", "29", 3656 "30", "31", "32", "33", "34", "35", "36", 3657 "37", "38", "39", "40", "41", "42", "43", 3658 "44", "45", "46", "47", "47", "48", "49", 3659 "50", "51", "52", "53", "54", "55", "56", 3660 "57", "58", "59"), 3661 BYMINUTE SET("1", "2", "3", "4", "5", "6", "7", "8", 3662 "9", "10", "11", "12", "13", "14", "15", 3663 "16", "17", "18", "19", "20", "21", "22", 3664 "23", "24", "25", "26", "27", "28", "29", 3665 "30", "31", "32", "33", "34", "35", "36", 3666 "37", "38", "39", "40", "41", "42", "43", 3667 "44", "45", "46", "47", "47", "48", "49", 3668 "50", "51", "52", "53", "54", "55", "56", 3669 "57", "58", "59"), 3670 BYHOUR SET("1", "2", "3", "4", "5", "6", "7", "8", 3671 "9", "10", "11", "12", "13", "14", "15", 3672 "16", "17", "18", "19", "20", "21", "22", 3673 "23"), 3674 BYDAY TINYTEXT, 3675 BYMONTHDAY SET("1", "2", "3", "4", "5", "6", "7", "8", 3676 "9", "10", "11", "12", "13", "14", "15", 3677 "16", "17", "18", "19", "20", "21", "22", 3678 "23", "24", "25", "26", "27", "28", "29", 3679 "30", "31", "-1", "-2", "-3", "-4", "-5", 3680 "-6", "-7", "-8", "-9", "-10", "-11", 3681 "-12", "-13", "-14", "-15", "-16", "-17", 3682 "-18", "-19", "-20", "-21", "-22", "-23", 3683 "-24", "-25", "-26", "-27", "-28", "-29", 3684 "-30", "-31"), 3685 BYYEARDAY TINYTEXT, 3686 BYWEEKNO TINYTEXT, 3687 BYMONTH SET("1", "2", "3", "4", "5", "6", "7", "8", 3688 "9", "10", "11", "12"), 3689 BYSETPOS TINYTEXT, 3690 WKST SET("SU", "MO", "TU", "WE", "TH", "FR", "SA"), 3691 XPARAM INTEGER /* VALUE_KEY */ 3692 ); 3694 9.1.36. RECURRENCE_ID schema 3696 CREATE TABLE RECURRENCE_ID ( 3697 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3698 VALUE TIMESTAMP(14) NOT NULL, 3699 VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ 3700 RANGE ENUM("THISANDPRIOR", "THISANDFUTURE"), 3701 TZID INTEGER, /* VALUE_KEY */ 3702 XPARAM INTEGER /* VALUE_KEY */ 3704 Mansour/Dawson/Royer/Taler/Hill 71 Expires September 2000 3705 ); 3707 9.1.37. RELATED_TO schema 3709 CREATE TABLE RELATED_TO ( 3710 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3711 VALUE TEXT, 3712 RELTYPE ENUM("PARENT", "CHILD", "SIBLING", 3713 ""), 3714 OTHER_RELTYPE TINYTEXT, 3715 XPARAM INTEGER /* VALUE_KEY */ 3716 ); 3718 9.1.38. REPEAT schema 3720 CREATE TABLE REPEAT ( 3721 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3722 VALUE INTEGER NOT NULL DEFAULT 0, 3723 XPARAM INTEGER /* VALUE_KEY */ 3724 ); 3726 9.1.39. RESOURCES schema 3728 CREATE TABLE RESOURCES ( 3729 VALUE_Y INTEGER NOT NULL PRIMARY KEY, 3730 VALUE TEXT NOT NULL, 3731 ALTREP INTEGER, /* VALUE_KEY */ 3732 LANGUAE INTEGER, /* VALUE_KEY */ 3733 XPARAM INTEGER /* VALUE_KEY */ 3734 ); 3736 9.1.40. ROLE schema 3738 CREATE TABLE ROLE ( 3739 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3740 VALUE ENUM("CHAIR", "REQ-PARTICIPANT", 3741 "OPT-PARTICIPANT", 3742 "NON-PARTICIPANT", 3743 "") 3744 NOT NULL DEFAULT "REQ-PARTICIPANT", 3745 OTHER_VALUE TINYTEXT 3746 ); 3748 Mansour/Dawson/Royer/Taler/Hill 72 Expires September 2000 3749 9.1.41. RRULE schema 3751 CREATE TABLE RRULE ( 3752 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3753 VALUE INTEGER NOT NULL, /* VALUE_KEY (RECUR) */ 3754 XPARAM INTEGER /* VALUE_KEY */ 3755 ); 3757 9.1.42. SEQUENCE schema 3759 CREATE TABLE SEQUENCE ( 3760 VALUE_KEY INTEGER NOT NULL PRIMARY KEY DEFAULT 0, 3761 VALUE INTEGER NOT NULL, 3762 XPARAM INTEGER /* VALUE_KEY */ 3763 ); 3765 9.1.43. STATUS schema 3767 CREATE TABLE STATUS ( 3768 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3769 VALUE ENUM("TENTATIVE", 3770 "CONFIRMED", 3771 "CANCELLED", 3772 "NEEDS-ACTION", 3773 "COMPLETED", 3774 "IN-PROCESS", 3775 "DRAFT", 3776 "FINAL") NOT NULL, 3777 XPARAM INTEGER /* VALUE_KEY */ 3778 ); 3780 9.1.44. SUMMARY schema 3782 CREATE TABLE SUMMARY ( 3783 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3784 VALUE TINYTEXT, 3785 ALTREP INTEGER, /* VALUE_KEY */ 3786 LANGUAGE INTEGER, /* VALUE_KEY */ 3787 XPARAM INTEGER /* VALUE_KEY */ 3788 ); 3790 9.1.45. TRANSP schema 3792 CREATE TABLE TRANSP ( 3793 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3795 Mansour/Dawson/Royer/Taler/Hill 73 Expires September 2000 3796 VALUE ENUM("OPQQUE", "TRANSPARENT", 3797 "OPAQUE-NOCONFLICTS", 3798 "TRANSPARENT-NOCONFLICTS") 3799 NOT NULL DEFAULT "TRANSPARENT", 3800 XPARAM INTEGER /* VALUE_KEY */ 3801 ); 3803 9.1.46. TRIGGER schema 3805 CREATE TABLE TRIGGER ( 3806 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3807 VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ 3808 VALUE_DT TIMESTAMP(14), 3809 VALUE_P INTEGER, /* SECONDS */ 3810 RELATED INTEGER, /* VALUE_KEY */ 3811 XPARAM INTEGER /* VALUE_KEY */ 3812 ); 3814 9.1.47. TZID schema 3816 CREATE TABLE TZID ( 3817 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3818 VALUE TEXT 3819 ); 3821 9.1.48. UID schema 3823 CREATE TABLE UID ( 3824 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3825 VALUE TEXT, 3826 XPARAM INTEGER /* VALUE_KEY */ 3827 ); 3829 9.1.49. URL schema 3831 CREATE TABLE URL ( 3832 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3833 VALUE TEXT, 3834 XPARAM INTEGER /* VALUE_KEY */ 3835 ); 3837 Mansour/Dawson/Royer/Taler/Hill 74 Expires September 2000 3838 9.1.50. VALARM schema 3840 CREATE TABLE VALARM ( 3841 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3842 ACTION INTEGER NOT NULL, /* VALUE_KEY */ 3843 ATTACH INTEGER, 3844 DESCRIPTION INTEGER, /* VALUE_KEY */ 3845 DURATION INTEGER, /* VALUE_KEY */ 3846 REPEAT INTEGER, /* VALUE_KEY */ 3847 SUMMARY INTEGER, /* VALUE_KEY */ 3848 TRIGGER INTEGER, /* VALUE_KEY */ 3849 X_PROP INTEGER /* VALUE_KEY */ 3850 ); 3852 9.1.51. VCALENDAR schema 3854 CREATE TABLE VCALENDAR ( 3855 VALUE_KEY INTEGER NOT NULL, 3856 ALLOW_CONFLICTS ENUM("T", "F") DEFAULT "T", 3857 CALSCALE TINYTEXT NOT NULL, 3858 CHARSET TINYTEXT NOT NULL, 3859 CHILDREN INTEGER, /* VALUE_KEY */ 3860 CREATED INTEGER, /* VALUE_KEY */ 3861 DEFAULT_VCAR INTEGER NOT NULL, /* VALUE_KEY */ 3862 LANGUAGE INTEGER, /* VALUE_KEY */ 3863 LAST_MODIFIED INTEGER, /* VALUE_KEY */ 3864 NAME TINYTEXT, 3865 OWNERS INTEGER, /* VALUE_KEY */ 3866 PARENT INTEGER, /* VALUE_KEY */ 3867 RELCALID VARCHAR(255) NOT NULL PRIMARY KEY, 3868 TOMESTONE ENUM("T", "F") NOT NULL DEFAULT "T", 3869 TZID INTEGER NOT NULL /* VALUE_KEY */ 3870 ); 3872 9.1.52. VCAR schema 3874 CREATE TABLE VCAR ( 3875 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3876 VALUE TINYTEXT 3877 /**/ 3879 ); 3881 9.1.53. VEVENT schema 3882 The METHOD value will be CREATE for booked entries. Or it must be a 3883 valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, 3884 REFRESH, COUNTER or DECLINE-COUNTER. 3886 Mansour/Dawson/Royer/Taler/Hill 75 Expires September 2000 3887 CREATE TABLE VEVENT ( 3888 ATTACH INTEGER, /* VALUE_KEY */ 3889 ATTENDEE INTEGER, /* VALUE_KEY */ 3890 CATEGORIES INTEGER, /* VALUE_KEY */ 3891 CLASS INTEGER, /* VALUE_KEY */ 3892 COMMENT INTEGER, /* VALUE_KEY */ 3893 CONTACT INTEGER, /* VALUE_KEY */ 3894 CREATED INTEGER, /* VALUE_KEY */ 3895 DESCRIPTION INTEGER, /* VALUE_KEY */ 3896 DTEND INTEGER, /* VALUE_KEY */ 3897 DTSTAMP INTEGER, /* VALUE_KEY */ 3898 DTSTART INTEGER, /* VALUE_KEY */ 3899 DURATION INTEGER, /* VALUE_KEY */ 3900 EXDATE INTEGER, /* VALUE_KEY */ 3901 EXRULE INTEGER, /* VALUE_KEY */ 3902 GEO INTEGER, /* VALUE_KEY */ 3903 LAST_MODIFIED INTEGER, /* VALUE_KEY */ 3904 LOCATION INTEGER, /* VALUE_KEY */ 3905 METHOD INTEGER, /* VALUE_KEY */ 3906 ORGANIZER INTEGER, /* VALUE_KEY */ 3907 PRIORITY INTEGER, /* VALUE_KEY */ 3908 RECURRENCE_ID INTEGER, /* VALUE_KEY */ 3909 RDATE_KEY INTEGER, /* VALUE_KEY */ 3910 RELATED_TO INTEGER, /* VALUE_KEY */ 3911 RESOURCES INTEGER, /* VALUE_KEY */ 3912 RRULE INTEGER, /* VALUE_KEY */ 3913 SUMMARY INTEGER, /* VALUE_KEY */ 3914 SEQUENCE INTEGER, /* VALUE_KEY */ 3915 STATUS INTEGER, /* VALUE_KEY */ 3916 TRANSP INTEGER, /* VALUE_KEY */ 3917 UID INTEGER, /* VALUE_KEY */ 3918 URL INTEGER, /* VALUE_KEY */ 3919 X_PROP_KEY INTEGER, /* VALUE_KEY */ 3920 VALARM_KEY INTEGER /* VALUE_KEY */ 3921 ); 3923 9.1.54. VFREEBUSY schema 3924 An implementation may not actually have a VFREEBUSY table as the 3925 information may be produced dynamicly. However a CS MUST appear to 3926 provide this table as this may be how a CUA chooses to query for 3927 VFREEBUSY information while using [CAP]. Example, it probably would not 3928 make any sense for ATTENDEE to exist in this table, yet a CUA may wish 3929 to ask for the VFREEBUSY for an ATTENDEE. 3931 CREATE TABLE VFREEBUSY ( 3932 ATTENDEE INTEGER, /* VALUE_KEY */ 3933 COMMENT INTEGER, /* VALUE_KEY */ 3934 CONTACT INTEGER, /* VALUE_KEY */ 3935 DTEND INTEGER, /* VALUE_KEY */ 3937 Mansour/Dawson/Royer/Taler/Hill 76 Expires September 2000 3938 DTSTAMP INTEGER, /* VALUE_KEY */ 3939 DTSTART INTEGER, /* VALUE_KEY */ 3940 FREEBUSY INTEGER, /* VALUE_KEY */ 3941 METHOD INTEGER, /* VALUE_KEY */ 3942 ORGANIZER INTEGER, /* VALUE_KEY */ 3943 X_PROP_KEY INTEGER, /* VALUE_KEY */ 3944 URL INTEGER /* VALUE_KEY */ 3945 ); 3947 9.1.55. VJOURNAL schema 3948 The METHOD value will be CREATE for booked entries. Or it must be a 3949 valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, 3950 REFRESH, COUNTER or DECLINE-COUNTER. 3952 CREATE TABLE VJOURNAL ( 3953 ATTACH_KEY INTEGER, /* VALUE_KEY */ 3954 CATEGORIES INTEGER, /* VALUE_KEY */ 3955 CLASS INTEGER, /* VALUE_KEY */ 3956 COMMENT INTEGER, /* VALUE_KEY */ 3957 CONTACT INTEGER, /* VALUE_KEY */ 3958 CREATED INTEGER, /* VALUE_KEY */ 3959 DESCRIPTION INTEGER, /* VALUE_KEY */ 3960 DTSTAMP INTEGER, /* VALUE_KEY */ 3961 DTSTART INTEGER, /* VALUE_KEY */ 3962 EXDATE INTEGER, /* VALUE_KEY */ 3963 EXRULE INTEGER, /* VALUE_KEY */ 3964 LAST_MODIFIED INTEGER, /* VALUE_KEY */ 3965 METHOD INTEGER, /* VALUE_KEY */ 3966 ORGANIZER INTEGER, /* VALUE_KEY */ 3967 RDATE INTEGER, /* VALUE_KEY */ 3968 RECURRENCE_ID INTEGER, /* VALUE_KEY */ 3969 RELATED_TO INTEGER, /* VALUE_KEY */ 3970 RRULE INTEGER, /* VALUE_KEY */ 3971 SEQUENCE INTEGER, /* VALUE_KEY */ 3972 STATUS INTEGER, /* VALUE_KEY */ 3973 SUMMARY INTEGER, /* VALUE_KEY */ 3974 UID INTEGER, /* VALUE_KEY */ 3975 X_PROP INTEGER /* VALUE_KEY */ 3976 ); 3978 9.1.56. VQUERY schema 3979 Stored VQUERYs will use the following schema. 3981 CREATE TABLE VQUERY ( 3982 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 3983 VALUE TINYTEXT, /* QUERYNAME */ 3984 SCOPE TINYTEXT, 3985 MAXRESULTS INTEGER, 3987 Mansour/Dawson/Royer/Taler/Hill 77 Expires September 2000 3988 MAXSIZE INTEGER, 3989 CARSELECT TEXT, 3990 CARWHERE TEXT, 3991 CARORDERBY TEXT, 3992 X_PROP INTEGER /* VALUE_KEY */ 3993 ); 3995 9.1.57. VTIMEZONE schema 3997 CREATE TABLE VTIMEZONE ( 3998 DAYLIGHT INTEGER NOT NULL, /* VALUE_KEY */ 3999 STANDARD INTEGER NOT NULL, /* VALUE_KEY */ 4000 TZID INTEGER NOT NULL, /* VALUE_KEY */ 4001 TZURL INTEGER, /* VALUE_KEY */ 4002 X_PROP_KEY INTEGER /* VALUE_KEY */ 4003 ); 4005 9.1.58. VTODO schema 4006 The METHOD value will be CREATE for booked entries. Or it must be a 4007 valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, 4008 REFRESH, COUNTER or DECLINE-COUNTER. 4010 CREATE TABLE VTODO ( 4011 ATTENDEE INTEGER, /* VALUE_KEY */ 4012 ATTACH INTEGER, /* VALUE_KEY */ 4013 CATEGORIES INTEGER, /* VALUE_KEY */ 4014 CLASS INTEGER, /* VALUE_KEY */ 4015 COMMENT INTEGER, /* VALUE_KEY */ 4016 CONTACT INTEGER, /* VALUE_KEY */ 4017 CREATED INTEGER NOT NULL, /* VALUE_KEY */ 4018 DESCRIPTION INTEGER, /* VALUE_KEY */ 4019 DTSTAMP INTEGER NOT NULL, /* VALUE_KEY */ 4020 DTSTART INTEGER NOT NULL, /* VALUE_KEY */ 4021 DUE INTEGER, /* VALUE_KEY */ 4022 DURATION INTEGER, /* VALUE_KEY */ 4023 EXDATE INTEGER, /* VALUE_KEY */ 4024 EXRULE INTEGER, /* VALUE_KEY */ 4025 GEO INTEGER, /* VALUE_KEY */ 4026 LAST_MODIFIED INTEGER NOT NULL, /* VALUE_KEY */ 4027 LOCATION INTEGER, /* VALUE_KEY */ 4028 METHOD INTEGER, /* VALUE_KEY */ 4029 ORGANIZER INTEGER, /* VALUE_KEY */ 4030 PERCENT_COMPLETE INTEGER, /* VALUE_KEY */ 4031 PRIORITY INTEGER, /* VALUE_KEY */ 4032 RDATE INTEGER, /* VALUE_KEY */ 4033 RECURRENCE_ID INTEGER, /* VALUE_KEY */ 4034 RESOURCES INTEGER, /* VALUE_KEY */ 4035 RRULE INTEGER, /* VALUE_KEY */ 4036 SEQUENCE INTEGER, /* VALUE_KEY */ 4038 Mansour/Dawson/Royer/Taler/Hill 78 Expires September 2000 4039 SUMMARY INTEGER NOT NULL, /* VALUE_KEY */ 4040 UID INTEGER NOT NULL PRIMARY KEY, /* VALUE_KEY */ 4041 URL INTEGER, /* VALUE_KEY */ 4042 X_PROP INTEGER, /* VALUE_KEY */ 4043 VALARM INTEGER /* VALUE_KEY */ 4044 ); 4046 9.1.59. X_PROP schema 4048 CREATE TABLE X_PROP ( 4049 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 4050 VALUE TEXT NOT NULL, 4051 NAME TEXT NOT NULL, 4052 PARAMS INTEGER /* VALUE_KEY (XPARAM)*/ 4053 ); 4055 9.1.60. XPARAM schema 4057 CREATE TABLE XPARAM ( 4058 VALUE_KEY INTEGER NOT NULL PRIMARY KEY, 4059 VALUE TEXT NOT NULL, 4060 NAME TEXT NOT NULL 4061 ); 4063 9.2. Query example 4064 4066 10. Examples 4068 For all the examples in this section, the authenticated user is 4069 user@example.com. 4071 10.1. Authentication Examples 4073 10.1.1. Login Using Kerberos V4 4075 Use Kerberos V4 to authenticate as bill@example.com to the CAP server on 4076 cal.example.com. 4078 C: 4079 S: 2.0 4080 S: . 4081 C: CAPABILTY 4082 S: CAPVERSION=1.0 4084 Mansour/Dawson/Royer/Taler/Hill 79 Expires September 2000 4085 S: ITIPVERSION=1.0 4086 S: AUTH=KERBEROS_V4 4087 S: AUTH=DIGEST_MD5 4088 S: . 4089 C: AUTHENTICATE KERBEROS_V4 4090 S: AmFYig== 4091 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 4092 S: or//EoAADZI= 4093 C: DiAF5A4gA+oOIALuBkAAmw== 4094 S: 2.0 4095 S: IDENTITY=bill@example.com 4096 S: CAPVERSION=1.0 4097 S: ITIPVERSION=1.0 4098 S: AUTH=KERBEROS_V4 4099 S: AUTH=DIGEST_MD5 4100 S: CAR=CAR-FULL-1 4101 S: MINDATE=19700101T000000Z 4102 # who knows this date (end of the 32 bit number)? 4103 S: MAXDATE=20370201T000000Z 4104 S: . 4106 10.1.2. Error Scenarios 4108 Use of SASL Authorization Identity is not supported. Use the IDENTITY 4109 command instead. If you attempt to use the Authorization Identity, an 4110 error status will be returned. 4112 C: AUTHENTICATE KERBEROS_V4 4113 S: AmFYig== 4114 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 4115 S: or//EoAADZI= 4116 C: DiAF5A4gA+oOIALuBkAAmw== 4117 S: 6.1 4118 S: . 4120 Sender aborted authentication: 4122 C: AUTHENTICATE KERBEROS_V4 4123 S: AmFYig== 4124 C: . 4125 S: 6.2 4126 S: . 4128 Unsupported mechanism: 4130 C: AUTHENTICATE Experimental_Auth 4131 S: 6.3 4132 S: . 4134 Mansour/Dawson/Royer/Taler/Hill 80 Expires September 2000 4135 10.2. Read Examples 4137 10.2.1. Read From A Single Calendar 4139 In this example bill@example.com reads a day's worth of events from 4140 cap://cal.example.com/opaqueid99. 4142 C: SENDDATA 4143 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4144 C: 4145 C: BEGIN:VCALENDAR 4146 C: VERSION:2.1 4147 C: METHOD:READ 4148 C: CMDID:xyz12345 4149 C: TARGET:cap://cal.example.com/opaqueid99 4150 C: BEGIN:VQUERY 4151 C: QUERY:SELECT (VEVENT.DTSTART,VEVENT.DTEND,SUMMARY,UID); 4152 C: FROM VEVENTTABLE; 4153 C: WHERE (VEVENT.DTEND >= 19990714T080000Z AND 4154 C: VEVENT.DTSTART <= 19990715T080000Z); 4155 C: ORDERBY (VEVENT.DTSTART ASC, VEVENT.DTEND, UID, SUMMARY) 4156 C: END:VQUERY 4157 C: END:VCALENDAR 4158 C: . 4159 # this response code means that the transport successfully 4160 # delivered the data. 4161 S: 2.0 ; got the request OK ; really 4162 S: . 4163 S: Content-type:text/calendar; Method=RESPONSE; 4164 S: Optinfo=VERSION:2.1 4165 S: Content-Transfer-Encoding: 7bit 4166 S: 4167 S: BEGIN:VCALENDAR 4168 S: VERSION:2.1 4169 S: METHOD:RESPONSE 4170 S: TARGET:cap://cal.example.com/opaqueid99 4171 S: CMDID:xyz12345 4172 S: RESPONSE-STATUS:2.0 4173 S: BEGIN:VEVENT 4174 S: DTSTART:19990714T200000Z 4175 S: DTEND:19990714T210000Z 4176 S: UID:000444888929922 4177 S: SUMMARY:Blah bla 4178 S: END:VEVENT 4179 S: BEGIN:VEVENT 4180 S: UID:0034848098038888989443 4181 S: SUMMARY:meeting 4182 S: DTEND:19990714T233000Z 4183 S: DTSTART:19990714T223000Z 4184 S: END:VEVENT 4185 S: END:VCALENDAR 4186 S: . 4188 Mansour/Dawson/Royer/Taler/Hill 81 Expires September 2000 4189 10.2.2. Read From Multiple Calendars 4191 In this example bill@example.com reads a day's worth of events from 4192 cap://cal.example.com/opaqueid101 and cap://cal.example.com/opaqueid103 4194 C: SENDDATA 4195 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4196 C: 4197 C: BEGIN:VCALENDAR 4198 C: VERSION:2.1 4199 C: METHOD:READ 4200 C: CMDID:xyz12346 4201 C: TARGET:cap://cal.example.com/opaqueid101 4202 C: TARGET:opaqueid103 4203 C: BEGIN:VQUERY 4204 C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID); 4205 C: FROM VEVENT; 4206 C: WHERE (DTEND >= 19990714T080000Z AND 4207 C: DTSTART <= 19990715T080000Z); 4208 C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) 4209 C: END:VQUERY 4210 C: END:VCALENDAR 4211 C: . 4212 S: 2.0 4213 S: . 4214 S: Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67" 4215 S: 4216 S: ----FEE3790DC7E35189CA67 4217 S: Content-type:text/calendar; Method=RESPONSE; 4218 S: Optinfo=VERSION:2.1 4219 S: Content-Transfer-Encoding: 7bit 4220 S: 4221 S: BEGIN:VCALENDAR 4222 S: VERSION:2.1 4223 S: METHOD:RESPONSE 4224 S: TARGET:cap://cal.example.com/opaqueid103 4225 S: CMDID:xyz12346 4226 S: RESPONSE-CODE:2.0 4227 S: BEGIN:VEVENT 4228 S: UID:0034848098038888989443 4229 S: SUMMARY:meeting 4230 S: DTEND:19990714T233000Z 4231 S: DTSTART:19990714T223000Z 4232 S: END:VEVENT 4233 S: END:VCALENDAR 4234 S: 4235 S: ----FEE3790DC7E35189CA67CE2C 4236 S: Content-type:text/calendar; Method=RESPONSE; 4237 S: Optinfo=VERSION:2.1 4238 S: Content-Transfer-Encoding: 7bit 4239 S: 4240 S: BEGIN:VCALENDAR 4241 S: VERSION:2.1 4243 Mansour/Dawson/Royer/Taler/Hill 82 Expires September 2000 4244 S: METHOD:RESPONSE 4245 S: TARGET:cap://cal.example.com/opaqueid101 4246 S: CMDID:xyz12346 4247 S: RESPONSE-CODE:4.1 ; access denied 4248 S: END:VCALENDAR 4249 S: 4250 S: ----FEE3790DC7E35189CA67CE2C 4251 S: . 4253 10.2.3. Timeouts 4255 In this example bill@example.com attempts to read a calendar but the 4256 latency time he supplies is not sufficient for the server to complete 4257 the command. 4259 C: SENDDATA 3 4260 C: Content-type:text/calendar; Method=READ; Component=VQUERY 4261 C: 4262 C: BEGIN:VCALENDAR 4263 C: VERSION:2.1 4264 C: METHOD:READ 4265 C: CMDID:xyz12346 4266 C: TARGET:cap://cal.example.com/opaqueid101 4267 C: TARGET:opaqueid103 4268 C: BEGIN:VQUERY 4269 C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID); 4270 C: FROM VEVENT; 4271 C: WHERE (DTEND >= 19990714T080000Z AND 4272 C: DTSTART <= 19990715T080000Z); 4273 C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) 4274 C: END:VQUERY 4275 C: END:VCALENDAR 4276 C: . 4277 S: 7.0 ; timeout 4278 S: . 4279 S: . 4281 If Bill wants to continue and give the server more time he would issue a 4282 CONTINUE command: 4284 C: CONTINUE 10 4286 If Bill wants to abort the command and not wait any further he would 4287 issue an ABORT command: 4289 C: ABORT 4290 S: 2.0 4291 S: . 4292 S: . 4294 Mansour/Dawson/Royer/Taler/Hill 83 Expires September 2000 4295 10.2.4. Using the Calendar Parent, Children Properties 4297 10.2.5. An example that depends on VEVENT.DTSTART and VALARM.DTSTART 4299 11. Implementation Issues 4301 1. What are the minimum component properties set required to create a 4302 new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and UID. 4304 2. What is the state of all undefined properties? PROPOSAL: Not defined. 4305 So a query will not return them, if they are selected. 4307 12. Properties 4309 [Editors Note: These extensions/changes to iCalendar need to be 4310 reformatted to conform to the IANA registration process defined in 4311 section 7 of [RFC2445].] 4313 12.1. Calendar Store Properties 4314 The following are properties of the calendar store. 4316 Name Read Value Description 4317 Only Type 4318 -------------------------------------------------------------------------- 4319 CALMASTER N URI The email address for a responsable 4320 person. MUST be a mailto URL. 4322 CSID Y URI The CSID of this calendar store. 4323 If not specified, it is the same as 4324 the hostname or virtual host name. 4326 DEFAULT_VCARS N TEXT A multivalued property containing 4327 the default VCARs for newly created 4328 top level calendars. Each entry is 4329 a CARID It MUST include at a mini- 4330 mum READBUSYTIMEINFO, REQUESTONLY, 4331 UPDATEPARTSTATUS, and DEFAULTOWNER. 4333 MAXDATE Y DATE-TIME The date/time in the future beyond 4334 which the server cannot represent. 4335 If not specified, then 4336 99991231T235959 will be assumed. 4338 Mansour/Dawson/Royer/Taler/Hill 84 Expires September 2000 4339 MINDATE Y DATE-TIME The date/time in the past prior to 4340 which the server cannot represent. 4341 If not specified, then 4342 00000101T000000 will be assumed. 4344 CURRENT_DATETIME Y DATE-TIME Current server time. This is re- 4345 turned as a local time and TZID. 4347 RECUR_ACCEPTED Y BOOLEAN Boolean value will be set to TRUE 4348 if the server will accept recur- 4349 rence rules. It will be set to 4350 FALSE if the server will not accept 4351 recurrence rules. If not specified 4352 a CUA MUST assume TRUE. 4354 RECUR_EXPAND Y BOOLEAN If set to TRUE, the CS supports the 4355 expansion of recurrence rules. If 4356 set to FALSE, the CS is incapabale 4357 of expanding recurrence rules. If 4358 not specified a CUA MUST assume 4359 TRUE. 4361 RECUR_LIMIT Y INTEGER This numeric value describes how 4362 the server handles unbounded recur- 4363 rences. The value is only valid if 4364 RECURRENCE is TRUE. If the value is 4365 0 it means that the server supports 4366 unbounded recurrence rules. If it 4367 is non-zero, it is a positive inte- 4368 ger indicating the number of in- 4369 stances that will be created when 4370 the server expands an unbounded re- 4371 currence rule when fetched from the 4372 CS. A CUA MUST query for date 4373 ranges when this value is zero. 4375 VERSION Y TEXT The version of the CS. The default 4376 and the only currently supported 4377 version is "2.0" to match the 4378 [RFC2445] VERSION. 4380 [Editors Note: Can/MUST the server unzip RRULES/EXRULES?] 4382 12.2. Calendar Properties 4384 Mansour/Dawson/Royer/Taler/Hill 85 Expires September 2000 4385 Name Read Value Description 4386 Only Type 4387 ------------------------------------------------------------------------- 4388 ALLOW-CONFLICTS N BOOLEAN This boolean value indicates 4389 whether or not the calendar sup- 4390 ports event conflicts. That is, 4391 whether or not any of the events in 4392 the calendar can overlap. If not 4393 specified the default value is TRUE 4394 meaning that conflicts are allowed. 4396 CALSCALE N TEXT The CALSCALE for thie calendar. If 4397 not specified the default is GREGO- 4398 RIAN. 4400 CHARSET N TEXT The default charset for localized 4401 strings in this calendar. If not 4402 specified, the default is UTF-8. 4404 CHILDREN Y TEXT The list of sub-calendars belonging 4405 to this calendar. An empty list 4406 means no children. The results may 4407 be a comma seperated list of chil- 4408 dren. Each entry returned is a 4409 CALID. The default is an empty 4410 list. 4412 CREATED Y DATE-TIME The timestamp of the calendar's 4413 create date. 4415 DEFAULT_VCAR N TEXT The default VCARs for newly created 4416 top level calendars. This is a 4417 CARID. The defalut value is the 4418 value of DEFAULT_VCAR in the CAL- 4419 STORE table. 4420 T} 4422 LANGUAGE N TEXT The default language for localiz- 4423 able strings in this calendar. 4424 There is no default. 4426 LAST-MODIFIED N DATE-TIME The timestamp when the properties 4427 of the calendar were last updated. 4429 NAME N TEXT The display name for this calendar. 4430 It is a localizable string. If not 4431 provided, an empty value will be 4432 returned. 4434 Mansour/Dawson/Royer/Taler/Hill 86 Expires September 2000 4435 OWNERS N URI A multi instanced property indicat- 4436 ing the calendar owner. Each entry 4437 returned will be a UPN. There must 4438 be at least one owner. 4440 PARENT N URI The CALID of this calendars parent 4441 maintained by a CAP server. An 4442 empty value means the calendar is 4443 the top level parent. The default 4444 value is no parent. 4446 RELCALID N URI A unique name for the calendar. 4447 There is no default value and this 4448 value MUST NOT be empty. 4450 TOMBSTONE N BOOLEAN TRUE indicator that this calendar 4451 has been marked as deleted. The 4452 default value is FALSE. 4454 TZID N TEXT The id of the timezone associated 4455 with this calendar. See TZID in 4456 [RFC2445]. The default value is 4457 GMT. 4459 13. Security Considerations 4461 For the mandatory SASL mechanism that CAP specifies, the mechanism 4462 support is: 4464 ? MUST authentication ? MUST authorization ? MAY impersonation 4466 The security issue: 4468 +---------+ +----------+ 4469 CUA1 ------ | CS1 |--------CAP----------| CS2 |-----CUA2 4470 | calF | | calA | 4471 +---------+ +----------+ 4473 14. Changes to iCalendar 4475 [Editors Note: These extensions/changes to iCalendar need to be 4476 reformatted to conform to the IANA registration process defined in 4477 section 7 of [RFC2445].] 4479 Mansour/Dawson/Royer/Taler/Hill 87 Expires September 2000 4480 14.1. Time Transparency 4482 Property Name: TRANSP 4484 Purpose: This property defines whether an event is transparent or not to 4485 busy time searches. 4487 Value Type: TEXT 4489 Property Parameters: Non-standard property parameters can be specified 4490 on this property. 4492 Conformance: This property can be specified once in a "VEVENT" calendar 4493 component. 4495 Description: Time Transparency is the characteristic of an event that 4496 determines whether it appears to consume time on a calendar. Events that 4497 consume actual time for the individual or resource associated with the 4498 calendar SHOULD be recorded as OPAQUE, allowing them to be detected by 4499 free-busy time searches. Other events, which do not take up the 4500 individual's (or resource's) time SHOULD be recorded as TRANSPARENT, 4501 making them invisible to free-busy time searches. 4503 Format Definition: The property is specified by the following notation: 4505 transp = "TRANSP" tranparam ":" transvalue CRLF 4507 tranparam = *(";" xparam) 4509 transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. 4510 / "TRANSPARENT" ;Transparent on busy time searches. 4512 / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time 4513 ; searches and no other OPAQUE 4514 ; or OPAQUE-NOCONFLICT event 4515 ; can overlap it. 4517 / "OPAQUE-NOCONFLICT" ; Opaque on busy time 4518 ; searches and no other OPAQUE 4519 ; or OPAQUE-NOCONFLICT event 4520 ; can overlap it. 4521 ; 4522 ;Default value is OPAQUE 4524 Example: The following is an example of this property for an event that 4525 is transparent or does not block on free/busy time searches: 4527 TRANSP:TRANSPARENT 4529 The following is an example of this property for an event that is opaque 4530 or blocks on free/busy time searches: 4532 Mansour/Dawson/Royer/Taler/Hill 88 Expires September 2000 4533 TRANSP:OPAQUE 4535 The following is an example of this property for an event that is opaque 4536 or blocks on free/busy time searches plus no other event can overlap it: 4538 TRANSP:OPAQUE-NOCONFLICT 4540 14.2. RIGHTS Value Type 4542 Value Name: RIGHTS 4544 Purpose: This value type is used to identify properties whose value is a 4545 calendar access rights. 4547 Formal Definition: The value type is defined by the following notation: 4549 carrights = [princ] (carref / cardef) CRLF 4551 princ = "UPN" "=" (text / all / "OWNER" / "NONOWNER" / "ANONYMOUS") 4553 carref = ";" "CARREF" "=" text *("," text) 4555 cardef = action object *("," action object) 4557 action = ";" "ACTION" "=" act-type *("," act-type) 4559 act-type = ("CREATE" / "MODIFY" / "DELETE" / "READ" / all) 4561 object = ";" "OBJECT" "=" (csprop *("," csprop) [propvalue]) 4562 / (calprop *("," calprop) [propvalue]) 4563 / (component *("," component)) [compvalue] 4564 / (compprop *("," compprop) [propvalue]) 4565 / (compparam *("," compparam) [paramvalue]) 4567 csprop = csprop2 / all / iana-name 4569 csprop2 = 4571 propvalue = propvalue2 / all / self / iana-name 4573 propvalue2 = 4575 calprop = calprop2 / all / iana-name 4577 calprop2 = 4580 component = component2 / all / iana-name 4582 component2 = 4585 Mansour/Dawson/Royer/Taler/Hill 89 Expires September 2000 4586 compprop = compprop2 / all / iana-name 4588 compprop2 = 4591 compparam = compparm2 / all / iana-name 4593 compparm2 = 4596 compvalue = ";" "VALUE" "=" ((component2 *("," component2)) 4597 / all / iana-name) 4599 paramvalue = paramvalue2 / all / iana-name 4601 paramvalue2 = 4603 all = "*" 4605 self = "SELF" ; Only valid for ATTENDEE value. 4606 ; When OBJECT=ATTENDEE;VALUE=SELF. 4608 iana-name = 4610 Description: The value type is a structured value consisting of a list 4611 of one or more access control rights rule parts. Each rule part is 4612 defined by a "NAME=VALUE" pair. The rule parts are separated from each 4613 other by the SEMICOLON character (US-ASCII decimal 59). The rule parts 4614 are not ordered in any particular sequence, unless otherwise specified 4615 by the ABNF. 4617 Within one carrights all matches of multiple OBJECT and VALUE pairs must 4618 be true for the GRANT or DENY to apply. 4620 The UPN rule part specifies the CU or UG to which the VCARs applies. 4621 The value of this rule part is either a quoted text specifying a UPN or 4622 an unquoted text specifying a keyword enumerating a standard 4623 authenticated user type. If the value is the keyword is *, then the rule 4624 applies to all authenticated calendar users (i.e., all UPNs). If the 4625 value is the keyword OWNER, then the rule applies to any of the owners 4626 of the calendar store or calendar. If the value is the keyword NONOWNER, 4627 then the rule applies to a UPN that is not the owner of the calendar 4628 store or calendar. If this rule part is not specified in the value, then 4629 the calendar access rights do not apply to any UPN. In this case, the 4630 calendar access rights can be defined for reference by another instance 4631 of a calendar access rights. For example, a complex set of calendar 4632 access rights can be defined once and referenced many times in the 4633 rights specified for individual calendar users. 4635 The CARREF rule part specifies a reference to a particular "VCAR" 4636 calendar component. The text is matched to a CARID property value within 4637 a "VCAR" calendar component. This allows for a particular set of 4638 calendar access rights to be defined once and referenced multiple times. 4640 Mansour/Dawson/Royer/Taler/Hill 90 Expires September 2000 4641 The "VCAR" identifier specified by this rule part is unique to the 4642 calendar store. 4644 Predefined calendar access CARIDs that MUST be implememnetd (CAR-MIN) 4645 are: 4646 CARID:READBUSYTIMEINFO - Specifies rights for reading VFREEBUSY 4647 components by anonymous and known users. Suggested VCAR to allow all 4648 users to read VFREEBUSY components: 4650 BEGIN:VCAR 4651 CARID:READBUSYTIMEINFO 4652 GRANT:UPN=*;ACTION=READ;OBJECTS=VFREEBUSY;VALUE=* 4653 END:VCAR 4655 CARID:REQUESTONLY - Specifies rights for creating new event 4656 invitations, to-do assignments and journal entries by users other 4657 than the owner of the calendar. Suggested VCAR to allow access by 4658 nonowners to submit REQUESTs: 4660 BEGIN:VCAR 4661 CARID:REQUESTONLY 4662 GRANT:UPN=NONOWNER;ACTION=CREATE;OBJECT=* 4663 ;OBJECT=METHOD;VALUE=REQUEST 4664 END:VCAR 4666 CARID:UPDATEPARTSTATUS - Specifies rights for a user to modify their 4667 participation status in a calendar they do not own. Suggested VCAR 4668 to allow users to update their own participation status: 4670 BEGIN:VCAR 4671 CARID:UPDATEPARTSTATUS 4672 GRANT:UPN=*;ACTION=MODIFY 4673 ;OBECT=PARTSTAT:VALUE=* 4674 ;OBJECT=ATTENDEE;VALUE=SELF 4675 END:VCAR 4677 CARID:DEFAULTOWNER - Specifies the default access for any owner of a 4678 calendar. Suggested VCAR to all owners access to their own 4679 calendars: 4681 BEGIN:VCAR 4682 CARID:DEFAULTOWNER 4683 GRANT:UPN=OWNER;ACTION=*;OBJECT=*;VALUE=*; 4684 END:VCAR 4686 The ACTION rule part defines one or more CAP actions that are allowed 4687 for the UPN. The valid values are CREATE, COPY, DELETE, MODIFY, MOVE, 4688 READ, corresponding to the calendar commands; PUBLISH, REQUEST, REPLY, 4689 ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER, corresponding to the 4690 scheduling commands; and ALL, meaning all of calendaring commands and 4691 scheduling commands. Multiple ACTION enumerations can be specified as a 4692 COMMA character (US-ASCII decimal 44) separated list of ACTION 4694 Mansour/Dawson/Royer/Taler/Hill 91 Expires September 2000 4695 enumerated values. The text ALL is the same as specifying the enumerated 4696 values "CREATE, MODIFY, DELETE, READ". 4698 The OBJECT rule part defines the calendar store property, calendar 4699 property, calendar component, component property, or parameter that the 4700 ACTION is restricted to. Multiple OBJECT enumerations can be specified 4701 as a COMMA character (US-ASCII decimal 44) separated list of OBJECT 4702 enumerated values. The value ALL specifies any and all valid objects. 4704 The VALUE rule part specifies the restricted values for the OBJECT rule 4705 part. Multiple VALUE strings can be specified as a COMMA character (US- 4706 ASCII decimal 44) separated list of VALUE strings. The text ALL 4707 specifies any and all valid values. If an OBJECT rule part is specified 4708 but no corresponding VALUE rule part is specified, then the rule applies 4709 to any and all valid values of the specified OBJECT(s). 4711 Example: The following is a rule which specifies access rights for "foo" 4712 calendar user to read busy time values: 4714 UPN="foo@host.com";ACTION=READ;OBJECT=DTSTART,DTEND 4716 14.3. VCAR Calendar Component 4718 Component Name: "VCAR" 4720 Purpose: Provide a grouping of calendar access rights. 4722 Format Definition: A "VCAR" calendar component is defined by the 4723 following notation: 4725 aclc = "BEGIN" ":" "VCAR" CRLF 4726 carprop 4727 "END" ":" "VCAR" CRLF 4729 carprop = carid 1*(grant / deny) 4731 Description: A "VCAR" calendar component is a grouping of calendar 4732 access rights component properties. 4734 The "CARID" property specifies the local identifier for the "VCAR" 4735 calendar component. The "GRANT" property specifies calendar access 4736 rights granted to an UPN. The "DENY" property specifies calendar access 4737 rights denied from an UPN. 4739 Example: In the following example, the UPN "foo@host.com" has read 4740 access to the "DTSTART" and "DTEND" calendar properties. No other access 4741 is specified: 4743 BEGIN:VCAR 4744 CARID:"View Start and End Times" 4745 GRANT:UPN=foo@host.com;ACTION="READ";OBJECT=DTSTART,DTEND 4746 END:VEVENT 4748 Mansour/Dawson/Royer/Taler/Hill 92 Expires September 2000 4749 In this example, all UPNs are given read access to "DTSTART" and 4750 "DTEND". "All CUs and UGs" are specified by the UPN value "*". Note 4751 that this enumerated UPN value is not in quotes.: 4753 BEGIN:VCAR 4754 CARID:"View Start and End Times 2" 4755 GRANT:UPN=*;ACTION=READ;OBJECT=DTSTART,DTEND 4756 END:VCAR 4758 In this example, rights are specified for all UPNs to read components 4759 classified as PUBLIC: 4761 BEGIN:VCAR 4762 CARID:"View PUBLIC Start and End Times" 4763 GRANT:UPN=*;ACTION=READ;OBJECT=DTSTART;DTEND 4764 DENY:UPN=*;ACTION=READ;OBJECT=CLASS;VALUE=PUBLIC, 4765 CONFIDENTIAL 4766 END:VCAR 4768 In this example, rights are specified for all UPNs to read or modify 4769 existing components classified as PUBLIC: 4771 BEGIN:VCAR 4772 CARID:"Read and Modify PUBLIC Calendar Entries" 4773 GRANT:UPN=*;ACTION=READ,MODIFY;OBJECT=* 4774 DENY:UPN=*;ACTION=READ,MODIFY;OBJECT=CLASS;VALUE=PRIVATE, 4775 CONFIDENTIAL 4776 END:VCAR 4778 In this example, full calendar access rights are given to the OWNER and 4779 a hypothetical administrator is given access rights to specify calendar 4780 access rights. If no other rights are specified, only these two UPNs can 4781 specify calendar access rights: 4783 BEGIN:VCAR 4784 CARID:"Only OWNER or ADMIN Settable CARs" 4785 GRANT:UPN=OWNER;ACTION=*;OBJECT=* 4786 GRANT:UPN=cal-admin@host.com;ACTION=*; 4787 OBJECT=VCAR,CARID,GRANT,DENY 4788 END:VCAR 4790 In this example, rights to create, read, modify or delete calendar 4791 access rights are denied to all UPNs. This example would disable 4792 providing different access rights to the calendar store or calendar. 4793 This calendar access rights should not be specified, as they the ability 4794 to change calendar access; even for the owner or administrator: 4796 BEGIN:VCAR 4797 CARID:"No CAR At All" 4798 DENY:UPN=*;OBJECT=VCAR,CARID,GRANT,DENY 4799 ENG:VCAR 4801 Mansour/Dawson/Royer/Taler/Hill 93 Expires September 2000 4802 14.4. GRANT Component Property 4804 Property Name: GRANT 4806 Purpose: This property specifies those access rights granted to a UPN. 4808 Value Type: RIGHTS 4810 Property Parameters: Only non-standard property parameters can be 4811 specified on this property. 4813 Conformance: This property can only be specified in "VCAR" calendar 4814 component. 4816 Description: This property is used to grant calendar access rights to a 4817 UPN. 4819 Format Definition: The property is defined by the following notation: 4821 grant = "GRANT" rightsparam ":" carrights CRLF 4822 rightsparam = *(";" xparam) 4824 14.5. DENY Component Property 4826 Property Name: DENY 4828 Purpose: This property specifies those access rights denied from a UPN. 4830 Value Type: RIGHTS 4832 Property Parameters: Only non-standard property parameters can be 4833 specified on this property. 4835 Conformance: This property can only be specified in "VCAR" calendar 4836 component. 4838 Description: This property is used to deny calendar access rights to a 4839 UPN. 4841 Format Definition: The property is defined by the following notation: 4843 DENY = "DENY" rightsparam ":" carrights CRLF 4844 rightsparam = *(";" xparam) 4846 Example: In the following example, any UPN who is not the owner is 4847 denied rights to create, modify or delete entries: 4849 DENY:UPN=NONOWNER;ACTION=CREATE,MODIFY,DELETE;OBJECT=* 4851 Mansour/Dawson/Royer/Taler/Hill 94 Expires September 2000 4852 14.6. VCAR Identifier Component Property 4854 Property Name: CARID 4856 Purpose: This property specifies the identifier for a "VCAR" calendar 4857 component. 4859 Value Type: TEXT 4861 Property Parameters: Non-standard property parameters can be specified 4862 on this property. 4864 Conformance: This property can be specified in "VCAR" calendar 4865 component. 4867 Description: This property permits previously defined sets of calendar 4868 access rights to be specified with a reference. This capability 4869 facilitates repetitively specifying calendar access rights. 4871 Format Definition: The property is defined by the following notation: 4873 CARID = "CARID" textparam ":" text CRLF 4875 Example: The following is an example of this property: 4877 CARID:"Restrict Guests From Creating ALARMs On Events" 4879 14.8 REQUEST-STATUS property 4881 This description is a revision of the REQUEST-STATUS property for 4882 VCALENDAR version 2.1. 4884 rstatus = "REQUEST-STATUS" rstatparam ":" 4885 statcode [";" statdesc [";" extdata]] 4887 rstatparam = *( 4888 ; the following is optional, 4889 ; but MUST NOT occur more than once 4891 (";" languageparm) / 4893 ; the following is optional, 4894 ; and MAY occur more than once 4896 (";" xparam) 4898 ) 4900 statcode = 1*DIGIT *("." 1*DIGIT) 4901 ;Hierarchical, numeric return status code 4903 statdesc = text 4905 Mansour/Dawson/Royer/Taler/Hill 95 Expires September 2000 4906 ;An optional textual status description, content is 4907 ;decided by the implementor. May be empty. 4909 extdata = text 4910 ;Textual exception data. For example, the offending property 4911 ;name and value or complete property line. 4913 Example: The following are some possible examples of this property. The 4914 COMMA and SEMICOLON separator characters in the property value are 4915 BACKSLASH character escaped because they appear in a text value. 4917 REQUEST-STATUS:2.0;Success 4919 REQUEST-STATUS:2.0;Success despite braindead LDAP implementation 4921 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 4923 REQUEST-STATUS:2.8; Success, repeating event ignored. Scheduled 4924 as a single event.;RRULE:FREQ=WEEKLY;INTERVAL=2 4926 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. 4928 REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: 4929 MAILTO:jsmith@host.com 4931 REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@host.com 4933 REQUEST-STATUS:10.4;Help! That really shouldnt have happened. 4935 15. CAP Entities Registration 4937 This section provides the process for registration of new or modified 4938 CAP entities. 4940 15.1 Registration of New and Modified CAP Entities New CAP entities are 4941 registered by the publication of an IETF Request for Comment (RFC). 4942 Changes to a CAP entity are registered by the publication of a revision 4943 of the RFC defining the method. 4945 15.2 Registration of New Entities 4947 This section defines procedures by which new entities (i.e., components, 4948 properties, parameters, enumerated values or restriction tables) for a 4949 CAP entity can be registered with the IANA. 4951 Non-standard, experimental entities can be used by bilateral agreement, 4952 provided the associated properties names follow the "X-" convention. 4953 Such non-standard entities are non-IANA entities and need not be 4954 registered using this process. 4956 The procedures defined here are designed to allow public comment and 4958 Mansour/Dawson/Royer/Taler/Hill 96 Expires September 2000 4959 review of new CAP entities, while posing only a small impediment to the 4960 definition of new properties. 4962 Registration of a new CAP entity is accomplished by the following steps. 4964 15.1.1. Define the Entity 4965 A CAP entity is defined by completing the following template. 4967 To: ietf-calendar@imc.org 4968 Subject: Registration of CAP entity XXX 4969 Entity name: 4970 Entity purpose: 4971 Description: 4972 CAP terminology changes: 4973 CAP data model changes: 4974 CAP system model changes: 4975 Conformance considerations: 4976 Format definition: 4977 Examples: 4979 The meaning of each field in the template is as follows. 4981 Entity name: The name of the entity. 4983 Entity purpose: The purpose of the entity (e.g., Extends the CAP command 4984 set to poll for notifications, etc.). Give a short but clear 4985 description. 4987 Description: Any special notes about the entity, how it is to be used, 4988 etc. 4990 CAP terminology changes: Any change or additions to the existing CAP 4991 terminology needs to be specified. 4993 CAP data model changes: Any of the valid property parameters for the 4994 property needs to be specified. 4996 CAP system model changes: 4998 Conformance: A clear summary of how and where this CAP entity extension 4999 MUST, MAY, SHOULD or can be used. Any changes or impact to the existing 5000 conformance definition for CAP should be explained. The impact to 5001 implementations conforming to the existing CAP specification should be 5002 clearly described. 5004 Format definition: The ABNF for each element of the CAP entity needs to 5005 be specified. 5007 Examples: One or more examples of instances of the CAP entity and each 5008 of its usage scenarios needs to be specified. 5010 Mansour/Dawson/Royer/Taler/Hill 97 Expires September 2000 5011 15.1.2. Post the entity definition 5013 The entity description MUST be posted to the new entity discussion list, 5014 ietf-calendar@imc.org. 5016 15.1.3. Allow a comment period 5018 Discussion on the new entity MUST be allowed to take place on the list 5019 for a minimum of two weeks. Consensus MUST be reached on the property 5020 before proceeding to the next step. 5022 15.1.4. Submit the entity for approval 5024 Once the two-week comment period has elapsed, and the proposer is 5025 convinced consensus has been reached on the entity, the registration 5026 application should be submitted to the Method Reviewer for approval. 5027 The Method Reviewer is appointed by the Application Area Directors and 5028 can either accept or reject the entity registration. An accepted 5029 registration should be passed on by the Method Reviewer to the IANA for 5030 inclusion in the official IANA method registry. The registration can be 5031 rejected for any of the following reasons. 1) Insufficient comment 5032 period; 2) Consensus not reached; 3) Technical deficiencies raised on 5033 the list or elsewhere have not been addressed. The Method Reviewers 5034 decision to reject an entity can be appealed by the proposer to the 5035 IESG, or the objections raised can be addressed by the proposer and the 5036 entity resubmitted. 5038 [Ed note: John Stracke to review any updates] 5040 15.2. Property Change Control 5042 Existing CAP entities can be changed using the same process by which 5043 they were registered. 5045 1. Define the change 2. Post the change 3. Allow a comment period 4. 5046 Submit the entity for approval 5048 Note that the original author or any other interested party can propose 5049 a change to an existing CAP entity, but that such changes should only be 5050 proposed when there are serious omissions or errors in the published 5051 memo. The Method Reviewer can object to a change if it is not backward 5052 compatible, but is not required to do so. 5054 CAP entity definitions can never be deleted from the IANA registry, but 5055 entities which are no longer believed to be useful can be declared 5056 OBSOLETE by adding this text to their "Entity purpose" field. 5058 Mansour/Dawson/Royer/Taler/Hill 98 Expires September 2000 5059 16. IANA Considerations 5061 This memo defines IANA registered extensions to the attributes defined 5062 by iCalendar, as defined in [RFC2445], and iTIP, as defined in 5063 [RFC2426]. 5065 IANA registration proposals for iCalendar and iTIP are to be mailed to 5066 the registration agent for the "text/calendar" MIME content-type, 5067 using the format defined in section 7 of 5068 [RFC2445]. 5070 17. Acknowledgments 5072 The following have individuals were major contributors in the drafting 5073 and discussion of this memo: 5075 Harald Alvestrand, Mario Bonin, Andre Courtemanche, Dave Crocker, Pat 5076 Egen, Gilles Fortin, Jeff Hodges, Alex Hoppman, Bruce Kahn, Lisa 5077 Lippert, David Madeo, Bob Mahoney, Bob Morgan, Pete O'Leary, Richard 5078 Shusterman, Tony Small, John Stracke, Mark Wahl. 5080 18. Bibliography 5082 [RFC1521] N. Borenstein and N. Freed, "MIME (Multipurpose Internet Mail 5083 Extensions) Part One: Mechanisms for Internet Draft UTF-825 July 1996 5084 Specifying and Describing the Format of Internet Message Bodies", RFC 5085 1521, Bellcore, Innosoft, September 1993. 5087 [TLS] Dierks, Allen, "The TLS Protocol", RFC 2246, January 1999 5089 [RFC2608] Guttman, Perkins, Veizades, Day, "Service Location protocol, 5090 Version 2", RFC2608, June 1999. 5092 [RFC2609] Guttman, Perkins, Kempf, "Service Templates and Service: 5093 Schemes", RFC2609, June 1999. 5095 [RFC2396] Berners-Lee, Fielding, Masinter, "Uniform Resource Identifiers 5096 (URI): Generic Syntax", RFC 2396, August 1998. 5098 [RFC2445] Dawson, Stenerson, "Internet Calendaring and Scheduling Core 5099 Object Specification (iCalendar)", RFC 2445, November 1998 5101 [RFC2446] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- 5102 Independent Interoperability Protocol (iTIP)", RFC 2446, November 1998 5104 [RFC2447] Dawson, Mansour, Silverberg, "iCalendar Message-Based 5105 Interoperability Protocol (iMIP)", RFC 2445, November 1998 5107 [SQL] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka ANSI 5108 X3.135-1992, aka FiPS PUB 127-2 5110 Mansour/Dawson/Royer/Taler/Hill 99 Expires September 2000 5112 [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 to 5113 ISO/IEC 9075: 1992, also adopted as Amendment 1 to ANSI X3.135.1992 5115 [UNICODE] The Unicode Consortium, "The Unicode Standard --Worldwide 5116 Character Encoding -- Version 1.0", Addison-Wesley, Volume 1, 1991, 5117 Volume 2, 1992. UTF-8 is described in Unicode Technical Report #4. 5119 [US-ASCII] Coded Character Set--7-bit American Standard Code for 5120 Information Interchange, ANSI X3.4-1986. 5122 19. Author's Address 5123 The following address information is provided in a vCard v3.0, the RFC 5124 2426 electronic business card format. 5126 BEGIN:VCARD 5127 VERSION:3.0 5128 N:Dawson;Frank 5129 FN:Frank Dawson 5130 ORG:Lotus Development Corporation 5131 ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;Raleigh;NC; 5132 27613-3502;US 5133 TEL;TYPE=PREF,WORK,MSG:+1-617-693-8728 5134 TEL;TYPE=WORK,MSG:+1-919-676-9515 5135 TEL;TYPE=WORK,FAX:+1-919-676-9515 5136 EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com 5137 EMAIL;TYPE=INTERNET:fdawson@earthlink.net 5138 URL;TYPE=X-HOME:http://home.earthlink.net/~fdawson 5139 END:VCARD 5141 BEGIN:VCARD 5142 VERSION:3.0 5143 N:Mansour;Steve 5144 FN:Steve Mansour 5145 ORG:Netscape 5146 ADR;TYPE=WORK,POSTAL,PARCEL:;;501 E Middlfield Road;Mountain 5147 View;CA;94043;US 5148 TEL;WORK;MSG:+1-650-937-2378 5149 TEL;WORK;FAX:+1-650-937-2103 5150 EMAIL;INTERNET:sman@netscape.com 5151 END:VCARD 5153 BEGIN:VCARD 5154 VERSION: 3.0 5155 FN:Doug Royer 5156 N:Royer,Doug 5157 ORG:Software.com 5158 ADR;TYPE=WORK,POSTAL,PARCEL:Suite 106;;530 E. Montecito St; 5159 Santa Barbara;CA;93103;US 5160 TEL;TYPE=PREF,WORK,MSG:805-957-1790 x541 5161 TEL;TYPE=WORK,MSG:650-364-6538 5162 TEL;TYPE=WORK,FAX:805-957-1544 5163 EMAIL;TYPE=INTERNET,PREF:Doug.Royer@Software.com 5165 Mansour/Dawson/Royer/Taler/Hill 100 Expires September 2000 5166 EMAIL;TYPE=INTERNET:Doug@Royer.com 5167 URL;TYPE=X-HOME:http://Royer.com/People/Doug 5168 END:VCARD 5170 BEGIN:VCARD 5171 VERSION:3.0 5172 FN:Alexander Taler 5173 N:Taler;Alexander 5174 ORG:CS&T 5175 ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC; 5176 H3R 3L5;Canada 5177 TEL;TYPE=WORK,VOICE:514-733-8500 5178 TEL;TYPE=FAX:514-733-8878 5179 EMAIL;TYPE=INTERNET:alext@cst.ca 5180 END:VCARD 5182 20. Full Copyright Statement 5184 "Copyright (C) The Internet Society (2000). All Rights Reserved. This 5185 document and translations of it may be copied and furnished to others, 5186 and derivative works that comment on or otherwise explain it or assist 5187 in its implementation may be prepared, copied, published and 5188 distributed, in whole or in part, without restriction of any kind, 5189 provided that the above copyright notice and this paragraph are included 5190 on all such copies and derivative works. However, this document itself 5191 may not be modified in any way, such as by removing the copyright notice 5192 or references to the Internet Society or other Internet organizations, 5193 except as needed for the purpose of developing Internet standards in 5194 which case the procedures for copyrights defined in the Internet 5195 Standards process MUST be followed, or as required to translate it into 5196 languages other than English. 5198 The limited permissions granted above are perpetual and will not be 5199 revoked by the Internet Society or its successors or assigns. This 5200 document and the information contained herein is provided on an "AS IS" 5201 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 5202 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 5203 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 5204 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 5205 PARTICULAR PURPOSE. 5207 Mansour/Dawson/Royer/Taler/Hill 101 Expires September 2000