idnits 2.17.1 draft-desruisseaux-caldav-sched-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2615. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 1. when creating a scheduling object resource the Organizer MAY NOT set the "PARTSTAT" iCalendar parameter value to anything other than "NEEDS-ACTION" if the corresponding "ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar parameter with its value set to "SERVER", or no "SCHEDULE-AGENT" parameter is present. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 2. when modifying a scheduling object resource the Organizer MAY NOT change the "PARTSTAT" iCalendar parameter value to anything other than "NEEDS-ACTION" if the corresponding "ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar parameter with its value set to "SERVER", or no "SCHEDULE-AGENT" parameter is present. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2445 (Obsoleted by RFC 5545) ** Obsolete normative reference: RFC 2446 (Obsoleted by RFC 5546) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2447 (Obsoleted by RFC 6047) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track B. Desruisseaux 5 Expires: May 7, 2009 Oracle 6 November 3, 2008 8 CalDAV Scheduling Extensions to WebDAV 9 draft-desruisseaux-caldav-sched-06 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 This document defines extensions to the CalDAV calendar-access 39 feature to specify a standard way of performing scheduling 40 transactions with iCalendar-based calendar components. This document 41 defines the "calendar-auto-schedule" feature of CalDAV. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 1.1. Level of Support for iTIP . . . . . . . . . . . . . . . . 4 47 1.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 5 48 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 5 49 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 50 1.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 6 51 2. CalDAV Scheduling Support . . . . . . . . . . . . . . . . . . 7 52 3. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 7 53 3.1. Scheduling Collections . . . . . . . . . . . . . . . . . . 9 54 3.1.1. Scheduling Outbox Collection . . . . . . . . . . . . . 9 55 3.1.2. Scheduling Inbox Collection . . . . . . . . . . . . . 10 56 3.2. Automatic Scheduling Transactions . . . . . . . . . . . . 12 57 3.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12 58 3.2.2. Identifying Scheduling Object Resources . . . . . . . 12 59 3.2.3. Handling Scheduling Object Resources . . . . . . . . . 13 60 3.2.3.1. Organizer Scheduling Object Resources . . . . . . 13 61 3.2.3.2. Attendee Scheduling Object Resources . . . . . . . 16 62 3.2.3.3. HTTP Methods . . . . . . . . . . . . . . . . . . . 18 63 3.3. Processing of incoming scheduling messages . . . . . . . . 20 64 3.3.1. Automatic processing for the Organizer . . . . . . . . 21 65 3.3.1.1. Processing an Attendee reply . . . . . . . . . . . 21 66 3.3.1.2. Processing an Attendee refresh . . . . . . . . . . 21 67 3.3.2. Automatic processing for the Attendee . . . . . . . . 21 68 3.3.2.1. Processing a new scheduling message . . . . . . . 22 69 3.3.2.2. Processing a scheduling message update . . . . . . 22 70 3.3.3. Processing by the client . . . . . . . . . . . . . . . 22 71 3.4. Explicit Scheduling Request . . . . . . . . . . . . . . . 23 72 3.5. Other Considerations . . . . . . . . . . . . . . . . . . . 23 73 3.5.1. Handling recurring items . . . . . . . . . . . . . . . 23 74 3.5.1.1. Restricting what is sent . . . . . . . . . . . . . 23 75 3.5.1.2. Attendee overrides . . . . . . . . . . . . . . . . 23 76 3.5.2. Handling the Default Calendar . . . . . . . . . . . . 24 77 3.5.3. DTSTAMP and SEQUENCE properties . . . . . . . . . . . 24 78 3.5.4. Schedule Status Values . . . . . . . . . . . . . . . . 25 79 3.5.5. Error Handling . . . . . . . . . . . . . . . . . . . . 26 80 3.5.6. Organizer is an Attendee . . . . . . . . . . . . . . . 26 81 4. New iCalendar Parameters . . . . . . . . . . . . . . . . . . . 26 82 4.1. Schedule Agent . . . . . . . . . . . . . . . . . . . . . . 26 83 4.2. Schedule Status . . . . . . . . . . . . . . . . . . . . . 27 84 5. New WebDAV Request Headers . . . . . . . . . . . . . . . . . . 28 85 5.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 28 86 6. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 29 87 6.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 29 88 6.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 30 89 6.3. CALDAV:schedule-state Property . . . . . . . . . . . . . . 31 90 7. New Preconditions . . . . . . . . . . . . . . . . . . . . . . 32 91 7.1. Additional Preconditions for PUT, COPY and MOVE . . . . . 32 92 7.2. Additional Preconditions for PUT . . . . . . . . . . . . . 32 93 7.3. Additional Precondition for DELETE . . . . . . . . . . . . 33 94 7.4. Additional Precondition for PROPPATCH . . . . . . . . . . 33 95 8. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 8.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 34 97 8.1.1. Handling a REFRESH . . . . . . . . . . . . . . . . . . 35 98 8.1.2. Response to a POST request . . . . . . . . . . . . . . 35 99 8.1.3. Status Codes for use with the POST method . . . . . . 36 100 8.1.4. Example - Simple meeting invitation refresh . . . . . 37 101 8.1.5. Example - Freebusy lookup . . . . . . . . . . . . . . 38 102 8.2. Retrieving incoming scheduling messages . . . . . . . . . 39 103 9. Scheduling Access Control . . . . . . . . . . . . . . . . . . 40 104 9.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 40 105 9.1.1. Privileges on Scheduling Inbox Collections . . . . . . 40 106 9.1.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . 40 107 9.1.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . 40 108 9.1.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . 41 109 9.1.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . 41 110 9.1.2. Privileges on Scheduling Outbox Collections . . . . . 41 111 9.1.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . 41 112 9.1.2.2. CALDAV:schedule-send-invite Privilege . . . . . . 41 113 9.1.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . 42 114 9.1.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . 42 115 9.1.3. Aggregation of Scheduling Privileges . . . . . . . . . 42 116 9.2. Additional Principal Properties . . . . . . . . . . . . . 43 117 9.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 43 118 9.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 43 119 9.2.3. CALDAV:calendar-user-address-set Property . . . . . . 44 120 9.2.4. CALDAV:calendar-user-type Property . . . . . . . . . . 45 121 10. Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 122 11. XML Element Definitions . . . . . . . . . . . . . . . . . . . 46 123 11.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 46 124 11.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 46 125 11.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 47 126 11.4. CALDAV:request-status XML Element . . . . . . . . . . . . 47 127 12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 128 12.1. Verifying scheduling requests . . . . . . . . . . . . . . 47 129 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 48 130 13.1. HTTP header registration . . . . . . . . . . . . . . . . . 48 131 13.1.1. Schedule-Reply Request Header Registration . . . . . . 49 132 13.2. iCalendar Registrations . . . . . . . . . . . . . . . . . 49 133 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49 134 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 135 15.1. Normative References . . . . . . . . . . . . . . . . . . . 49 136 15.2. Informative References . . . . . . . . . . . . . . . . . . 50 137 Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 50 138 A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 50 139 A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 52 140 Appendix B. Changes (to be removed prior to publication as an 141 RFC) . . . . . . . . . . . . . . . . . . . . . . . . 54 142 B.1. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 54 143 B.2. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 55 145 1. Introduction 147 This document specifies an extension to the CalDAV calendar-access 148 feature [RFC4791] to enable scheduling of iCalendar-based [RFC2445] 149 calendar components between calendar users. This extension leverages 150 the scheduling methods defined in the iCalendar Transport-independent 151 Interoperability Protocol iTIP [RFC2446] to permit calendar users to 152 perform scheduling transactions such as schedule, reschedule, respond 153 to scheduling request or cancel scheduled calendar components, as 154 well as search for busy time information. 156 iTIP [RFC2446] outlines a model where calendar users exchange 157 scheduling messages with one another. Often times, calendar user 158 agents are made responsible for generating and sending scheduling 159 messages as well as processing incoming scheduling messages. This 160 approach yields a number of problems, including: 162 o The handling of incoming scheduling messages and the updates to 163 calendars imposed by these messages only occurs when calendar user 164 agents are active. 166 o For most updates to a calendar, calendar user agents need to 167 address a separate scheduling message to the Organizer or the 168 Attendees. 170 o Due to the update latency it is possible for calendars of 171 different calendar users to reflect different, inaccurate states. 173 This specification is using an alternative approach where the server 174 is made responsible for sending most scheduling messages and 175 processing most incoming scheduling messages. This approach frees 176 the calendar user agents from the delivery and processing of most 177 scheduling messages and ensures a better consistency of the data in 178 the users' calendars on the server. The simple operation of 179 creating, modifying or deleting a calendar object resource in a 180 calendar is enough to trigger the CalDAV server to deliver 181 appropriate scheduling messages to the calendar users. 183 Discussion of this Internet-Draft is taking place on the mailing list 184 . 186 1.1. Level of Support for iTIP 188 While the scheduling features described in this specification are 189 based on iTIP [RFC2446], some of its more complex features have 190 deliberately not been implemented, in order to keep this 191 specification simple. In particular, the following iTIP [RFC2446] 192 features are not supported: 194 o Sending scheduling messages with the METHODs "PUBLISH", "COUNTER" 195 and "DECLINE-COUNTER" 197 o Delegating an Event to another calendar user 199 o Changing the Organizer 201 o Forwarding to an uninvited calendar user 203 The goal of this specification is to provide the essential scheduling 204 features needed, and it is anticipated that future extensions will be 205 developed to address the more complex features if the demand arises. 207 1.2. XML Namespaces 209 Definitions of XML elements in this document use XML element type 210 declarations (as found in XML Document Type Declarations), described 211 in Section 3.2 of [W3C.REC-xml-20060816]. 213 The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML 214 elements defined in this specification, or in other Standards Track 215 IETF RFCs written to extend CalDAV. It MUST NOT be used for 216 proprietary extensions. 218 Note that the XML declarations used in this document are incomplete, 219 in that they do not include namespace information. Thus, the reader 220 MUST NOT use these declarations as the only way to create valid 221 CalDAV properties or to validate CalDAV XML element types. Some of 222 the declarations refer to XML elements defined by WebDAV which use 223 the "DAV:" namespace. Wherever such elements appear, they are 224 explicitly given the "DAV:" prefix to help avoid confusion. 225 Additionally, some of the elements used here are defined in CalDAV 226 [RFC4791]. 228 Also note that some CalDAV XML element names are identical to WebDAV 229 XML element names, though their namespace differs. Care MUST be 230 taken not to confuse the two sets of names. 232 1.3. Notational Conventions 234 The augmented BNF used by this document to describe protocol elements 235 is described in Section 2.1 of [RFC2616]. Because this augmented BNF 236 uses the basic production rules provided in Section 2.2 of [RFC2616], 237 those rules apply to this document as well. 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in [RFC2119]. 243 When XML element types in the namespaces "DAV:" and 244 "urn:ietf:params:xml:ns:caldav" are referenced in this document 245 outside of the context of an XML fragment, the string "DAV:" and 246 "CALDAV:" will be prefixed to the element types respectively. 248 1.4. Terminology 250 Calendar User Agent (CUA): Software with which the calendar user 251 communicates with a calendar service or local calendar store to 252 access calendar information. 254 Calendar collection: Same as [RFC4791]. 256 Calendar object resource: Same as [RFC4791]. 258 Scheduling object resource: A calendar object resource contained in 259 a calendar collection for which the server will take care of 260 sending scheduling messages on behalf of the owner of the calendar 261 collection. 263 Organizer scheduling object resource: A scheduling object resource 264 owned by an Organizer. 266 Attendee scheduling object resource: A scheduling object resource 267 owned by an Attendee. 269 Automatic scheduling transaction: Add, change or remove operations 270 on a scheduling object resource for which the server will deliver 271 scheduling messages to other users. 273 Explicit scheduling request: Scheduling requests targeted at a 274 scheduling Outbox collection. 276 Scheduling message: A calendar object resource that describes a 277 scheduling transaction such as publish, schedule, reschedule, 278 respond to scheduling requests, or cancel calendar components. 280 Scheduling Outbox collection: A resource at which explicit 281 scheduling requests are targeted. 283 Scheduling Inbox collection: A collection in which a recipient's 284 incoming scheduling messages are delivered. 286 1.5. Open Issues 288 1. Need to discuss in a limited fashion how group calendar user 289 addresses might be handled. 291 2. Need a mechanism to allow clients to be able to do "weak" If- 292 Match updates to calendar data without the "strong" ETag 293 behavior. 295 2. CalDAV Scheduling Support 297 In order for a server to support the scheduling extensions defined in 298 this specification it MUST support all of the CalDAV calendar-access 299 feature [RFC4791]. 301 A server that supports the features described in this document MUST 302 include "calendar-auto-schedule" as a field in the DAV response 303 header from an OPTIONS request on any resource that supports any 304 scheduling actions, properties, privileges or methods. 306 >> Request << 308 OPTIONS /lisa/calendar/outbox/ HTTP/1.1 309 Host: cal.example.com 311 >> Response << 313 HTTP/1.1 204 No Content 314 Date: Thu, 31 Mar 2005 09:00:00 GMT 315 Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE, 316 Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL 317 DAV: 1, 2, 3, access-control 318 DAV: calendar-access, calendar-auto-schedule 320 In this example, the OPTIONS response indicates that the server 321 supports both the "calendar-access" and "calendar-auto-schedule" 322 features and that resource "/lisa/calendar/outbox/" supports the 323 properties, reports, methods, and privileges defined in this 324 specification. 326 3. Scheduling Process 328 The process of scheduling a meeting between different parties often 329 involves a series of steps with different "actors" playing particular 330 roles during the whole process. Typically there is a meeting 331 "Organizer" whose role is to setup a meeting between one or more 332 meeting "Attendees", and this is done by sending out invitations and 333 handling responses from each Attendee. 335 This process can typically be broken down into two phases. 337 In the first phase, the Organizer tries to determine a time for the 338 meeting that ought to be acceptable to each Attendee. This involves 339 finding out when each Attendee is available during the period of time 340 in which the meeting needs to occur (or simply finding a suitable 341 time for all attendees to come together for the meeting), and 342 determining when the most appropriate time is for which each Attendee 343 is free. This process is called a "freebusy" lookup. 345 In the second phase, the Organizer sends out invitations to each 346 Attendee using the time determined from the freebusy lookup - or a 347 suitable guess as to an appropriate time based on other factors if 348 freebusy lookup is not feasible. There then follows a process of 349 negotiation between Organizer and Attendees regarding the invitation. 350 Some Attendees may choose to attend at the original time provided by 351 the Organizer, others may decline to attend. The Organizer needs to 352 process each of the replies from the Attendees and take appropriate 353 action to confirm the meeting, reschedule it or perhaps cancel it. 355 The user "expectation" as to how a calendaring and scheduling system 356 should respond in each of these two phases is somewhat different. In 357 the case of a freebusy lookup, users expect to get back results 358 immediately so that they can then move on to the invitation phase as 359 quickly as possible. In the case of invitations, it is expected that 360 each Attendee will reply with their participation status in their own 361 time, so delays in receiving replies are anticipated. Thus 362 calendaring and scheduling systems should treat these two operational 363 phases in different ways to accommodate the user expectations, and 364 this specification does that. 366 The scenario above covers the case of scheduling events ("VEVENT" 367 components) between calendar users, and doing freebusy lookups 368 ("VFREEBUSY" components). However, iCalendar [RFC2445] also allows 369 for sending "VTODO" and "VJOURNAL" components as described in iTIP 370 [RFC2446]. Since this specification is based on iTIP, "VTODO" and 371 "VJOURNAL" components can also be used. For the majority of the 372 following discussion, scheduling of events and freebusy lookups will 373 be discussed as these are the more common operations. 375 In this specification there are two primary modes of carrying out a 376 scheduling transaction. For an "automatic scheduling transaction", 377 calendar data created, modified or removed from calendar collections 378 cause scheduling operations to occur. For an "explicit scheduling 379 request", scheduling operations are triggered by an HTTP POST request 380 to a special resource. iTIP freebusy lookups and iTIP "METHOD: 381 REFRESH" operations are done via explicit scheduling requests. All 382 other scheduling operations defined in iTIP, except for "METHOD: 383 COUNTER" and "METHOD:DECLINECOUNTER" which are not supported, are 384 done via automatic scheduling transactions. 386 3.1. Scheduling Collections 388 This specification introduces new collection resource types that are 389 used for managing resources specific to scheduling, in addition to 390 regular calendar object resources. 392 3.1.1. Scheduling Outbox Collection 394 A scheduling Outbox collection is used as the target for initiating 395 the processing of manual scheduling messages. Currently the only 396 defined use for this is for "VFREEBUSY" "REQUEST" iTIP messages to 397 request a synchronous freebusy lookup for a number of calendar users. 399 A scheduling Outbox collection MUST report the DAV:collection and 400 CALDAV:schedule-outbox XML elements in the value of the DAV: 401 resourcetype property. The element type declaration for CALDAV: 402 schedule-outbox is: 404 406 Example: 408 409 410 411 413 New WebDAV ACL [RFC3744] privileges can be used on the scheduling 414 Outbox collection to control who is allowed to send scheduling 415 messages on behalf of the calendar user associated with the 416 scheduling Outbox collection. See Section 9.1 for more details. 418 A scheduling Outbox collection MUST NOT be a child (at any depth) of 419 a calendar collection resource. 421 A scheduling Outbox collection MAY have the following WebDAV 422 properties defined (as per calendar collections in [RFC4791]): 424 CALDAV:supported-calendar-component-set - when present this 425 indicates the allowed calendar component types for scheduling 426 messages submitted to the scheduling Outbox collection with the 427 POST method. 429 CALDAV:supported-calendar-data - when present this indicates the 430 allowed media types for scheduling messages submitted to the 431 scheduling Outbox collection with the POST method. 433 CALDAV:max-resource-size - when present this indicates the maximum 434 size of a resource in octets that the server is willing to accept 435 for scheduling messages submitted to the scheduling Outbox 436 collection with the POST method. 438 CALDAV:min-date-time - when present this indicates the earliest 439 date and time (in UTC) that the server is willing to accept for 440 any DATE or DATE-TIME value in scheduling messages submitted to 441 the scheduling Outbox collection with the POST method. 443 CALDAV:max-date-time - when present this indicates the latest date 444 and time (in UTC) that the server is willing to accept for any 445 DATE or DATE-TIME value in scheduling messages submitted to the 446 scheduling Outbox collection with the POST method. 448 CALDAV:max-instances - when present this indicates the maximum 449 number of recurrence instances in scheduling messages submitted to 450 the scheduling Outbox collection with the POST method. 452 CALDAV:max-attendees-per-instance - when present this indicates 453 the maximum number of ATTENDEE properties in any instance of 454 scheduling messages submitted to the scheduling Outbox collection 455 with the POST method. 457 3.1.2. Scheduling Inbox Collection 459 A scheduling Inbox collection contains incoming scheduling messages. 460 These may be requests sent by an Organizer, or replies sent by an 461 Attendee in response to a request. 463 A scheduling Inbox collection MUST report the DAV:collection and 464 CALDAV:schedule-inbox XML elements in the value of the DAV: 465 resourcetype property. The element type declaration for CALDAV: 466 schedule-inbox is: 468 470 Example: 472 473 474 475 477 Every resource in the scheduling Inbox collection MUST be a valid 478 calendar object resource that defines a scheduling message (i.e. an 479 iCalendar object that follows the iTIP semantic). Note, that unlike 480 calendar collections defined by the CalDAV calendar-access feature, 481 there are no restrictions on the nature of the resources stored 482 (e.g., there is no need to verify that the "UID"s of each resource 483 are unique) beyond the restrictions of iTIP itself. The removal of 484 the "UID" restriction, in particular, is needed because multiple 485 scheduling messages may be sent for one particular calendar 486 component, and each of those will have the same "UID" property in the 487 calendar object resource. This also implies that a scheduling Inbox 488 collection cannot contain any types of WebDAV collection resources. 490 New WebDAV ACL [RFC3744] privileges can be set on the scheduling 491 Inbox collection to control who the user associated with the 492 scheduling Inbox collection will accept scheduling messages from. 493 See Section 9.1 for more details. 495 A scheduling Inbox collection MUST NOT be a child (at any depth) of a 496 calendar collection resource. 498 A scheduling Inbox collection MAY have the following WebDAV 499 properties defined (as per calendar collections in [RFC4791]): 501 CALDAV:calendar-timezone - when present this contains a time zone 502 that the server can use when calendar date-time operations are 503 carried out, for example when a time-range CALDAV:calendar-query 504 REPORT is targeted at a scheduling Inbox collection. 506 CALDAV:supported-calendar-component-set - when present this 507 indicates the allowed calendar component types for scheduling 508 messages delivered to the scheduling Inbox collection. 510 CALDAV:supported-calendar-data - when present this indicates the 511 allowed media types for scheduling messages delivered to the 512 scheduling Inbox collection. 514 CALDAV:max-resource-size - when present this indicates the maximum 515 size of a resource in octets that the server is willing to accept 516 for scheduling messages delivered to the scheduling Inbox 517 collection. 519 CALDAV:min-date-time - when present this indicates the earliest 520 date and time (in UTC) that the server is willing to accept for 521 any DATE or DATE-TIME value in scheduling messages delivered to 522 the scheduling Inbox collection. 524 CALDAV:max-date-time - when present this indicates the latest date 525 and time (in UTC) that the server is willing to accept for any 526 DATE or DATE-TIME value in scheduling messages delivered to the 527 scheduling Inbox collection. 529 CALDAV:max-instances - when present this indicates the maximum 530 number of recurrence instances in scheduling messages delivered to 531 the scheduling Inbox collection. 533 CALDAV:max-attendees-per-instance - when present this indicates 534 the maximum number of ATTENDEE properties in any instance of 535 scheduling messages delivered to the scheduling Inbox collection. 537 3.2. Automatic Scheduling Transactions 539 3.2.1. Introduction 541 When a calendar object resource is created, modified or removed from 542 a calendar collection that supports the operations defined in this 543 specification (either via a PUT, DELETE, COPY or MOVE HTTP request), 544 the server examines the calendar data and checks to see whether the 545 data represents a scheduling object resource. If it does, the server 546 will take care of automatically sending and processing scheduling 547 messages to the appropriate recipients. Several types of scheduling 548 operation can occur in this case, equivalent to iTIP "REQUEST", 549 "REPLY", "CANCEL" and "ADD" operations. 551 When a scheduling transaction is processed by the server, it will 552 attempt to deliver a scheduling message to each recipient. 554 3.2.2. Identifying Scheduling Object Resources 556 The server will only perform automatic scheduling transactions on 557 creations, modifications, and deletions of valid scheduling object 558 resources. There are two types of scheduling object resources: 559 organizer scheduling object resources, and attendee scheduling object 560 resources. 562 A calendar object resource is considered to be a valid organizer 563 scheduling object resource if the "ORGANIZER" iCalendar property is 564 present and set in all the calendar components to a value that 565 matches one of the calendar user addresses of the owner of the 566 calendar collection. 568 A calendar object resource is considered to be a valid attendee 569 scheduling object resource if the "ORGANIZER" iCalendar property is 570 present and set in all the calendar components to the same value and 571 doesn't match one of the calendar user addresses of the owner of the 572 calendar collection, and that at least one of the "ATTENDEE" 573 iCalendar property values match one of the calendar user addresses of 574 the owner of the calendar collection. 576 The creation of attendee scheduling object resources will typically 577 be done by the server in cases where a default calendar collection is 578 defined (see Section 3.5.2. In cases where no default calendar 579 collection is defined, the server MAY prevent calendar user agents 580 from forging attendee scheduling object resources by forbidding their 581 creation or imposing restrictions on their creation. For instance, a 582 server MAY require the presence of a scheduling message, received 583 from the "ORGANIZER" with the same "UID" property value, in the 584 scheduling Inbox collection of the owner of the calendar collection. 586 3.2.3. Handling Scheduling Object Resources 588 The server's behavior when processing a scheduling object resource 589 depends on whether it is owned by the Organizer or an Attendee 590 specified in the calendar data. 592 3.2.3.1. Organizer Scheduling Object Resources 594 An Organizer can create, modify or remove a scheduling object 595 resource by issuing HTTP requests with an appropriate method. The 596 create, modify and remove behaviors for the server are each described 597 next, and the way these are invoked via HTTP requests is described in 598 Section 3.2.3.3. 600 3.2.3.1.1. Actions on Organizer Scheduling Object Resource 602 3.2.3.1.1.1. Create 604 When a scheduling object resource is created by the Organizer, the 605 server will inspect each "ATTENDEE" property to determine which ones 606 have the "SCHEDULE-AGENT" iCalendar property parameter. 608 For each Attendee the server will determine whether to attempt to 609 deliver a scheduling message into the Attendee's scheduling Inbox 610 collection, based on the table below: 612 +------------------+-------------+ 613 | SCHEDULE-AGENT | iTIP METHOD | 614 +==================+=============+ 615 | SERVER (default) | REQUEST | 616 +------------------+-------------+ 617 | CLIENT | -- | 618 +------------------+-------------+ 619 | NONE | -- | 620 +------------------+-------------+ 622 The attempt to deliver the scheduling message will either succeed or 623 fail. In all cases, the server MUST add a "SCHEDULE-STATUS" 624 iCalendar property parameter to the "ATTENDEE" iCalendar property in 625 the scheduling object resource being created, and set its value as 626 described in Section 3.5.4. This will result in the created calendar 627 object resource differing from the calendar data sent in the HTTP 628 request. As a result clients MAY reload the calendar data from the 629 server as soon as it is stored in order to update to the new server 630 generated state information. Servers MUST NOT set the "SCHEDULE- 631 STATUS" property on any "ATTENDEE" properties for Attendees that were 632 not sent a scheduling message. 634 Restrictions: 636 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar 637 property parameter value of the "ATTENDEE" iCalendar property of 638 other users in the calendar object resource to a value other than 639 "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value 640 is not present or set to the value "SERVER". To maintain 641 consistency for organizers and attendees hosted on the server 642 itself, a server will typically choose to enforce the requirement 643 that only an Attendee can change their own "PARTSTAT" to a value 644 other than "NEEDS-ACTION". 646 2. The server MUST reject any attempt to create a duplicate 647 scheduling object resource in any of the calendar collections 648 owned by the Organizer. A duplicate scheduling object resource 649 is one with the same "UID" as an existing scheduling object 650 resource. 652 3. The server MUST take into account scheduling privileges when 653 handling the creation of a scheduling object resource as 654 described in Section 9.1. 656 4. Restrictions from [RFC4791] MUST also be enforced. 658 3.2.3.1.1.2. Modify 660 When a scheduling object resource is modified by the Organizer, the 661 server will inspect each "ATTENDEE" property in the new calendar data 662 to determine which ones have the "SCHEDULE-AGENT" iCalendar property 663 parameter. It will then need to compare this with the "ATTENDEE" 664 properties in the existing calendar object resource that is being 665 modified. 667 For each Attendee in the old and new calendar data on a per-instance 668 basis, and taking into account the addition or removal of Attendees, 669 the server will determine whether to deliver a scheduling message to 670 the Attendee. The following table determines whether the server 671 needs to deliver a scheduling message, and if so which iTIP 672 scheduling method to use. The values "SERVER", "CLIENT" and "NONE" 673 in the top and left titles of the table refer to the "SCHEDULE-AGENT" 674 parameter value of the "ATTENDEE" property, and the values "" 675 and "" are used to cover the cases where the "ATTENDEE" 676 property is not present (Old) or is being removed (New). 678 +---------------+-----------------------------------------------+ 679 | | New | 680 | ATTENDEE +-----------+-----------+-----------+-----------+ 681 | | | SERVER | CLIENT | NONE | 682 | | | (default) | | | 683 +===+===========+===========+===========+===========+===========+ 684 | | | -- | REQUEST / | -- | -- | 685 | | | | ADD | | | 686 | +-----------+-----------+-----------+-----------+-----------+ 687 | | SERVER | CANCEL | REQUEST | CANCEL | CANCEL | 688 | O | (default) | | | | | 689 | l +-----------+-----------+-----------+-----------+-----------+ 690 | d | CLIENT | -- | REQUEST / | -- | -- | 691 | | | | ADD | | | 692 | +-----------+-----------+-----------+-----------+-----------+ 693 | | NONE | -- | REQUEST / | -- | -- | 694 | | | | ADD | | | 695 +---+-----------+-----------+-----------+-----------+-----------+ 697 The attempt to deliver the scheduling message will either succeed or 698 fail. In all cases, the server MUST add a "SCHEDULE-STATUS" 699 iCalendar property parameter to the "ATTENDEE" iCalendar property in 700 the scheduling object resource being modified, and set its value as 701 described in Section 3.5.4. This will result in the created calendar 702 object resource differing from the calendar data sent in the HTTP 703 request. As a result clients MAY reload the calendar data from the 704 server as soon as it is stored in order to update to the new server 705 generated state information. 707 Restrictions: 709 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar 710 property parameter value of the "ATTENDEE" iCalendar property of 711 other users in the calendar object resource to a value other than 712 "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value 713 is not present or set to the value "SERVER". To maintain 714 consistency for organizers and attendees hosted on the server 715 itself, a server will typically choose to enforce the requirement 716 that only an Attendee can change their own "PARTSTAT" to a value 717 other than "NEEDS-ACTION". 719 2. The server MUST take into account scheduling privileges when 720 handling the modification of a scheduling object resources as 721 described in Section Section 9.1. 723 3. Restrictions from [RFC4791] MUST also be enforced. 725 3.2.3.1.1.3. Remove 727 When a scheduling object resource is removed by the Organizer, the 728 server will inspect each "ATTENDEE" property in the scheduling object 729 resource being removed to determine which ones have the "SCHEDULE- 730 AGENT" iCalendar property parameter. 732 For each Attendee the server will determine whether to attempt to 733 deliver a scheduling message into the Attendee's scheduling Inbox 734 collection, based on the table below: 736 +------------------+-------------+ 737 | SCHEDULE-AGENT | iTIP METHOD | 738 +==================+=============+ 739 | SERVER (default) | CANCEL | 740 +------------------+-------------+ 741 | CLIENT | -- | 742 +------------------+-------------+ 743 | NONE | -- | 744 +------------------+-------------+ 746 The attempt to deliver the scheduling message will either succeed or 747 fail. 749 Restrictions: 751 1. The server MUST take into account scheduling privileges when 752 handling the removal of a scheduling object resource as described 753 in Section 9.1. 755 3.2.3.2. Attendee Scheduling Object Resources 757 An Attendee can create, modify or remove a scheduling object resource 758 by issuing HTTP requests with an appropriate method. The create, 759 modify and remove behaviors for the server are each described next, 760 and the way these are invoked via HTTP requests is described in 761 Section 3.2.3.3. 763 3.2.3.2.1. Actions on a Scheduling Object Resource 765 3.2.3.2.1.1. Allowed Attendee Changes 767 Attendees are allowed to make some changes to a scheduling object 768 resource, though the key scheduling properties such as start, end, 769 location, summary etc are typically under the control of the 770 Organizer of the event. 772 The server MUST allow attendees to: 774 1. change their own "PARTSTAT" iCalendar property parameter value. 776 2. add or remove "X-" iCalendar property parameters on their own 777 "ATTENDEE" properties. 779 3. add, modify or remove any "TRANSP" iCalendar properties. 781 4. add, modify or remove any "X-" iCalendar properties in any 782 component. 784 5. add, modify or remove any "VALARM" iCalendar components. 786 6. modify the "PRODID" iCalendar property within the top-level 787 "VCALENDAR" component. 789 7. add, modify or remove "CALSCALE" or "X-" iCalendar properties 790 within the top-level "VCALENDAR" component. 792 8. create new components to represent overridden recurrence 793 instances, provided the only changes to the recurrence instance 794 follow the rules above. 796 3.2.3.2.1.2. Create 798 A scheduling object resource is created by an Attendee when the 799 client creates a scheduling object resource corresponding to an 800 unprocessed scheduling message currently in that Attendee's 801 scheduling Inbox collection. 803 The Attendee is allowed to make changes as noted above. 805 If the Attendee changes one or more "PARTSTAT" iCalendar property 806 values on any component, or adds an overridden component with a 807 changed "PARTSTAT" property, then the server MUST deliver an iTIP 808 "REPLY" scheduling message to the Organizer to indicate the new 809 participation status of the Attendee. 811 The attempt to deliver the scheduling message will either succeed or 812 fail. In all cases, the server MUST add a "SCHEDULE-STATUS" 813 iCalendar property parameter to the "ORGANIZER" iCalendar property in 814 the scheduling object resource being created, and set its value as 815 described in Section 3.5.4. This will result in the created calendar 816 object resource differing from the calendar data sent in the HTTP 817 request. As a result clients MAY reload the calendar data from the 818 server as soon as it is stored in order to update to the new server 819 generated state information. 821 3.2.3.2.1.3. Modify 823 Behavior is as per the Create action above. 825 3.2.3.2.1.4. Remove 827 When a scheduling object resource is removed by the Attendee, one of 828 two possibilities exist: 830 1. If the HTTP request contains a request header "Schedule-Reply" 831 set to the value "T" or there is no "Schedule-Reply" request 832 header, then the server MUST attempt to deliver a scheduling 833 message to the Organizer indicating that the Attendee has a 834 "PARTSTAT" iCalendar property parameter value set to "DECLINED". 835 i.e., the Attendee has chosen not to attend any instances. If 836 the server is unable to deliver the scheduling message, the 837 remove action MUST fail, and an appropriate "SCHEDULE-STATUS" 838 iCalendar property parameter set on the "ORGANIZER" property in 839 the scheduling object resource stored by the server. 841 2. If the HTTP request contains a request header "Schedule-Reply" 842 set to the value "F", the server MUST NOT attempt to deliver a 843 scheduling message. The resource is simply removed. This 844 provides the client a way to silently remove unwanted scheduling 845 attempts. 847 3.2.3.3. HTTP Methods 849 This section describes how use of various HTTP Methods on a 850 scheduling object resource will cause a create, modify or remove 851 action on that resource as described above. 853 3.2.3.3.1. PUT 855 When a PUT method request is received, the server will execute the 856 following actions, provided all appropriate pre-conditions are met: 858 +--------------------------+--------------------------+-------------+ 859 | Existing Destination | Resulting Destination | Server | 860 | Resource | Resource | Action | 861 +--------------------------+--------------------------+-------------+ 862 | None | Calendar object resource | None (1) | 863 | None | Scheduling object | Create (2) | 864 | | resource | | 865 | Calendar object resource | Calendar object resource | None | 866 | Calendar object resource | Scheduling object | Create (1) | 867 | | resource | | 868 | Scheduling object | Calendar object resource | Remove | 869 | resource | | | 870 | Scheduling object | Scheduling object | Modify | 871 | resource | resource | | 872 +--------------------------+--------------------------+-------------+ 874 Note 1. The server MUST verify that no scheduling object resource 875 exists in any other of the owner's calendar collections with the same 876 UID as the resource being created. 878 Note 2. The server MUST verify that no calendar object resource 879 exists in any other of the owner's calendar collections with the same 880 UID as the resource being created. 882 3.2.3.3.2. COPY 884 When a COPY method request is received, the server will execute the 885 following actions based on the source and destination collections in 886 the request: 888 +-------------------------+-------------------------+---------------+ 889 | Source Collection | Destination Collection | Server Action | 890 +-------------------------+-------------------------+---------------+ 891 | Non-calendar collection | Non-calendar collection | None | 892 | Non-calendar collection | Calendar collection | (1) | 893 | Calendar collection | Non-calendar collection | None | 894 | Calendar collection | Calendar collection | (2) | 895 +-------------------------+-------------------------+---------------+ 897 Note 1. The same rules as used for PUT above are applied for the 898 destination of the COPY request. 900 Note 2. If the resource being copied is a scheduling object resource 901 the server MUST generate an error as scheduling object resources 902 cannot be duplicated. If the resource being copied is not a 903 scheduling object resource no server action occurs. 905 3.2.3.3.3. MOVE 907 When a MOVE method request is received, the server will execute the 908 following actions based on the source and destination collections in 909 the request: 911 +-------------------------+-------------------------+---------------+ 912 | Source Collection | Destination Collection | Server Action | 913 +-------------------------+-------------------------+---------------+ 914 | Non-calendar collection | Non-calendar collection | None | 915 | Non-calendar collection | Calendar collection | (1) | 916 | Calendar collection | Non-calendar collection | (2) | 917 | Calendar collection | Calendar collection | (3) | 918 +-------------------------+-------------------------+---------------+ 920 Note 1. The same rules as used for PUT above are applied for the 921 destination of the MOVE request. 923 Note 2. The same rules as used for DELETE below are applied for the 924 source of the MOVE request. 926 Note 3. If the destination resource does not exist the server action 927 is None. If the source and destination resources are not scheduling 928 object resources then the server action is None. In all other cases 929 the server MUST generate an error as scheduling object resources 930 cannot be duplicated or overwritten by different scheduling object 931 resources. 933 3.2.3.3.4. DELETE 935 When a DELETE method is targeted at a scheduling object resource the 936 server will execute the Remove action. 938 When a DELETE method is targeted at a calendar collection the server 939 will execute the Remove action on all scheduling object resources 940 contained in the calendar collection. 942 3.3. Processing of incoming scheduling messages 944 Scheduling operations can cause the delivery of a scheduling message 945 into an Organizer's or Attendee's scheduling Inbox collection. In 946 the former case the scheduling messages are replies or refresh 947 requests from Attendees, in the latter case the scheduling messages 948 are requests, cancellations or additions from the Organizer. 950 In some cases the server will automatically process the scheduling 951 message, in other cases the scheduling message will be left for the 952 client to process. In each case, the scheduling message in the 953 scheduling Inbox collection is used as an indicator to the client 954 that a scheduling operation has taken place. 956 3.3.1. Automatic processing for the Organizer 958 3.3.1.1. Processing an Attendee reply 960 For a scheduling message reply sent by an Attendee, the server first 961 locates the corresponding scheduling object resource belonging to the 962 Organizer. 964 The server MUST then update the "PARTSTAT" iCalendar parameter value 965 of each "ATTENDEE" iCalendar property in the scheduling object 966 resource to match the changes indicated in the reply (taking into 967 account the fact that an Attendee could have created a new overridden 968 iCalendar component to indicate different participation status on one 969 or more instances of a recurring event). 971 The server MUST also update or add the "SCHEDULE-STATUS" property 972 parameter on each matching "ATTENDEE" iCalendar property and sets its 973 value to that of the "REQUEST-STATUS" property in the reply, or to 974 "2.0" if "REQUEST-STATUS" is not present (also taking into account 975 recurrence instances). 977 At the same time, the server MUST add the CALDAV:schedule-state 978 WebDAV property with the value CALDAV:schedule-processed (see 979 Section 6.3) to the scheduling message in the Inbox scheduling 980 collection. 982 The server MUST send scheduling messages to all the other Attendees 983 indicating the change in participation status of the Attendee 984 replying, subject to the recurrence requirements of Section 3.5.1. 986 3.3.1.2. Processing an Attendee refresh 988 TODO: write something here. 990 3.3.2. Automatic processing for the Attendee 992 For a scheduling message sent by the Organizer, the server first 993 tries to locate a corresponding scheduling object resource belonging 994 to the Attendee. If no matching scheduling object resource exists, 995 the server treats the scheduling message as a new message, otherwise 996 it is treated as an update. 998 3.3.2.1. Processing a new scheduling message 1000 When a scheduling message containing new calendar components is 1001 detected, two possibilities exist, depending on whether a "default" 1002 calendar (Section 3.5.2) is set for the Attendee: 1004 1. if no valid default calendar is set, the server leaves the 1005 scheduling message in the scheduling Inbox collection, but it 1006 MUST add the CALDAV:schedule-state WebDAV property with the value 1007 CALDAV:schedule-unprocessed (see Section 6.3) to the scheduling 1008 message. It is then up to the client to explicitly process the 1009 scheduling message and remove it from the scheduling Inbox 1010 collection once it has done so. 1012 2. if a valid default calendar is set, the server MUST process the 1013 scheduling message and create an appropriate scheduling object 1014 resource in the default calendar set for the Attendee. At the 1015 same time it MUST add the CALDAV:schedule-state WebDAV property 1016 with the value CALDAV:schedule-processed (see Section 6.3) to the 1017 scheduling message. 1019 3.3.2.2. Processing a scheduling message update 1021 When an update to scheduling message is detected, the server MUST 1022 update the matching scheduling object resource belonging to the 1023 Attendee to reflect the changes proposed in the scheduling message. 1024 At the same time it MUST add the CALDAV:schedule-state WebDAV 1025 property with the value CALDAV:schedule-processed (see Section 6.3) 1026 to the scheduling message. 1028 3.3.3. Processing by the client 1030 When a client detects a scheduling message in the scheduling Inbox 1031 collection it needs to look at the CALDAV:schedule-state WebDAV 1032 property on the resource and act accordingly: 1034 1. if CALDAV:schedule-state is set to CALDAV:schedule-unprocessed, 1035 then it is the client's responsibility to process the scheduling 1036 message and remove it from the scheduling Inbox collection once 1037 it has done so. 1039 2. if CALDAV:schedule-state is set to CALDAV:schedule-processed, 1040 then the server has already processed the scheduling message, but 1041 has left it in the scheduling Inbox collection to serve as a 1042 notification to the client that a change has been made to the 1043 corresponding scheduling object resource. It is then the 1044 client's responsibility to remove the scheduling object resource 1045 from the scheduling Inbox collection once it has made note of the 1046 fact that a change has occurred. 1048 3.4. Explicit Scheduling Request 1050 An explicit scheduling request sends a scheduling message via an HTTP 1051 POST request targeted at a scheduling Outbox collection. Full 1052 details can be found in Section 8.1. 1054 3.5. Other Considerations 1056 3.5.1. Handling recurring items 1058 3.5.1.1. Restricting what is sent 1060 When delivering scheduling messages for recurring calendar components 1061 to Attendees, servers MUST ensure that Attendees only get information 1062 about recurrence instances that explicitly include them as an 1063 Attendee. 1065 For example, if an Attendee is invited to a single recurrence 1066 instance of a recurring event, and no others, the scheduling object 1067 resource contained in the Organizer's calendar collection will 1068 contain an overridden instance in the form of a separate calendar 1069 component. That separate calendar component will include the 1070 "ATTENDEE" property referencing the "one-off" Attendee. That 1071 Attendee will not be listed in any other calendar components in the 1072 scheduling object resource. The scheduling message that will be 1073 delivered to the Attendee will only contain information about this 1074 overridden instance. 1076 As another example, an Attendee could be excluded from one instance 1077 of a recurring event. In that case the scheduling object resource 1078 contained in the calendar collection of the Organizer will include an 1079 overridden instance with an "ATTENDEE" list that does not include the 1080 Attendee being excluded. The scheduling message that will be 1081 delivered to the Attendee will not specify the overridden instance 1082 but rather include an "EXDATE" property in the master recurring 1083 component defining the recurrence set. 1085 This requirement is needed to ensure that Attendees only have access 1086 to calendar data for items they have been explicitly invited to. 1088 3.5.1.2. Attendee overrides 1090 When a recurring scheduling message is sent to an Attendee, that 1091 Attendee may wish to reply with different participation status on one 1092 or more recurrence instances. In order to do that it will need to 1093 add an overridden iCalendar component for the instances with 1094 different participation status, and send that as a reply back to the 1095 Organizer. The Organizer will then need to incorporate any new 1096 overridden instances into the matching scheduling object resource to 1097 ensure that the Attendee's participation status is accurately 1098 recorded for all recurrence instances. 1100 3.5.2. Handling the Default Calendar 1102 A calendar user may have multiple calendars representing different 1103 "spheres of activity". However, scheduling requests are targeted at 1104 calendar users and not a specific calendar of a calendar user. Often 1105 it is not appropriate to automatically deliver a scheduling message 1106 to a particular calendar because that scheduling message refers to an 1107 event for a different "sphere of activity". By storing all incoming 1108 scheduling requests in a separate special collection, clients can 1109 process the requests in that collection and choose which calendar 1110 ("sphere of activity") the request belongs to and make its own 1111 arrangements to place the relevant calendar object in that calendar. 1113 This specification defines the concept of a "default" calendar 1114 collection. If a valid default calendar collection is specified, 1115 then servers are required to automatically process new scheduling 1116 messages and create the appropriate scheduling object resource in the 1117 default calendar collection. If there is no valid default calendar, 1118 then the server does not automatically process new scheduling 1119 messages, and instead leaves it up to the client to process the 1120 scheduling message and create the appropriate scheduling object 1121 resource in a calendar collection chosen by the calendar user. 1122 Servers MAY prevent deletion of the default calendar. 1124 In order to manage this behavior, a new CALDAV:schedule-default- 1125 calendar-URL WebDAV property is defined for use on scheduling Inbox 1126 collections. This property is used to define the default calendar 1127 collection, if one is required. See Section 6.2. 1129 3.5.3. DTSTAMP and SEQUENCE properties 1131 Whenever the server generates a scheduling message for delivery to a 1132 recipient, it MUST ensure that a "DTSTAMP" iCalendar property is 1133 present and MUST set the value to the UTC time that the scheduling 1134 message was generated (as required by iCalendar). 1136 iTIP [RFC2446] places certain requirements on how the "SEQUENCE" 1137 iCalendar property value in scheduling messages changes. The server 1138 MUST ensure that for each type of scheduling operation, the 1139 "SEQUENCE" iCalendar property value is appropriately updated. If the 1140 client does not update the "SEQUENCE" iCalendar property itself when 1141 that is required, the server MUST update the property and change any 1142 scheduling object resource accordingly. 1144 3.5.4. Schedule Status Values 1146 When scheduling with an Attendee there are two types of status 1147 information that can be returned during the transaction. The first 1148 status information is a "delivery" status that indicates whether the 1149 scheduling message from the Organizer to the Attendee was delivered 1150 or not, or what the current status of delivery is. The second status 1151 information is a "reply" status corresponding to the Attendee's own 1152 "REQUEST-STATUS" information from the scheduling message reply that 1153 is sent back to the Organizer. 1155 Similarly, when an Attendee sends a reply back to the Organizer, 1156 there will be "delivery" status information for the scheduling 1157 message sent to the Organizer. However, there is no "REQUEST-STATUS" 1158 sent back by the Organizer, so there is no equivalent of the "reply" 1159 status as per scheduling messages to Attendees. 1161 The "delivery" status information on an "ORGANIZER" or "ATTENDEE" 1162 iCalendar property is conveyed in the "SCHEDULE-STATUS" property 1163 parameter value (Section 4.2). The status code value for "delivery" 1164 status can be one of the following: 1166 +----------+--------------------------------------------------------+ 1167 | Delivery | Description | 1168 | Status | | 1169 | Code | | 1170 +----------+--------------------------------------------------------+ 1171 | 1.0 | The scheduling message is pending. i.e. the server is | 1172 | | still in the process of sending the message. The | 1173 | | status code value can be expected to change once the | 1174 | | server has completed its sending and delivery | 1175 | | attempts. | 1176 | | | 1177 | 1.1 | The scheduling message has been successfully sent. | 1178 | | However, the server does not have explicit information | 1179 | | about whether the scheduling message was successfully | 1180 | | delivered to the recipient. This state can occur with | 1181 | | "store and forward" style scheduling protocols such as | 1182 | | iMIP [RFC2447] (iTIP using email). | 1183 | | | 1184 | 1.2 | The scheduling message has been successfully | 1185 | | delivered. | 1186 | | | 1187 | 3.7 | The scheduling message was not delivered because the | 1188 | | server did not recognize the calendar user address of | 1189 | | the recipient as being a supported URI. | 1190 | | | 1191 | 3.8 | The scheduling message was not delivered because | 1192 | | access privileges do not allow it. | 1193 | | | 1194 | 5.1 | The scheduling message was not delivered because the | 1195 | | server could not complete delivery of the message. | 1196 | | This is likely due to a temporary failure, and the | 1197 | | originator can try to send the message again at a | 1198 | | later time. | 1199 | | | 1200 | 5.2 | The scheduling message was not delivered because the | 1201 | | server was not able to find a suitable way to deliver | 1202 | | the message. This is likely a permanent failure, and | 1203 | | the originator should not try to send the message | 1204 | | again, at least without verifying/correcting the | 1205 | | calendar user address of the recipient. | 1206 | | | 1207 | 5.3 | The scheduling message was not delivered and was | 1208 | | rejected because scheduling with that recipient is not | 1209 | | allowed. This is likely a permanent failure, and the | 1210 | | originator should not try to send the message again. | 1211 +----------+--------------------------------------------------------+ 1213 The status code for "reply" status can be any of the valid iTIP 1214 [RFC2446] "REQUEST-STATUS" values. 1216 3.5.5. Error Handling 1218 TODO: e.g. how to deal with failed cancels. 1220 3.5.6. Organizer is an Attendee 1222 The Organizer of a scheduled event may also be an Attendee of that 1223 event. In such cases the server MUST NOT send a scheduling message 1224 to the Attendee that matches the Organizer. 1226 4. New iCalendar Parameters 1228 This section describes additions to iCalendar [RFC2445] to support 1229 CalDAV scheduling. 1231 4.1. Schedule Agent 1233 Parameter Name: SCHEDULE-AGENT 1234 Purpose: Indicates what agent is expected to handle scheduling for 1235 the corresponding Attendee. 1237 Format Definition: This property parameter is defined by the 1238 following notation: 1240 scheduleagentparam = "SCHEDULE-AGENT" "=" 1241 ("SERVER" ; The server handles scheduling 1242 / "CLIENT" ; The client handles scheduling 1243 / "NONE" ; No automatic scheduling 1244 / x-name ; Experimental type 1245 / iana-token) ; Other IANA registered type 1246 ; Default is SERVER 1248 Description: This property parameter MAY be present on any 1249 "ATTENDEE" iCalendar property. In the absence of this parameter, 1250 the value "SERVER" MUST be used for the default behavior. The 1251 value determines whether or not an automatic scheduling 1252 transaction on a server will cause a scheduling message to be sent 1253 to the corresponding calendar user identified by the "ATTENDEE" 1254 property value. When the value "SERVER" is specified (or the 1255 parameter is absent) then it is the server's responsibility to 1256 send a scheduling messages as part of an automatic scheduling 1257 transaction. When the value "CLIENT" is specified, that indicates 1258 that the client is handling scheduling messages with the calendar 1259 user itself. When "NONE" is specified, no scheduling messages are 1260 being sent to the calendar user. 1262 Servers MUST NOT include this parameter in any scheduling messages 1263 sent as the result of an automatic scheduling transaction. 1265 Clients SHOULD NOT include this parameter in any scheduling 1266 messages that they themselves send. 1268 Example: 1270 ATTENDEE;SCHEDULE-AGENT=SERVER:mailto:cyrus@example.org 1272 4.2. Schedule Status 1274 Parameter Name: SCHEDULE-STATUS 1276 Purpose: Indicates the status code returned from processing of the 1277 most recent scheduling message sent to the corresponding Attendee, 1278 or received from the corresponding Organizer. 1280 Format Definition: This property parameter is defined by the 1281 following notation: 1283 schedulestatusparam = "SCHEDULE-STATUS" "=" statcode 1284 ; statcode defined in RFC2445. 1286 Description: This property parameter may be present on any 1287 "ATTENDEE" or "ORGANIZER" iCalendar property. 1289 Servers MUST add this parameter to any "ATTENDEE" properties 1290 corresponding to calendar users who were sent a scheduling message 1291 via an automatic scheduling transaction. Clients SHOULD NOT 1292 change or remove this parameter if it was provided by the server. 1293 In the case where the client is handling the scheduling, the 1294 client MAY add, change or remove this parameter to indicate the 1295 last scheduling message status it received. 1297 Servers MUST add this parameter to any "ORGANIZER" properties 1298 corresponding to calendar users who were sent a scheduling message 1299 reply by an Attendee via an automatic scheduling transaction. 1300 Clients SHOULD NOT change or remove this parameter if it was 1301 provided by the server. In the case where the client is handling 1302 the scheduling the client MAY add, change or remove this parameter 1303 to indicate the last scheduling message status it received. 1305 Servers MUST NOT include this parameter in any scheduling messages 1306 sent as the result of an automatic scheduling transaction. 1308 Clients SHOULD NOT include this parameter in any scheduling 1309 messages that they themselves send. 1311 Suitable values for this property parameter are described in 1312 Section 3.5.4. 1314 Example: 1316 ATTENDEE;SCHEDULE-STATUS="2.0":mailto:cyrus@example.org 1318 5. New WebDAV Request Headers 1320 The CalDAV scheduling extension defines the following new WebDAV 1321 request headers for use with CalDAV. 1323 5.1. Schedule-Reply Request Header 1325 ScheduleReply = "Schedule-Reply" ":" ("T" | "F") 1327 When an Attendee executes an HTTP DELETE request on a scheduling 1328 object resource, and the Schedule-Reply header is not present, or 1329 present and set to the value "T", the server MUST send an appropriate 1330 iTIP "REPLY" scheduling message with the Attendee's "PARTSTAT" 1331 iCalendar property parameter value set to "DECLINED" as part of its 1332 normal automatic scheduling transaction processing. 1334 When the Schedule-Reply header is set to the value "F", the server 1335 MUST NOT send an iTIP scheduling message as part of its normal 1336 automatic scheduling transaction processing. 1338 The Schedule-Reply request header is used by a client to indicate to 1339 a server whether or not an automatic scheduling transaction should 1340 occur when an Attendee deletes a scheduling object resource. In 1341 particular it controls whether an iTIP "REPLY" message is sent to the 1342 Organizer as a result of the deletion. There are situations in which 1343 unsolicited scheduling messages need to be silently deleted (or 1344 ignored) for security or privacy reasons. The new header allows the 1345 scheduling message to be suppressed if such a need arises. 1347 All scheduling object resources MUST support the Schedule-Reply 1348 header. 1350 6. New WebDAV Properties 1352 The CalDAV scheduling extension defines the following new WebDAV 1353 properties for use with CalDAV. 1355 6.1. CALDAV:schedule-calendar-transp Property 1357 Name: schedule-calendar-transp 1359 Namespace: urn:ietf:params:xml:ns:caldav 1361 Purpose: Determines whether the calendar object resources in a 1362 calendar collection will affect the owner's freebusy. 1364 Protected: This property MAY be protected and SHOULD NOT be returned 1365 by a PROPFIND allprop request (as defined in Section 14.2 of 1366 [RFC4918]). 1368 COPY/MOVE behavior: This property value SHOULD be kept during a MOVE 1369 operation, but is normally re-initialized when a resource is 1370 created with a COPY. It should not be set in a COPY. 1372 Description: This property SHOULD be defined on all calendar object 1373 resources. If present, it contains one of two XML elements that 1374 indicate whether the calendar object resources should contribute 1375 to the owner's freebusy or not. When the 'opaque' element is 1376 used, all calendar object resources MUST contribute to freebusy, 1377 assuming access privileges and other iCalendar properties allow it 1378 to. When the 'transparent' XML element is used, all calendar 1379 object resources MUST NOT contribute to freebusy. 1381 If this property is not present on a calendar collection, then the 1382 default value of 'opaque' MUST be assumed. 1384 Definition: 1386 1388 1389 1391 1392 1394 Example: 1396 1398 1399 1401 6.2. CALDAV:schedule-default-calendar-URL Property 1403 Name: schedule-default-calendar-URL 1405 Namespace: urn:ietf:params:xml:ns:caldav 1407 Purpose: Specifies a default calendar for an attendee that will 1408 automatically have new scheduling messages deposited into it when 1409 they arrive. 1411 Protected: This property MAY be protected in the case where a server 1412 supports only a single calendar collection, or does not support 1413 changing the default calendar, or does not support a default 1414 calendar. 1416 COPY/MOVE behavior: This property is only defined on a scheduling 1417 Inbox collection which cannot be moved or copied. 1419 Description: This property MAY be defined on a scheduling Inbox 1420 collection. If present, it contains zero or one DAV:href XML 1421 elements. When a DAV:href element is present, its value indicates 1422 a URL to a calendar collection that is used as the default 1423 calendar. When no DAV:href element is present, it indicates that 1424 there is no default calendar. In the absence of this property 1425 there is no default calendar. 1427 Definition: 1429 1431 Example: 1433 1435 /calendars/users/cdaboo/calendar/ 1436 1438 6.3. CALDAV:schedule-state Property 1440 Name: schedule-state 1442 Namespace: urn:ietf:params:xml:ns:caldav 1444 Purpose: Indicates whether a scheduling message in a scheduling 1445 Inbox collection has been processed as part of an automatic 1446 scheduling transaction. 1448 Protected: This property MUST be protected as only the server can 1449 carry out automatic processing of scheduling messages. 1451 COPY/MOVE behavior: This property is only defined on a scheduling 1452 message in a scheduling Inbox collection. If a scheduling message 1453 is copied or moved into a scheduling Inbox collection, this 1454 property MUST NOT be set. 1456 Description: This property MAY be defined on a scheduling resource 1457 in a scheduling Inbox collection. If present, it contains one of 1458 two XML elements. When the CALDAV:schedule-unprocessed XML 1459 element is used, it indicates that the scheduling message has not 1460 been automatically processed by the server, and thus needs action 1461 on the part of the client. When the CALDAV:schedule-processed XML 1462 element is used, it indicates that automatic processing of the 1463 scheduling message has taken place, so no scheduling operations 1464 are needed by the client. 1466 Definition: 1468 1470 1471 1473 1474 1476 Example: 1478 1479 1480 1482 7. New Preconditions 1484 7.1. Additional Preconditions for PUT, COPY and MOVE 1486 This specification requires additional Preconditions for the PUT, 1487 COPY and MOVE methods. The preconditions are: 1489 (CALDAV:unique-scheduling-object-resource): Only one scheduling 1490 object resource with a particular iCalendar property "UID" value 1491 MUST exist in the system for each Organizer and each Attendee. 1493 (CALDAV:same-organizer-in-all-components): All the calendar 1494 components in a scheduling object resource MUST contain the same 1495 "ORGANIZER" property value if the "ORGANIZER" property is present. 1497 7.2. Additional Preconditions for PUT 1499 This specification requires additional Preconditions for the PUT 1500 method. The preconditions are: 1502 (CALDAV:allowed-organizer-scheduling-object-change): The following 1503 restrictions exist for the "PARTSTAT" property value in scheduling 1504 object resources created or modified by an Organizer: 1506 1. when creating a scheduling object resource the Organizer MAY 1507 NOT set the "PARTSTAT" iCalendar parameter value to anything 1508 other than "NEEDS-ACTION" if the corresponding "ATTENDEE" 1509 property includes the "SCHEDULE-AGENT" iCalendar parameter 1510 with its value set to "SERVER", or no "SCHEDULE-AGENT" 1511 parameter is present. 1513 2. when modifying a scheduling object resource the Organizer MAY 1514 NOT change the "PARTSTAT" iCalendar parameter value to 1515 anything other than "NEEDS-ACTION" if the corresponding 1516 "ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar 1517 parameter with its value set to "SERVER", or no "SCHEDULE- 1518 AGENT" parameter is present. 1520 (CALDAV:allowed-attendee-scheduling-object-change): When creating 1521 or modifying a scheduling object resource the Attendee can only 1522 make the following changes: 1524 1. any iCalendar parameter on any "ATTENDEE" property whose value 1525 corresponds to the calendar user address of the Attendee 1527 2. add, change or remove a "TRANSP" property in any component 1529 3. add, change or remove a "COMMENT" property in any component 1531 4. add, change or remove a "PERCENT-COMPLETE" property in any 1532 component 1534 5. change the "PRODID" property in the top-level "VCALENDAR" 1535 component 1537 6. add, change or remove the "CALSCALE" property in the top-level 1538 "VCALENDAR" component 1540 7. add, change or remove any "VALARM" components 1542 8. create overridden recurring instances with only changes as 1543 detailed above 1545 The Attendee MUST NOT make any other type of change. 1547 7.3. Additional Precondition for DELETE 1549 This specification require an additional Preconditions for the PUT 1550 method. The preconditions are: 1552 (CALDAV:default-calendar-delete-allowed): The server MAY allow 1553 deletion of the default calendar collection. 1555 7.4. Additional Precondition for PROPPATCH 1557 This specification requires an additional Precondition for the 1558 property response elements in PROPPATCH method response. The 1559 precondition is: 1561 (CALDAV:valid-schedule-default-calendar-URL): When the server 1562 allows the client to change the CALDAV:schedule-default-calendar- 1563 URL property on a scheduling Inbox collection, the URL specified 1564 in any DAV:href element MUST reference a calendar collection owned 1565 by the owner of the scheduling Inbox collection. 1567 8. Scheduling 1569 8.1. POST Method 1571 The POST method submits a scheduling or freebusy message to one or 1572 more recipients by targeting the request at the URI of a scheduling 1573 Outbox collection. The request body of a POST method MUST contain a 1574 scheduling message or freebusy message (e.g., an iCalendar object 1575 that follows the iTIP semantic). The resource identified by the 1576 Request-URI MUST be a resource collection of type CALDAV:schedule- 1577 outbox (Section 3.1.1). 1579 Only specific types of scheduling message are allowed in a POST 1580 request on a scheduling Outbox collection: 1582 +----------------+---------------------------------+ 1583 | iTIP METHOD | COMPONENT | 1584 +----------------+---------------------------------+ 1585 | PUBLISH | None | 1586 | REQUEST | VFREEBUSY | 1587 | REPLY | None | 1588 | ADD | None | 1589 | CANCEL | None | 1590 | REFRESH | Any except VTIMEZONE, VFREEBUSY | 1591 | COUNTER | None | 1592 | DECLINECOUNTER | None | 1593 +----------------+---------------------------------+ 1595 Servers SHOULD reject any scheduling message that is not allowed. 1596 However, for backwards compatibility with earlier versions of this 1597 specification, servers MAY return a valid schedule response result 1598 indicating success for the iTIP operation being executed. 1600 Preconditions: 1602 (CALDAV:supported-collection): The Request-URI MUST identify the 1603 location of a scheduling Outbox collection; 1605 (CALDAV:supported-calendar-data): The resource submitted in the 1606 POST request MUST be a supported media type (i.e. text/calendar) 1607 for scheduling or freebusy messages; 1609 (CALDAV:valid-calendar-data): The resource submitted in the POST 1610 request MUST be valid data for the media type being specified 1611 (i.e. valid iCalendar object); 1612 (CALDAV:valid-scheduling-message): The resource submitted in the 1613 POST request MUST obey all restrictions specified for the POST 1614 request (e.g., the scheduling message follows the restrictions of 1615 iTIP); 1617 (CALDAV:originator-allowed): The currently authenticated user MUST 1618 be granted the CALDAV:schedule-deliver privilege or a suitable 1619 sub-privilege on the scheduling Outbox collection being targeted 1620 by the request; 1622 (CALDAV:organizer-allowed): The calendar user identified by the 1623 "ORGANIZER" property in the POST request's scheduling message MUST 1624 be the calendar user (or one of the calendar users) associated 1625 with the scheduling Outbox collection being targeted by the 1626 request when the scheduling message is an outgoing scheduling 1627 message; 1629 (CALDAV:max-resource-size): The resource submitted in the POST 1630 request MUST have an octet size less than or equal to the value of 1631 the CALDAV:max-resource-size property value [RFC4791]on the 1632 scheduling Outbox collection targeted by the request; 1634 Postconditions: None 1636 8.1.1. Handling a REFRESH 1638 When an iTIP REFRESH scheduling message is executed, the server 1639 delivers the scheduling message to the calendar user specified by the 1640 "ORGANIZER" property value in the scheduling object resource that was 1641 submitted to the scheduling Outbox collection with the POST method. 1643 8.1.2. Response to a POST request 1645 A POST request may deliver a scheduling message to one or more 1646 calendar user recipients. Since the behavior of each recipient may 1647 vary, it is useful to get response status information for each 1648 recipient in the overall POST response. This specification defines a 1649 new XML response to convey multiple recipient status. 1651 A response to a POST method that indicates status for one or more 1652 recipients MUST be a CALDAV:schedule-response XML element. This MUST 1653 contain one or more CALDAV:response elements for each recipient, with 1654 each of those containing elements that indicate which recipient they 1655 correspond to, the scheduling status of the request for that 1656 recipient, any error codes and an optional description. See 1657 Section 11.1. 1659 In the case of a freebusy request, the CALDAV:response elements can 1660 also contain CALDAV:calendar-data elements which contain freebusy 1661 information (e.g., an iCalendar VFREEBUSY component) indicating the 1662 busy state of the corresponding recipient, assuming that the freebusy 1663 request for that recipient succeeded. 1665 8.1.3. Status Codes for use with the POST method 1667 The following are examples of response codes one would expect to be 1668 used for this method. Note, however, that unless explicitly 1669 prohibited any 2/3/4/5xx series response code may be used in a 1670 response. 1672 200 (OK) - The command succeeded. 1674 201 (Created) - The command succeeded and a new resource was 1675 created in the scheduling Outbox collection. 1677 400 (Bad Request) - The client has provided an invalid scheduling 1678 message. 1680 403 (Forbidden) - The client cannot submit a scheduling message to 1681 the specified Request-URI. 1683 404 (Not Found) - The URL in the Request-URI was not present. 1685 423 (Locked) - The specified resource is locked and the client 1686 either is not a lock owner or the lock type requires a lock token 1687 to be submitted and the client did not submit it. 1689 507 (Insufficient Storage) - The server did not have sufficient 1690 space to record the scheduling message in a scheduling Outbox 1691 collection being targeted by the POST request. 1693 8.1.4. Example - Simple meeting invitation refresh 1695 >> Request << 1697 POST /bernard/calendar/outbox/ HTTP/1.1 1698 Host: cal.example.com 1699 Content-Type: text/calendar 1700 Content-Length: xxxx 1702 BEGIN:VCALENDAR 1703 VERSION:2.0 1704 PRODID:-//Example Corp.//CalDAV Client//EN 1705 METHOD:REFRESH 1706 BEGIN:VEVENT 1707 DTSTAMP:20040901T200200Z 1708 ORGANIZER:mailto:lisa@example.com 1709 ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE 1710 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr 1711 uisseaux:mailto:bernard@example.com 1712 END:VEVENT 1713 END:VCALENDAR 1715 >> Response << 1717 HTTP/1.1 200 OK 1718 Date: Thu, 02 Sep 2004 16:53:32 GMT 1719 Content-Type: application/xml; charset="utf-8" 1720 Content-Length: xxxx 1722 1723 1725 1726 1727 mailto:lisa@example.com 1728 1729 2.0;Success 1730 Delivered to recipient 1731 scheduling inbox 1732 1733 1735 In this example, the client requests the server to deliver a 1736 "REFRESH" scheduling message to the Organizer of the meeting 1737 mailto:lisa@example.com. The response indicates that delivery to the 1738 relevant scheduling Inbox collection of the Organizer was 1739 accomplished successfully. 1741 8.1.5. Example - Freebusy lookup 1743 >> Request << 1745 POST /lisa/calendar/outbox/ HTTP/1.1 1746 Host: cal.example.com 1747 Content-Type: text/calendar 1748 Content-Length: xxxx 1750 BEGIN:VCALENDAR 1751 VERSION:2.0 1752 PRODID:-//Example Corp.//CalDAV Client//EN 1753 METHOD:REQUEST 1754 BEGIN:VFREEBUSY 1755 DTSTAMP:20040901T200200Z 1756 ORGANIZER:mailto:lisa@example.com 1757 DTSTART:20040902T000000Z 1758 DTEND:20040903T000000Z 1759 UID:34222-232@example.com 1760 ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@ 1761 example.com 1762 ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com 1763 END:VFREEBUSY 1764 END:VCALENDAR 1766 >> Response << 1768 HTTP/1.1 200 OK 1769 Date: Thu, 02 Sep 2004 16:53:32 GMT 1770 Content-Type: application/xml; charset="utf-8" 1771 Content-Length: xxxx 1773 1774 1776 1777 1778 mailto:bernard@example.com 1779 1780 2.0;Success 1781 BEGIN:VCALENDAR 1782 VERSION:2.0 1783 PRODID:-//Example Corp.//CalDAV Server//EN 1784 METHOD:REPLY 1785 BEGIN:VFREEBUSY 1786 DTSTAMP:20040901T200200Z 1787 ORGANIZER:mailto:lisa@example.com 1788 DTSTART:20040902T000000Z 1789 DTEND:20040903T000000Z 1790 UID:34222-232@example.com 1791 ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@ 1792 example.com 1793 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 1794 20040902T090000Z,20040902T170000Z/20040903T000000Z 1795 END:VFREEBUSY 1796 END:VCALENDAR 1797 1798 1799 1800 1801 mailto:cyrus@example.com 1802 1803 2.0;Success 1804 BEGIN:VCALENDAR 1805 VERSION:2.0 1806 PRODID:-//Example Corp.//CalDAV Server//EN 1807 METHOD:REPLY 1808 BEGIN:VFREEBUSY 1809 DTSTAMP:20040901T200200Z 1810 ORGANIZER:mailto:lisa@example.com 1811 DTSTART:20040902T000000Z 1812 DTEND:20040903T000000Z 1813 UID:34222-232@example.com 1814 ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com 1815 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 1816 20040902T090000Z,20040902T170000Z/20040903T000000Z 1817 FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z 1818 END:VFREEBUSY 1819 END:VCALENDAR 1820 1821 1822 1824 In this example, the client requests the server to determine the busy 1825 information of the calendar users mailto:bernard@example.com and 1826 mailto:cyrus@example.com, over the time range specified by the 1827 scheduling message sent in the request. The response includes 1828 "VFREEBUSY" components for each of those calendar users with their 1829 busy time indicated. 1831 8.2. Retrieving incoming scheduling messages 1833 Incoming scheduling messages will be stored in a scheduling Inbox 1834 collection. As per Section 10, CalDAV calendar-access reports work 1835 on scheduling collections, so the client can use those to get partial 1836 information on scheduling messages in the scheduling Inbox 1837 collection. 1839 9. Scheduling Access Control 1841 9.1. Scheduling Privileges 1843 CalDAV servers MUST support and adhere to the requirements of WebDAV 1844 ACL [RFC3744]. Furthermore, CalDAV servers that advertise support 1845 for the "calendar-auto-schedule" feature MUST also support the 1846 scheduling privileges defined in this section. 1848 All the scheduling privileges MUST be non-abstract and MUST appear in 1849 the DAV:supported-privilege-set property of scheduling Outbox and 1850 Inbox collections on which they are defined. 1852 The tables specified in Appendix A clarifies which scheduling methods 1853 (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling 1854 privilege defined in this section. 1856 9.1.1. Privileges on Scheduling Inbox Collections 1858 This section defines new WebDAV ACL privileges that are for use on 1859 scheduling Inbox collections. These privileges determine whether a 1860 calendar user is allowed to have scheduling messages delivered to the 1861 calendar user who "owns" the scheduling Inbox collection. This 1862 allows calendar users to choose which other calendar users can 1863 schedule with them. 1865 The privileges defined in this section are ignored if applied to a 1866 resource other than a scheduling Inbox collection. 1868 9.1.1.1. CALDAV:schedule-deliver Privilege 1870 CALDAV:schedule-deliver is an aggregate privilege that contains all 1871 the scheduling privileges that control the processing and delivery of 1872 incoming scheduling messages, that is, CALDAV:schedule-deliver-invite 1873 and CALDAV:schedule-deliver-reply, as well as freebusy requests 1874 targeted at the owner of the scheduling Inbox collection, that is, 1875 CALDAV:schedule-query-freebusy. 1877 1879 9.1.1.2. CALDAV:schedule-deliver-invite Privilege 1881 The CALDAV:schedule-deliver-invite privilege controls the processing 1882 and delivery of scheduling messages coming from an Organizer. 1884 1886 9.1.1.3. CALDAV:schedule-deliver-reply Privilege 1888 The CALDAV:schedule-deliver-reply privilege controls the processing 1889 and delivery of scheduling messages coming from an Attendee. 1891 1893 9.1.1.4. CALDAV:schedule-query-freebusy Privilege 1895 The CALDAV:schedule-query-freebusy privilege controls freebusy 1896 requests targeted at the owner of the scheduling Inbox collection. 1898 1900 9.1.2. Privileges on Scheduling Outbox Collections 1902 This section defines new WebDAV ACL privileges that are defined for 1903 use on scheduling Outbox collections. These privileges determine 1904 which calendar users are allowed to send scheduling messages on 1905 behalf of the calendar user who "owns" the scheduling Outbox 1906 collection. This allows calendar users to choose other calendar 1907 users who can act on their behalf to schedule with other calendar 1908 users (e.g. assistants working on behalf of their boss). 1910 The privileges defined in this section are ignored if applied to a 1911 resource other than a scheduling Outbox collection. 1913 9.1.2.1. CALDAV:schedule-send Privilege 1915 CALDAV:schedule-send is an aggregate privilege that contains all the 1916 scheduling privileges that control the use of methods that will cause 1917 scheduling messages to be delivered to other users, that is, CALDAV- 1918 schedule-send-invite and CALDAV-schedule-send-reply, as well as 1919 freebusy requests to be targeted at other users, that is, CALDAV- 1920 schedule-send-freebusy. 1922 1924 9.1.2.2. CALDAV:schedule-send-invite Privilege 1926 The CALDAV:schedule-send-invite privilege controls the sending of 1927 scheduling messages by Organizers. 1929 Users granted the DAV:bind privilege on a calendar collection, or 1930 DAV:write privilege on scheduling object resources, will also need 1931 the CALDAV:schedule-send-invite privilege granted on the scheduling 1932 Outbox collection of the owner of the calendar collection or 1933 scheduling object resource in order to be allowed to create, modify 1934 or delete scheduling object resources in a way that will trigger the 1935 CalDAV server to deliver organizer scheduling messages to other 1936 calendar users. 1938 1940 9.1.2.3. CALDAV:schedule-send-reply Privilege 1942 The CALDAV:schedule-send-invite privilege controls the sending of 1943 scheduling messages by Attendees. 1945 Users granted the DAV:bind privilege on a calendar collection, or 1946 DAV:write privilege on scheduling object resources, will also need 1947 the CALDAV:schedule-send-reply privilege granted on the scheduling 1948 Outbox collection of the owner of the calendar collection or 1949 scheduling object resource in order to be allowed to create, modify 1950 or delete scheduling object resources in a way that will trigger the 1951 CalDAV server to deliver attendee scheduling messages to other 1952 calendar users. 1954 1956 9.1.2.4. CALDAV:schedule-send-freebusy Privilege 1958 The CALDAV:schedule-send-freebusy privilege controls the use of the 1959 POST method to submit scheduling messages that specify the scheduling 1960 method "REQUEST" with a "VFREEBUSY" calendar component. 1962 1964 9.1.3. Aggregation of Scheduling Privileges 1966 Server implementations MUST aggregate the scheduling privileges as 1967 follows: 1969 DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule- 1970 deliver; 1972 CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite, 1973 CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy; 1975 CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver- 1976 invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query- 1977 freebusy. 1979 The following diagram illustrates how scheduling privileges are 1980 aggregated according to the above requirements. 1982 [DAV:all] (aggregate) 1983 | 1984 +-- [CALDAV:schedule-deliver] (aggregate) 1985 | | 1986 | +-- [CALDAV:schedule-deliver-invite] 1987 | +-- [CALDAV:schedule-deliver-reply] 1988 | +-- [CALDAV:schedule-query-freebusy] 1989 | 1990 +-- [CALDAV:schedule-send] (aggregate) 1991 | 1992 +-- [CALDAV:schedule-send-invite] 1993 +-- [CALDAV:schedule-send-reply] 1994 +-- [CALDAV:schedule-send-freebusy] 1996 9.2. Additional Principal Properties 1998 This section defines new properties for WebDAV principal resources as 1999 defined in RFC3744 [RFC3744]. These properties are likely to be 2000 protected but the server MAY allow them to be written by appropriate 2001 users. 2003 9.2.1. CALDAV:schedule-inbox-URL Property 2005 Name: schedule-inbox-URL 2007 Namespace: urn:ietf:params:xml:ns:caldav 2009 Purpose: Identify the URL of the scheduling Inbox collection owned 2010 by the associated principal resource. 2012 Conformance: This property MAY be protected and SHOULD NOT be 2013 returned by a PROPFIND allprop request (as defined in Section 14.2 2014 of [RFC4918]). 2016 Description: This property is needed for a client to determine where 2017 the scheduling Inbox collection of the current user is located so 2018 that processing of scheduling messages can occur. 2020 Definition: 2022 2024 9.2.2. CALDAV:schedule-outbox-URL Property 2025 Name: schedule-outbox-URL 2027 Namespace: urn:ietf:params:xml:ns:caldav 2029 Purpose: Identify the URL of the scheduling Outbox collection owned 2030 by the associated principal resource. 2032 Conformance: This property MAY be protected and SHOULD NOT be 2033 returned by a PROPFIND allprop request (as defined in Section 14.2 2034 of [RFC4918]). 2036 Description: This property is needed for a client to determine where 2037 the scheduling Outbox collection of the current user is located so 2038 that sending of scheduling messages can occur. 2040 Definition: 2042 2044 9.2.3. CALDAV:calendar-user-address-set Property 2046 Name: calendar-user-address-set 2048 Namespace: urn:ietf:params:xml:ns:caldav 2050 Purpose: Identify the calendar addresses of the associated principal 2051 resource. 2053 Conformance: This property MAY be protected and SHOULD NOT be 2054 returned by a PROPFIND allprop request (as defined in Section 14.2 2055 of [RFC4918]). Support for this property is REQUIRED. This 2056 property SHOULD be searchable using the DAV:principal-property- 2057 search REPORT. The DAV:principal-search-property-set REPORT 2058 SHOULD identify this property as such. 2060 Description: This property is needed to map calendar user addresses 2061 in iCalendar data to principal resources and their associated 2062 scheduling Inbox and Outbox collections. In the event that a user 2063 has no well defined identifier for their calendar user address, 2064 the URI of their principal resource can be used. 2066 Definition: 2068 2070 Example: 2072 2074 mailto:bernard@example.com 2075 mailto:bernard.desruisseaux@example.com 2076 2078 9.2.4. CALDAV:calendar-user-type Property 2080 Name: calendar-user-type 2082 Namespace: urn:ietf:params:xml:ns:caldav 2084 Purpose: Identifies the calendar user type of the associated 2085 principal resource. 2087 Conformance: This property MAY be protected and SHOULD NOT be 2088 returned by a PROPFIND allprop request (as defined in Section 14.2 2089 of [RFC4918]). Support for this property is OPTIONAL. This 2090 property SHOULD be searchable using the DAV:principal-property- 2091 search REPORT. The DAV:principal-search-property-set REPORT 2092 SHOULD identify this property as such. 2094 Description: This property is used to indicate the type of calendar 2095 user associated with the principal resource. Its value is the 2096 same as the iCalendar "CUTYPE" property parameter that can be used 2097 on "ATTENDEE" properties. 2099 Definition: 2101 2102 2105 Example: 2107 INDIVIDUAL< 2109 /C:calendar-user-type> 2111 10. Reports 2113 This specification extends the CALDAV:calendar-query and CALDAV: 2114 calendar-multiget reports to return results for calendar object 2115 resources in scheduling Inbox collections when the report directly 2116 targets such a collection. i.e. the Request-URI for a REPORT MUST be 2117 the URI of the scheduling Inbox collection or of a child resource 2118 within a scheduling Inbox collection. A report run on a regular 2119 collection that includes a scheduling Inbox collection as a child 2120 resource at any depth MUST NOT examine or return any calendar object 2121 resources from within any scheduling Inbox collections. 2123 When a CALDAV:calendar-query REPORT includes a time-range query and 2124 targets a scheduling Inbox collection, if any calendar object 2125 resources contain "VEVENT" calendar components that do not include a 2126 "DTSTART" iCalendar property (as allowed by iTIP [RFC2446]) then such 2127 components MUST always match the time-range query test. 2129 Note that the CALDAV:free-busy-query report is NOT supported on 2130 scheduling Inbox collections. 2132 11. XML Element Definitions 2134 11.1. CALDAV:schedule-response XML Element 2136 Name: schedule-response 2138 Namespace: urn:ietf:params:xml:ns:caldav 2140 Purpose: Contains the set of responses for a POST method request. 2142 Description: See Section 8.1.2. 2144 Definition: 2146 2148 11.2. CALDAV:response XML Element 2150 Name: response 2152 Namespace: urn:ietf:params:xml:ns:caldav 2154 Purpose: Contains a single response for a POST method request. 2156 Description: See Section 8.1.2. 2158 Definition: 2160 2166 11.3. CALDAV:recipient XML Element 2168 Name: recipient 2170 Namespace: urn:ietf:params:xml:ns:caldav 2172 Purpose: The calendar user address (recipient header value) that the 2173 enclosing response for a POST method request is for. 2175 Description: See Section 8.1.2. 2177 Definition: 2179 2181 11.4. CALDAV:request-status XML Element 2183 Name: request-status 2185 Namespace: urn:ietf:params:xml:ns:caldav 2187 Purpose: The iTIP "REQUEST-STATUS" property value for this response. 2189 Description: See Section 8.1.2. 2191 Definition: 2193 2195 12. Security Considerations 2197 The process of scheduling involves the sending and receiving of 2198 scheduling messages. As a result, the security problems related to 2199 messaging in general are relevant here. In particular the 2200 authenticity of the scheduling messages needs to be verified 2201 absolutely. Servers and clients MUST use an HTTP connection 2202 protected with TLS as defined in [RFC2818] for all scheduling 2203 transactions. 2205 12.1. Verifying scheduling requests 2207 When handling an implicit scheduling operation: 2209 Servers MUST verify that the currently authenticated user has the 2210 CALDAV:schedule-deliver privilege or a suitable sub-privilege on 2211 the scheduling Outbox collection of the DAV:owner of the calendar 2212 collection in which a scheduling object resource is being 2213 manipulated. 2215 Servers MUST verify that the principal associated with the DAV: 2216 owner of the calendar collection in which a scheduling object 2217 resource is being manipulated contains a CALDAV:schedule-outbox- 2218 URL property value. 2220 Servers MUST only deliver scheduling messages to recipients when 2221 the principal associated with the DAV:owner of the calendar 2222 collection in which a scheduling object resource is being 2223 manipulated has the CALDAV:schedule privilege or a suitable sub- 2224 privilege on the scheduling Inbox collections for recipient. 2226 To prevent impersonation of calendar users, the server MUST verify 2227 that the "ORGANIZER" property in an organizer scheduling object 2228 resource matches one of the calendar user addresses of the DAV: 2229 owner of the calendar collection in which the resource is stored. 2231 To prevent spoofing of an existing scheduling object resource, 2232 servers MUST verify that the "UID" iCalendar property value in a 2233 new scheduling object resource does not match that of an existing 2234 scheduling object resource with a different "ORGANIZER" property 2235 value. 2237 When handling a POST request on a scheduling Outbox collection: 2239 Servers MUST verify that the currently authenticated user has the 2240 CALDAV:schedule-deliver privilege or a suitable sub-privilege on 2241 the scheduling Outbox collection targeted by the request. 2243 Servers MUST verify that the principal associated with the 2244 calendar user address specified in the "ORGANIZER" property of the 2245 scheduling message data in the request contains a CALDAV:schedule- 2246 outbox-URL property value that matches the scheduling Outbox 2247 collection targeted by the request. 2249 Servers MUST verify that the principal associated with the 2250 calendar user address specified in the "ORGANIZER" property of the 2251 scheduling message data in the request has the CALDAV:schedule 2252 privilege or a suitable sub-privilege on all of the scheduling 2253 Inbox collections for those recipients to whom a scheduling 2254 message is being delivered. 2256 13. IANA Consideration 2258 13.1. HTTP header registration 2260 This specification registers one new header for use with HTTP as per 2261 [RFC3864]. 2263 13.1.1. Schedule-Reply Request Header Registration 2265 Header field name: Schedule-Reply 2267 Applicable protocol: http 2269 Status: standard 2271 Author/Change controller: IETF 2273 Specification document(s): this specification 2275 Related information: none 2277 13.2. iCalendar Registrations 2279 This specification registers two new iCalendar property parameters as 2280 defined in XXX. 2282 14. Acknowledgements 2284 The authors would like to thank the following individuals for 2285 contributing their ideas and support for writing this specification: 2286 Mike Douglass, Lisa Dusseault, Arnaud Quillaud, Julian F. Reschke, 2287 Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim Whitehead. 2289 The authors would also like to thank the Calendaring and Scheduling 2290 Consortium for advice with this specification, and for organizing 2291 interoperability testing events to help refine it. 2293 15. References 2295 15.1. Normative References 2297 [RFC2119] Bradner, S., "Key words for use in RFCs to 2298 Indicate Requirement Levels", BCP 14, 2299 RFC 2119, March 1997. 2301 [RFC2445] Dawson, F. and Stenerson, D., "Internet 2302 Calendaring and Scheduling Core Object 2303 Specification (iCalendar)", RFC 2445, 2304 November 1998. 2306 [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and 2307 R. Hopson, "iCalendar Transport-Independent 2308 Interoperability Protocol (iTIP) Scheduling 2309 Events, BusyTime, To-dos and Journal 2310 Entries", RFC 2446, November 1998. 2312 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, 2313 H., Masinter, L., Leach, P., and T. Berners- 2314 Lee, "Hypertext Transfer Protocol -- 2315 HTTP/1.1", RFC 2616, June 1999. 2317 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2318 May 2000. 2320 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. 2321 Whitehead, "Web Distributed Authoring and 2322 Versioning (WebDAV) Access Control Protocol", 2323 RFC 3744, May 2004. 2325 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, 2326 "Registration Procedures for Message Header 2327 Fields", BCP 90, RFC 3864, September 2004. 2329 [RFC4791] Daboo, C., Desruisseaux, B., and L. 2330 Dusseault, "Calendaring Extensions to WebDAV 2331 (CalDAV)", RFC 4791, March 2007. 2333 [RFC4918] Dusseault, L., "HTTP Extensions for Web 2334 Distributed Authoring and Versioning 2335 (WebDAV)", RFC 4918, June 2007. 2337 [W3C.REC-xml-20060816] Bray, T., Paoli, J., Sperberg-McQueen, C., 2338 Yergeau, F., and E. Maler, "Extensible Markup 2339 Language (XML) 1.0 (Fourth Edition)", World 2340 Wide Web Consortium Recommendation REC-xml- 2341 20060816, August 2006, 2342 . 2344 15.2. Informative References 2346 [RFC2447] Dawson, F., Mansour, S., and S. Silverberg, 2347 "iCalendar Message-Based Interoperability 2348 Protocol (iMIP)", RFC 2447, November 1998. 2350 Appendix A. Scheduling Privileges Summary 2352 A.1. Scheduling Inbox Privileges 2354 The following tables specify which scheduling privileges grant the 2355 right to a calendar user to deliver a scheduling message to the 2356 scheduling Inbox collection of another calendar user. The 2357 appropriate behavior depends on the calendar component type in the 2358 scheduling message and the scheduling "METHOD" in use. 2360 +-----------------------+ 2361 | METHOD for VEVENT | 2362 +---+---+---+---+---+---+ 2363 | P | R | R | A | C | R | 2364 | U | E | E | D | A | E | 2365 | B | Q | P | D | N | F | 2366 | L | U | L | | C | R | 2367 | I | E | Y | | E | E | 2368 +----------------------------+| S | S | | | L | S | 2369 | Scheduling Inbox Privilege || H | T | | | | H | 2370 +============================++===+===+===+===+===+===+ 2371 | schedule-deliver || * | * | * | * | * | * | 2372 | schedule-deliver-invite || * | * | | * | * | | 2373 | schedule-deliver-reply || | | * | | | * | 2374 | schedule-query-freebusy || | | | | | | 2375 +----------------------------++---+---+---+---+---+---+ 2377 +-----------------------+ 2378 | METHOD for VTODO | 2379 +---+---+---+---+---+---+ 2380 | P | R | R | A | C | R | 2381 | U | E | E | D | A | E | 2382 | B | Q | P | D | N | F | 2383 | L | U | L | | C | R | 2384 | I | E | Y | | E | E | 2385 +----------------------------+| S | S | | | L | S | 2386 | Scheduling Inbox Privilege || H | T | | | | H | 2387 +============================++===+===+===+===+===+===+ 2388 | schedule-deliver || * | * | * | * | * | * | 2389 | schedule-deliver-invite || * | * | | * | * | | 2390 | schedule-deliver-reply || | | * | | | * | 2391 | schedule-query-freebusy || | | | | | | 2392 +----------------------------++---+---+---+---+---+---+ 2393 +-----------------------+ 2394 | METHOD for VJOURNAL | 2395 +-------+-------+-------+ 2396 | P | A | C | 2397 | U | D | A | 2398 | B | D | N | 2399 | L | | C | 2400 | I | | E | 2401 +----------------------------+| S | | L | 2402 | Scheduling Inbox Privilege || H | | | 2403 +============================++=======+=======+=======+ 2404 | schedule-deliver || * | * | * | 2405 | schedule-deliver-invite || * | * | * | 2406 | schedule-deliver-reply || | | | 2407 | schedule-query-freebusy || | | | 2408 +----------------------------++-------+-------+-------+ 2410 +---------------+ 2411 | METHOD for | 2412 | VFREEBUSY | 2413 +-------+-------+ 2414 | P | R | 2415 | U | E | 2416 | B | Q | 2417 | L | U | 2418 | I | E | 2419 +----------------------------+| S | S | 2420 | Scheduling Inbox Privilege || H | T | 2421 +============================++=======+=======+ 2422 | schedule-deliver || * | * | 2423 | schedule-deliver-invite || * | | 2424 | schedule-deliver-reply || | | 2425 | schedule-query-freebusy || | * | 2426 +----------------------------++-------+-------+ 2428 A.2. Scheduling Outbox Privileges 2430 The following tables specify which scheduling privileges grant the 2431 right to a calendar user to submit a scheduling message to another 2432 calendar user, either as the result of an explicit scheduling request 2433 or an automatic scheduling transaction. The appropriate behavior 2434 depends on the calendar component type in the scheduling message and 2435 the scheduling "METHOD" in use. 2437 +-------------------+ 2438 | METHOD for VEVENT | 2439 +---+---+---+---+---+ 2440 | R | R | A | C | R | 2441 | E | E | D | A | E | 2442 | Q | P | D | N | F | 2443 | U | L | | C | R | 2444 | E | Y | | E | E | 2445 +-----------------------------+| S | | | L | S | 2446 | Scheduling Outbox Privilege || T | | | | H | 2447 +=============================++===+===+===+===+===+ 2448 | schedule-send || * | * | * | * | * | 2449 | schedule-send-invite || * | | * | * | | 2450 | schedule-send-reply || | * | | | * | 2451 | schedule-send-freebusy || | | | | | 2452 +-----------------------------++---+---+---+---+---+ 2454 +-------------------+ 2455 | METHOD for VTODO | 2456 +---+---+---+---+---+ 2457 | R | R | A | C | R | 2458 | E | E | D | A | E | 2459 | Q | P | D | N | F | 2460 | U | L | | C | R | 2461 | E | Y | | E | E | 2462 +-----------------------------+| S | | | L | S | 2463 | Scheduling Outbox Privilege || T | | | | H | 2464 +=============================++===+===+===+===+===+ 2465 | schedule-send || * | * | * | * | * | 2466 | schedule-send-invite || * | | * | * | | 2467 | schedule-send-reply || | * | | | * | 2468 | schedule-send-freebusy || | | | | | 2469 +-----------------------------++---+---+---+---+---+ 2470 +-----------------------+ 2471 | METHOD for VJOURNAL | 2472 +-------+-------+-------+ 2473 | P | A | C | 2474 | U | D | A | 2475 | B | D | N | 2476 | L | | C | 2477 | I | | E | 2478 +-----------------------------+| S | | L | 2479 | Scheduling Outbox Privilege || H | | | 2480 +=============================++=======+=======+=======+ 2481 | schedule-send || * | * | * | 2482 | schedule-send-invite || * | * | * | 2483 | schedule-send-reply || | | | 2484 | schedule-send-freebusy || | | | 2485 +-----------------------------++-------+-------+-------+ 2487 +---------------+ 2488 | METHOD for | 2489 | VFREEBUSY | 2490 +-------+-------+ 2491 | P | R | 2492 | U | E | 2493 | B | Q | 2494 | L | U | 2495 | I | E | 2496 +-----------------------------+| S | S | 2497 | Scheduling Outbox Privilege || H | T | 2498 +=============================++=======+=======+ 2499 | schedule-send || * | * | 2500 | schedule-send-invite || * | | 2501 | schedule-send-reply || | | 2502 | schedule-send-freebusy || | * | 2503 +-----------------------------++-------+-------+ 2505 Appendix B. Changes (to be removed prior to publication as an RFC) 2507 B.1. Changes in -06 2509 a. Removed distinction between scheduling calendar collections and 2510 basic calendar collections - now just have calendar collections. 2512 b. Clients now "MAY" reload data rather than "SHOULD" reload data. 2514 c. Fixed in examples. 2516 d. Removed CALDAV:attachments-allowed pre-condition on POST to 2517 Outbox as that is no longer relevant. 2519 e. Added CALDAV:default-calendar-delete-allowed precondition for 2520 DELETE. 2522 f. Relaxed MUST->MAY for Organizer setting PARTSTAT value. 2524 g. Tweaked restrictions on Create/Modify to emphasize that 4791 2525 restrictions also apply. 2527 h. Added comment that 'opaque' is the default when the CALDAV: 2528 schedule-calendar-transp property is not present. 2530 i. Description of Schedule-Reply header changed to reflect that it 2531 is only relevant for Attendees. 2533 j. Minor typos fixed. 2535 B.2. Changes in -05 2537 This draft has changed substantially since the -04 version. The 2538 primary reason for this change was implementation experience from a 2539 number of vendors who implemented products based on the earlier 2540 drafts. Experience showed that the client/server interaction was not 2541 reliable in keeping scheduling messages synchronized between 2542 organizer and attendees. In addition the latency in updates due to 2543 clients being offline proved unacceptable to users. These issues led 2544 to the redesign of this specification to support a server-based 2545 processing model that eliminates all the problems seen previously. 2546 Whilst this adds significant complexity to the server in that it 2547 needs to be a full blown iTIP processing agent, it does remove a lot 2548 of the same complexity from clients, opening up the possibility of 2549 supporting complex scheduling behaviors even with "thin" clients. 2551 In the judgement of the authors, we consider this new specification 2552 to be a substantial improvement over the old one and believe it 2553 represents a stronger protocol that will lead to better 2554 interoperability. 2556 Authors' Addresses 2558 Cyrus Daboo 2559 Apple Inc. 2560 1 Infinite Loop 2561 Cupertino, CA 95014 2562 USA 2564 EMail: cyrus@daboo.name 2565 URI: http://www.apple.com/ 2567 Bernard Desruisseaux 2568 Oracle Corporation 2569 600 Blvd. de Maisonneuve West 2570 Suite 1900 2571 Montreal, QC H3A 3J2 2572 CANADA 2574 EMail: bernard.desruisseaux@oracle.com 2575 URI: http://www.oracle.com/ 2577 Full Copyright Statement 2579 Copyright (C) The IETF Trust (2008). 2581 This document is subject to the rights, licenses and restrictions 2582 contained in BCP 78, and except as set forth therein, the authors 2583 retain all their rights. 2585 This document and the information contained herein are provided on an 2586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2588 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2589 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2590 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2593 Intellectual Property 2595 The IETF takes no position regarding the validity or scope of any 2596 Intellectual Property Rights or other rights that might be claimed to 2597 pertain to the implementation or use of the technology described in 2598 this document or the extent to which any license under such rights 2599 might or might not be available; nor does it represent that it has 2600 made any independent effort to identify any such rights. Information 2601 on the procedures with respect to rights in RFC documents can be 2602 found in BCP 78 and BCP 79. 2604 Copies of IPR disclosures made to the IETF Secretariat and any 2605 assurances of licenses to be made available, or the result of an 2606 attempt made to obtain a general license or permission for the use of 2607 such proprietary rights by implementers or users of this 2608 specification can be obtained from the IETF on-line IPR repository at 2609 http://www.ietf.org/ipr. 2611 The IETF invites any interested party to bring to its attention any 2612 copyrights, patents or patent applications, or other proprietary 2613 rights that may cover technology that may be required to implement 2614 this standard. Please address the information to the IETF at 2615 ietf-ipr@ietf.org.