idnits 2.17.1 draft-desruisseaux-caldav-sched-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC5546, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4791, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4791, updated by this document, for RFC5378 checks: 2004-06-24) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2, 2012) is 4378 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 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Updates: 4791,5546 (if approved) B. Desruisseaux 5 Intended status: Standards Track Oracle 6 Expires: October 4, 2012 April 2, 2012 8 CalDAV Scheduling Extensions to WebDAV 9 draft-desruisseaux-caldav-sched-12 11 Abstract 13 This document defines extensions to the CalDAV "calendar-access" 14 feature to specify a standard way of performing scheduling operations 15 with iCalendar-based calendar components. This document defines the 16 "calendar-auto-schedule" feature of CalDAV. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 4, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 66 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 7 67 1.3. XML Namespaces and Processing . . . . . . . . . . . . . . 8 68 2. Scheduling Support . . . . . . . . . . . . . . . . . . . . . . 9 69 2.1. Scheduling Outbox Collection . . . . . . . . . . . . . . . 9 70 2.1.1. CALDAV:schedule-outbox-URL Property . . . . . . . . . 10 71 2.2. Scheduling Inbox Collection . . . . . . . . . . . . . . . 10 72 2.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 12 73 2.3. Calendaring Reports Extensions . . . . . . . . . . . . . . 12 74 2.4. Additional Principal Properties . . . . . . . . . . . . . 13 75 2.4.1. CALDAV:calendar-user-address-set Property . . . . . . 13 76 2.4.2. CALDAV:calendar-user-type Property . . . . . . . . . . 14 77 3. Scheduling Operations . . . . . . . . . . . . . . . . . . . . 15 78 3.1. Identifying Scheduling Object Resources . . . . . . . . . 15 79 3.2. Handling Scheduling Object Resources . . . . . . . . . . . 15 80 3.2.1. Organizer Scheduling Object Resources . . . . . . . . 15 81 3.2.1.1. Create . . . . . . . . . . . . . . . . . . . . . . 16 82 3.2.1.2. Modify . . . . . . . . . . . . . . . . . . . . . . 17 83 3.2.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . 18 84 3.2.2. Attendee Scheduling Object Resources . . . . . . . . . 18 85 3.2.2.1. Allowed Attendee Changes . . . . . . . . . . . . . 18 86 3.2.2.2. Create . . . . . . . . . . . . . . . . . . . . . . 19 87 3.2.2.3. Modify . . . . . . . . . . . . . . . . . . . . . . 20 88 3.2.2.4. Remove . . . . . . . . . . . . . . . . . . . . . . 21 89 3.2.3. HTTP Methods . . . . . . . . . . . . . . . . . . . . . 21 90 3.2.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 22 91 3.2.3.2. DELETE . . . . . . . . . . . . . . . . . . . . . . 22 92 3.2.3.3. COPY . . . . . . . . . . . . . . . . . . . . . . . 22 93 3.2.3.4. MOVE . . . . . . . . . . . . . . . . . . . . . . . 23 94 3.2.4. Additional Method Preconditions . . . . . . . . . . . 24 95 3.2.4.1. CALDAV:unique-scheduling-object-resource 96 Precondition . . . . . . . . . . . . . . . . . . . 24 97 3.2.4.2. CALDAV:same-organizer-in-all-components 98 Precondition . . . . . . . . . . . . . . . . . . . 24 99 3.2.4.3. CALDAV:allowed-organizer-scheduling-object-chan 100 Precondition . . . . . . . . . . . . . . . . . . . 25 101 3.2.4.4. CALDAV:allowed-attendee-scheduling-object-chang 102 Precondition . . . . . . . . . . . . . . . . . . . 25 103 3.2.5. DTSTAMP and SEQUENCE Properties . . . . . . . . . . . 26 104 3.2.6. Restrict Recurrence Instances Sent to Attendees . . . 26 105 3.2.7. Forcing the Server to Send a Scheduling Message . . . 26 106 3.2.8. Attendee Participation Status . . . . . . . . . . . . 27 107 3.2.9. Schedule Status Values . . . . . . . . . . . . . . . . 28 108 3.2.10. Avoiding Conflicts when Updating Scheduling Object 109 Resources . . . . . . . . . . . . . . . . . . . . . . 31 110 3.2.10.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 33 111 3.2.10.2. DELETE, COPY or MOVE . . . . . . . . . . . . . . . 33 112 4. Processing Incoming Scheduling Messages . . . . . . . . . . . 34 113 4.1. Processing Organizer Requests, Additions, and 114 Cancellations . . . . . . . . . . . . . . . . . . . . . . 34 115 4.2. Processing Attendee Replies . . . . . . . . . . . . . . . 35 116 4.3. Default Calendar Collection . . . . . . . . . . . . . . . 35 117 4.3.1. Additional Method Preconditions . . . . . . . . . . . 36 118 4.3.1.1. CALDAV:default-calendar-needed Precondition . . . 36 119 4.3.1.2. CALDAV:valid-schedule-default-calendar-URL 120 Precondition . . . . . . . . . . . . . . . . . . . 36 121 5. Request for Busy Time Information . . . . . . . . . . . . . . 38 122 5.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 38 123 5.2. Additional Method Preconditions . . . . . . . . . . . . . 39 124 5.2.1. CALDAV:valid-scheduling-message Precondition . . . . . 39 125 5.2.2. CALDAV:valid-organizer Precondition . . . . . . . . . 39 126 6. Scheduling Privileges . . . . . . . . . . . . . . . . . . . . 41 127 6.1. Privileges on Scheduling Inbox Collections . . . . . . . . 41 128 6.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . . . 41 129 6.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . . . 41 130 6.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . . . 42 131 6.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . . . 42 132 6.2. Privileges on Scheduling Outbox Collections . . . . . . . 42 133 6.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . . . 42 134 6.2.2. CALDAV:schedule-send-invite Privilege . . . . . . . . 42 135 6.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . . . 43 136 6.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . . . 43 137 6.3. Aggregation of Scheduling Privileges . . . . . . . . . . . 43 138 7. Additional iCalendar Property Parameters . . . . . . . . . . . 45 139 7.1. Schedule Agent Parameter . . . . . . . . . . . . . . . . . 45 140 7.2. Schedule Force Send Parameter . . . . . . . . . . . . . . 46 141 7.3. Schedule Status Parameter . . . . . . . . . . . . . . . . 47 142 8. Additional Message Header Fields . . . . . . . . . . . . . . . 49 143 8.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 49 144 8.2. Schedule-Tag Response Header . . . . . . . . . . . . . . . 49 145 8.3. If-Schedule-Tag-Match Request Header . . . . . . . . . . . 50 147 9. Additional WebDAV Properties . . . . . . . . . . . . . . . . . 51 148 9.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 51 149 9.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 52 150 9.3. CALDAV:schedule-tag Property . . . . . . . . . . . . . . . 53 151 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 54 152 10.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 54 153 10.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 54 154 10.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 54 155 10.4. CALDAV:request-status XML Element . . . . . . . . . . . . 55 156 11. Security Considerations . . . . . . . . . . . . . . . . . . . 56 157 11.1. Preventing Denial of Service Attacks . . . . . . . . . . . 56 158 11.2. Verifying Scheduling Operations . . . . . . . . . . . . . 56 159 11.3. Verifying Busy Time Information Requests . . . . . . . . . 57 160 11.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 57 161 11.5. Mitigation of iTIP Threats . . . . . . . . . . . . . . . . 58 162 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 163 12.1. Message Header Field Registrations . . . . . . . . . . . . 59 164 12.1.1. Schedule-Reply . . . . . . . . . . . . . . . . . . . . 59 165 12.1.2. Schedule-Tag . . . . . . . . . . . . . . . . . . . . . 59 166 12.1.3. If-Schedule-Tag-Match . . . . . . . . . . . . . . . . 59 167 12.2. iCalendar Property Parameter Registrations . . . . . . . . 60 168 12.3. iCalendar REQUEST-STATUS Value Registrations . . . . . . . 60 169 12.4. Additional iCalendar Elements Registries . . . . . . . . . 60 170 12.4.1. Schedule Agent Values Registry . . . . . . . . . . . . 60 171 12.4.2. Schedule Force Send Values Registry . . . . . . . . . 61 172 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 173 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 174 14.1. Normative References . . . . . . . . . . . . . . . . . . . 63 175 14.2. Informative References . . . . . . . . . . . . . . . . . . 64 176 Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 65 177 A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 65 178 A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 65 179 Appendix B. Example Scheduling Operations . . . . . . . . . . . . 67 180 B.1. Example: Organizer Inviting Multiple Attendees . . . . . . 67 181 B.2. Example: Attendee Receiving an Invitation . . . . . . . . 69 182 B.3. Example: Attendee Replying to an Invitation . . . . . . . 71 183 B.4. Example: Organizer Receiving a Reply to an Invitation . . 74 184 B.5. Example: Organizer Requesting Busy Time Information . . . 76 185 B.6. Example: User Attempting to Invite Attendee on behalf 186 of Organizer . . . . . . . . . . . . . . . . . . . . . . . 78 187 B.7. Example: Attendee Declining an Instance of a Recurring 188 Event . . . . . . . . . . . . . . . . . . . . . . . . . . 80 189 B.8. Example: Attendee Removing an Instance of a Recurring 190 Event . . . . . . . . . . . . . . . . . . . . . . . . . . 83 191 Appendix C. Changes (to be removed by RFC Editor prior to 192 publication) . . . . . . . . . . . . . . . . . . . . 86 193 C.1. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 86 194 C.2. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 86 195 C.3. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 86 196 C.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 87 197 C.5. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 88 198 C.6. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 88 199 C.7. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 89 200 C.8. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 90 202 1. Introduction 204 This document specifies extensions to the CalDAV "calendar-access" 205 [RFC4791] feature to enable scheduling of iCalendar-based [RFC5545] 206 calendar components between calendar users. 208 This extension leverages the scheduling methods defined in the 209 iCalendar Transport-independent Interoperability Protocol (iTIP) 210 [RFC5546] to permit calendar users to perform scheduling operations 211 such as schedule, reschedule, respond to scheduling request or cancel 212 calendar components, as well as search for busy time information. 213 However, the following iTIP [RFC5546] features are not covered: 214 publishing, countering, delegating, refreshing and forwarding 215 calendar components, as well as replacing the Organizer of a calendar 216 component. It is expected that future extensions will be developed 217 to address these. 219 This specification defines a client/server scheduling protocol, where 220 the server is made responsible for sending scheduling messages and 221 processing incoming scheduling messages. The client operations of 222 creating, modifying or deleting a calendar component in a calendar is 223 enough to trigger the server to deliver the necessary scheduling 224 messages to the appropriate calendar users. This approach is 225 sometimes referred to as "implicit scheduling". 227 This specification only addresses how scheduling occurs with users on 228 a single system (i.e., scheduling between CalDAV servers, or some 229 other calendaring and scheduling system, is not defined). However, 230 this specification is compatible with servers being able to send or 231 receive scheduling messages with "external" users (e.g., using the 232 iCalendar Message-Based Interoperability Protocol iMIP [RFC6047]). 234 Section 3 defines the automated "Scheduling Operations", that allow a 235 client to store iCalendar data on a CalDAV server, with the server 236 taking specific actions in response. One of three scheduling 237 operations can take place: "create", "modify" or "remove", based on 238 the HTTP method used for the request, and a comparison between any 239 existing and any new iCalendar data. 241 Section 4 defines how the server processes scheduling messages sent 242 as the result of a scheduling operation. 244 Section 5 defines how freebusy requests with an immediate response 245 are accomplished. 247 Section 6 defines access control privileges for the scheduling 248 operations defined in this specification. 250 For the majority of the following discussion, scheduling of events 251 will be discussed. However, scheduling of to-dos is also fully 252 supported by this specification. 254 Discussion of this Internet-Draft is taking place on the mailing 255 lists at and 256 . 258 1.1. Terminology 260 This specification reuses much of the same terminology as iCalendar 261 [RFC5545], iTIP [RFC5546], WebDAV [RFC4918], and CalDAV [RFC4791]. 262 Additional terms used by this specification are: 264 Scheduling object resource: A calendar object resource contained in 265 a calendar collection for which the server will take care of 266 sending scheduling messages on behalf of the owner of the calendar 267 collection. 269 Organizer scheduling object resource: A scheduling object resource 270 owned by the Organizer. 272 Attendee scheduling object resource: A scheduling object resource 273 owned by an Attendee. 275 Scheduling operation: Add, change or remove operations on a 276 scheduling object resource for which the server will deliver 277 scheduling messages to other calendar users. 279 Scheduling message: A calendar object that describes a scheduling 280 operation such as schedule, reschedule, reply, or cancel. 282 Scheduling Outbox collection: A resource at which busy time 283 information requests are targeted. 285 Scheduling Inbox collection: A collection in which incoming 286 scheduling messages are delivered. 288 1.2. Notational Conventions 290 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 291 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 292 document are to be interpreted as described in [RFC2119]. 294 The Augmented BNF (ABNF) syntax used by this document to specify the 295 format definition of new iCalendar elements is defined in [RFC5234]. 297 The Augmented BNF (ABNF) syntax used by this document to specify the 298 format definition of new message header fields to be used with the 299 HTTP/1.1 protocol is described in Section 2.1 of [RFC2616]. Since 300 this Augmented BNF uses the basic production rules provided in 301 Section 2.2 of [RFC2616], these rules apply to this document as well. 303 The term "protected" is used in the Conformance field of WebDAV 304 property definitions as defined in Section 15 of [RFC4918]. 306 1.3. XML Namespaces and Processing 308 This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section 309 3.2) as a purely notational convention. WebDAV request and response 310 bodies cannot be validated by a DTD due to the specific extensibility 311 rules defined in Section 17 of [RFC4918] and due to the fact that all 312 XML elements defined by that specification use the XML namespace name 313 "DAV:". In particular: 315 1. element names use the "DAV:" namespace, 317 2. element ordering is irrelevant unless explicitly stated, 319 3. extension elements (elements not already defined as valid child 320 elements) can be added anywhere, except when explicitly stated 321 otherwise, 323 4. extension attributes (attributes not already defined as valid for 324 this element) can be added anywhere, except when explicitly 325 stated otherwise. 327 The XML elements specified in this document are defined in the 328 "urn:ietf:params:xml:ns:caldav" XML namespace registered by CalDAV 329 [RFC4791]. 331 When XML element types in the namespaces "DAV:" and 332 "urn:ietf:params:xml:ns:caldav" are referenced in this document 333 outside of the context of an XML fragment, the strings "DAV:" and 334 "CALDAV:" will be prefixed to the element types, respectively. 336 This document inherits, and sometimes extends, DTD productions from 337 Section 14 of [RFC4918]. 339 Also note that some CalDAV XML element names are identical to WebDAV 340 XML element names, though their namespace differs. Care needs to be 341 taken not to confuse the two sets of names. 343 2. Scheduling Support 345 A server that supports the features described in this document is 346 REQUIRED to support the CalDAV "calendar-access" [RFC4791] feature. 347 Servers include "calendar-auto-schedule" as a field in the DAV 348 response header from an OPTIONS request on any resource that supports 349 any scheduling operations, properties, privileges or methods. 351 This specification introduces new collection resource types that are 352 used to manage scheduling object resources, and scheduling privileges 353 (as per Section 6), as well as provide scheduling functionality. It 354 is the server's responsibility to create these collection resources, 355 and clients have no way to create or delete them. 357 2.1. Scheduling Outbox Collection 359 A scheduling Outbox collection is used as the target for busy time 360 information requests, and to manage privileges that apply to outgoing 361 scheduling requests. 363 A scheduling Outbox collection MUST report the DAV:collection and 364 CALDAV:schedule-outbox XML elements in the value of the DAV: 365 resourcetype property. The element type declaration for CALDAV: 366 schedule-outbox is: 368 370 Example: 372 373 374 375 377 A scheduling Outbox collection MUST NOT be a child (at any depth) of 378 a calendar collection resource. 380 The following WebDAV properties specified in CalDAV "calendar-access" 381 [RFC4791] MAY also be defined on scheduling Outbox collections and 382 apply to scheduling messages submitted to the scheduling Outbox 383 collection with the POST method: 385 o CALDAV:supported-calendar-component-set 387 o CALDAV:supported-calendar-data 389 o CALDAV:max-resource-size 390 o CALDAV:min-date-time 392 o CALDAV:max-date-time 394 o CALDAV:max-attendees-per-instance 396 The use of child resources in a scheduling Outbox collection is 397 reserved for future revisions or extensions of this specification. 399 The following WebDAV property is defined on principal resources and 400 used to locate the corresponding Outbox collection for the associated 401 principal. 403 2.1.1. CALDAV:schedule-outbox-URL Property 405 Name: schedule-outbox-URL 407 Namespace: urn:ietf:params:xml:ns:caldav 409 Purpose: Identify the URL of the scheduling Outbox collection owned 410 by the associated principal resource. 412 Protected: This property MAY be protected. 414 PROPFIND behavior: This property SHOULD NOT be returned by a 415 PROPFIND allprop request (as defined in Section 14.2 of 416 [RFC4918]). 418 COPY/MOVE behavior: This property value SHOULD be preserved in COPY 419 and MOVE operations. 421 Description: This property is needed for a client to determine where 422 the scheduling Outbox collection of the current user is located so 423 that sending of scheduling messages can occur. If not present, 424 then the associated calendar user is not enabled for the sending 425 of scheduling messages on the server. 427 Definition: 429 431 2.2. Scheduling Inbox Collection 433 A scheduling Inbox collection contains copies of incoming scheduling 434 messages. These can be requests sent by an Organizer, or replies 435 sent by an Attendee in response to a request. The scheduling Inbox 436 collection is also used to manage scheduling privileges. 438 A scheduling Inbox collection MUST report the DAV:collection and 439 CALDAV:schedule-inbox XML elements in the value of the DAV: 440 resourcetype property. The element type declaration for CALDAV: 441 schedule-inbox is: 443 445 Example: 447 448 449 450 452 Scheduling Inbox collections MUST only contain calendar object 453 resources that obey the restrictions specified in iTIP [RFC5546]. 454 Consequently, scheduling Inbox collections MUST NOT contain any types 455 of collection resources. Restrictions defined in Section 4.1 of 456 CalDAV "calendar-access" [RFC4791] on calendar object resources 457 contained in calendar collections (e.g., "UID" uniqueness) do not 458 apply to calendar object resources contained in a scheduling Inbox 459 collection. Thus, multiple calendar object resources contained in a 460 scheduling Inbox collection can have the same "UID" property value 461 (i.e., multiple scheduling messages for the same calendar component). 463 A scheduling Inbox collection MUST NOT be a child (at any depth) of a 464 calendar collection resource. 466 The following WebDAV properties specified in CalDAV "calendar-access" 467 [RFC4791] MAY also be defined on scheduling Inbox collections and 468 apply to scheduling messages delivered to the collection: 470 o CALDAV:supported-calendar-component-set 472 o CALDAV:supported-calendar-data 474 o CALDAV:max-resource-size 476 o CALDAV:min-date-time 478 o CALDAV:max-date-time 480 o CALDAV:max-instances 482 o CALDAV:max-attendees-per-instance 484 o CALDAV:calendar-timezone 485 The following WebDAV property is defined on principal resources and 486 used to locate the corresponding Inbox collection for the associated 487 principal. 489 2.2.1. CALDAV:schedule-inbox-URL Property 491 Name: schedule-inbox-URL 493 Namespace: urn:ietf:params:xml:ns:caldav 495 Purpose: Identify the URL of the scheduling Inbox collection owned 496 by the associated principal resource. 498 Protected: This property MAY be protected. 500 PROPFIND behavior: This property SHOULD NOT be returned by a 501 PROPFIND allprop request (as defined in Section 14.2 of 502 [RFC4918]). 504 COPY/MOVE behavior: This property value SHOULD be preserved in COPY 505 and MOVE operations. 507 Description: This property allows a client to determine where the 508 scheduling Inbox collection of the current user is located so that 509 processing of scheduling messages can occur. If not present, then 510 the associated calendar user is not enabled for reception of 511 scheduling messages on the server. 513 Definition: 515 517 2.3. Calendaring Reports Extensions 519 This specification extends the CALDAV:calendar-query and CALDAV: 520 calendar-multiget REPORTs to return results for calendar object 521 resources in scheduling Inbox collections. 523 When a CALDAV:calendar-query REPORT includes a time-range query and 524 targets a scheduling Inbox collection, if any calendar object 525 resources contain "VEVENT" calendar components that do not include a 526 "DTSTART" iCalendar property (as allowed by iTIP [RFC5546]) then such 527 components MUST always match the time-range query test. 529 Note that the CALDAV:free-busy-query REPORT is not supported on 530 scheduling Inbox collections. 532 2.4. Additional Principal Properties 534 This section defines new properties for WebDAV principal resources as 535 defined in [RFC3744]. These properties are likely to be protected 536 but the server MAY allow them to be written by appropriate users. 538 2.4.1. CALDAV:calendar-user-address-set Property 540 Name: calendar-user-address-set 542 Namespace: urn:ietf:params:xml:ns:caldav 544 Purpose: Identify the calendar addresses of the associated principal 545 resource. 547 Protected: This property MAY be protected. 549 PROPFIND behavior: This property SHOULD NOT be returned by a 550 PROPFIND allprop request (as defined in Section 14.2 of 551 [RFC4918]). 553 COPY/MOVE behavior: This property value SHOULD be preserved in COPY 554 and MOVE operations. 556 Description: Support for this property is REQUIRED. This property 557 is needed to map calendar user addresses in iCalendar data to 558 principal resources and their associated scheduling Inbox and 559 Outbox collections. In the event that a user has no well defined 560 identifier for their calendar user address, the URI of their 561 principal resource can be used. This property SHOULD be 562 searchable using the DAV:principal-property-search REPORT. The 563 DAV:principal-search-property-set REPORT SHOULD identify this 564 property as such. If not present, then the associated calendar 565 user is not enabled for scheduling on the server. 567 Definition: 569 571 Example: 573 575 mailto:bernard@example.com 576 mailto:bernard.desruisseaux@example.com 577 579 2.4.2. CALDAV:calendar-user-type Property 581 Name: calendar-user-type 583 Namespace: urn:ietf:params:xml:ns:caldav 585 Purpose: Identifies the calendar user type of the associated 586 principal resource. 588 Value: Same values allowed for the iCalendar "CUTYPE" property 589 parameter defined in Section 3.2.3 of [RFC5545]. 591 Protected: This property MAY be protected. 593 PROPFIND behavior: This property SHOULD NOT be returned by a 594 PROPFIND allprop request (as defined in Section 14.2 of 595 [RFC4918]). 597 COPY/MOVE behavior: This property value SHOULD be preserved in COPY 598 and MOVE operations. 600 Description: Clients can query principal resources in order to 601 lookup attendees available on the server. When doing this, it is 602 useful to know, or restrict the query to, certain types of 603 calendar user (e.g., only search for "people", or only search for 604 "rooms"). This property MAY be defined on principal resources to 605 indicate the type of calendar user associated with the principal 606 resource. Its value is the same as the iCalendar "CUTYPE" 607 property parameter that can be used on "ATTENDEE" properties. 608 This property SHOULD be searchable using the DAV:principal- 609 property-search REPORT. The DAV:principal-search-property-set 610 REPORT SHOULD identify this property as such. 612 Definition: 614 616 Example: 618 INDIVIDUAL< 620 /C:calendar-user-type> 622 3. Scheduling Operations 624 When a calendar object resource is created, modified or removed from 625 a calendar collection, the server examines the calendar data and 626 checks to see whether the data represents a scheduling object 627 resource. If it does, the server will automatically attempt to 628 deliver a scheduling message to the appropriate calendar users. 629 Several types of scheduling operations can occur in this case, 630 equivalent to iTIP "REQUEST", "REPLY", "CANCEL", and "ADD" 631 operations. 633 3.1. Identifying Scheduling Object Resources 635 Calendar object resources on which the server performs scheduling 636 operations are referred to as scheduling object resources. There are 637 two types of scheduling object resources: organizer scheduling object 638 resources, and attendee scheduling object resources. 640 A calendar object resource is considered to be a valid organizer 641 scheduling object resource if the "ORGANIZER" iCalendar property is 642 present and set in all the calendar components to a value that 643 matches one of the calendar user addresses of the owner of the 644 calendar collection. 646 A calendar object resource is considered to be a valid attendee 647 scheduling object resource if the "ORGANIZER" iCalendar property is 648 present and set in all the calendar components to the same value and 649 doesn't match one of the calendar user addresses of the owner of the 650 calendar collection, and at least one of the "ATTENDEE" iCalendar 651 property values matches one of the calendar user addresses of the 652 owner of the calendar collection. 654 The creation of attendee scheduling object resources is typically 655 done by the server, with the resource being created in an appropriate 656 calendar collection (see Section 4.3). 658 3.2. Handling Scheduling Object Resources 660 The server's behavior when processing a scheduling object resource 661 depends on whether it is owned by the Organizer or an Attendee 662 specified in the calendar data. 664 3.2.1. Organizer Scheduling Object Resources 666 An Organizer can create, modify or remove a scheduling object 667 resource, subject to access privileges, pre-conditions, and the 668 restrictions defined in Section 4.1 of [RFC4791]. These operations 669 are each described next, and how they are invoked via HTTP requests 670 is described in Section 3.2.3. 672 The Organizer of a calendar component can also be an Attendee of that 673 calendar component. In such cases the server MUST NOT send a 674 scheduling message to the Attendee that matches the Organizer. 676 The server SHOULD reject any attempt to set the "PARTSTAT" iCalendar 677 property parameter value of the "ATTENDEE" iCalendar property of 678 other users in the calendar object resource to a value other than 679 "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value is 680 not present or set to the value "SERVER". 682 The server MAY reject attempts to create a scheduling object resource 683 that specifies a "UID" property value already specified in a 684 scheduling object resource contained in another calendar collection 685 of the Organizer. 687 3.2.1.1. Create 689 When an Organizer creates a scheduling object resource, the server 690 MUST inspect each "ATTENDEE" property to determine whether to send a 691 scheduling message. The table below indicates the appropriate iTIP 692 method used by the server, taking into account any "SCHEDULE-AGENT" 693 property parameter (see Section 7.1) specified on each "ATTENDEE" 694 property. 696 +------------------+-------------+ 697 | SCHEDULE-AGENT | iTIP METHOD | 698 +------------------+-------------+ 699 | SERVER (default) | REQUEST | 700 | | | 701 | CLIENT | -- | 702 | | | 703 | NONE | -- | 704 +------------------+-------------+ 706 "SCHEDULE-STATUS" iCalendar property parameters are added or changed 707 on "ATTENDEE" iCalendar properties in the scheduling object resource 708 being created as described in Section 7.3, with the value set as 709 described in Section 3.2.9. This will result in the created calendar 710 object resource differing from the calendar data sent in the HTTP 711 request. As a result clients MAY reload the calendar data from the 712 server in order to update to the new server generated state 713 information. 715 The server MUST add a "SCHEDULE-STATUS" iCalendar property parameter 716 (see Section 7.3) to the "ATTENDEE" iCalendar property in the 717 scheduling object resource being created, and set its value as 718 described in Section 3.2.9. This will result in the created calendar 719 object resource differing from the calendar data sent in the HTTP 720 request. As a result clients MAY reload the calendar data from the 721 server in order to update to the new server generated state 722 information. Servers MUST NOT set the "SCHEDULE-STATUS" property 723 parameter on the "ATTENDEE" property of Attendees for which it did 724 not attempt to deliver a scheduling message. 726 The server MUST return an error with the CALDAV:allowed-organizer- 727 scheduling-object-change precondition code (Section 3.2.4.3) when the 728 Organizer attempts to change the iCalendar data in a manner that is 729 forbidden. 731 3.2.1.2. Modify 733 When an Organizer modifies a scheduling object resource, the server 734 MUST inspect each "ATTENDEE" property in both the original and 735 modified iCalendar data on a per-instance basis to determine whether 736 to send a scheduling message. The table below indicates the 737 appropriate iTIP method used by the server, taking into account any 738 "SCHEDULE-AGENT" property parameter (see Section 7.1) specified on 739 each "ATTENDEE" property. The values "SERVER", "CLIENT", and "NONE" 740 in the top and left titles of the table refer to the "SCHEDULE-AGENT" 741 parameter value of the "ATTENDEE" property, and the values "" 742 and "" are used to cover the cases where the "ATTENDEE" 743 property is not present (Original) or is being removed (Modified). 745 +---------------+-----------------------------------------------+ 746 | | Modified | 747 | +-----------+-----------+-----------+-----------+ 748 | | | SERVER | CLIENT | NONE | 749 | | | (default) | | | 750 +===+===========+===========+===========+===========+===========+ 751 | | | -- | REQUEST / | -- | -- | 752 | O | | | ADD | | | 753 | r +-----------+-----------+-----------+-----------+-----------+ 754 | i | SERVER | CANCEL | REQUEST | CANCEL | CANCEL | 755 | g | (default) | | | | | 756 | i +-----------+-----------+-----------+-----------+-----------+ 757 | n | CLIENT | -- | REQUEST / | -- | -- | 758 | a | | | ADD | | | 759 | l +-----------+-----------+-----------+-----------+-----------+ 760 | | NONE | -- | REQUEST / | -- | -- | 761 | | | | ADD | | | 762 +---+-----------+-----------+-----------+-----------+-----------+ 764 "SCHEDULE-STATUS" iCalendar property parameters are added or changed 765 on "ATTENDEE" iCalendar properties in the scheduling object resource 766 being modified as described in Section 7.3, with the value set as 767 described in Section 3.2.9. This will result in the created calendar 768 object resource differing from the calendar data sent in the HTTP 769 request. As a result clients MAY reload the calendar data from the 770 server in order to update to the new server generated state 771 information. 773 The server MUST return an error with the CALDAV:allowed-organizer- 774 scheduling-object-change precondition code (Section 3.2.4.3) when the 775 Organizer attempts to change the iCalendar data in a manner that is 776 forbidden. 778 3.2.1.3. Remove 780 When an Organizer removes a scheduling object resource, the server 781 MUST inspect each "ATTENDEE" property to determine whether to send a 782 scheduling message. The table below indicates the appropriate iTIP 783 method used by the server, taking into account any "SCHEDULE-AGENT" 784 property parameter (see Section 7.1) specified on each "ATTENDEE" 785 property. 787 +------------------+-------------+ 788 | SCHEDULE-AGENT | iTIP METHOD | 789 +------------------+-------------+ 790 | SERVER (default) | CANCEL | 791 | | | 792 | CLIENT | -- | 793 | | | 794 | NONE | -- | 795 +------------------+-------------+ 797 3.2.2. Attendee Scheduling Object Resources 799 An Attendee can create, modify or remove a scheduling object 800 resource. These operations are each described next, and how they are 801 invoked via HTTP requests is described in Section 3.2.3. 803 3.2.2.1. Allowed Attendee Changes 805 Attendees are allowed to make some changes to a scheduling object 806 resource, though key properties such as start time, end time, 807 location, and summary are typically under the control of the 808 Organizer. 810 Servers MUST allow Attendees to make the following iCalendar data 811 changes, subject to other restrictions, such as access privileges and 812 pre-conditions: 814 1. change their own "PARTSTAT" iCalendar property parameter value. 816 2. add, modify or remove any "TRANSP" iCalendar properties. 818 3. add, modify or remove any "PERCENT-COMPLETE" iCalendar 819 properties. 821 4. add, modify or remove any "COMPLETED" iCalendar properties. 823 5. add, modify or remove any "VALARM" iCalendar components. 825 6. add, modify or remove the "CALSCALE" iCalendar property within 826 the top-level "VCALENDAR" component. 828 7. modify the "PRODID" iCalendar property within the top-level 829 "VCALENDAR" component. 831 8. add "EXDATE" iCalendar properties and possibly remove components 832 for overridden recurrence instances. 834 9. add, modify or remove any "CREATED", "DTSTAMP" and "LAST- 835 MODIFIED" iCalendar properties. 837 10. add, modify or remove "SCHEDULE-STATUS" iCalendar property 838 parameters on "ATTENDEE" properties that have a "SCHEDULE-AGENT" 839 parameter set to "CLIENT". 841 11. add new components to represent overridden recurrence instances, 842 provided the only changes to the recurrence instance follow the 843 rules above. 845 The server MUST return an error with the CALDAV:allowed-attendee- 846 scheduling-object-change precondition code (Section 3.2.4.4) when the 847 Attendee attempts to change the iCalendar data in a manner forbidden 848 by the server. 850 3.2.2.2. Create 852 Typically an Attendee does not create scheduling object resources, as 853 scheduling messages delivered to them on the server are automatically 854 processed by the server and placed on one of their calendars (see 855 Section 4). However, in some cases a scheduling message can get 856 delivered directly to the client (e.g., via email [RFC6047]), and the 857 Attendee might wish to store that on the server. In that case the 858 client creates a scheduling object resource in a calendar belonging 859 to the Attendee. It can then set the "SCHEDULE-AGENT" iCalendar 860 property parameter on all "ORGANIZER" iCalendar properties in the 861 resource to determine how the server treats the resource. The value 862 of the "SCHEDULE-AGENT" iCalendar property parameter on all 863 "ORGANIZER" iCalendar properties MUST be the same. 865 +----------------+--------------------------------------------------+ 866 | SCHEDULE-AGENT | Action | 867 +----------------+--------------------------------------------------+ 868 | SERVER | The server will attempt to process changes to | 869 | (default) | the resource using the normal rules for attendee | 870 | | scheduling object resources. | 871 | | | 872 | CLIENT | The server does no special processing of the | 873 | | resource. The client is assumed to be handling | 874 | | Attendee replies etc. | 875 | | | 876 | NONE | The server does no special processing of the | 877 | | resource. | 878 +----------------+--------------------------------------------------+ 880 "SCHEDULE-STATUS" iCalendar property parameters are added or changed 881 on "ORGANIZER" iCalendar properties in the scheduling object resource 882 being created as described in Section 7.3, with the value set as 883 described in Section 3.2.9. 885 3.2.2.3. Modify 887 When a scheduling object resource is modified by an Attendee, the 888 server behavior depends on the value of the "SCHEDULE-AGENT" 889 iCalendar property parameter on the "ORGANIZER" iCalendar properties: 891 +----------------+--------------------------------------------------+ 892 | SCHEDULE-AGENT | Action | 893 +----------------+--------------------------------------------------+ 894 | SERVER | The server will attempt to process the update | 895 | (default) | using the behavior listed below. | 896 | | | 897 | CLIENT | The server does no special processing of the | 898 | | resource. The client is assumed to be handling | 899 | | any Attendee replies etc. | 900 | | | 901 | NONE | The server does no special processing of the | 902 | | resource. | 903 +----------------+--------------------------------------------------+ 905 The server will inspect the changes by comparing the new scheduling 906 object resource with the existing scheduling object resource. 908 If the Attendee changes one or more "PARTSTAT" iCalendar property 909 values on any component, or adds an overridden component with a 910 changed "PARTSTAT" property, then the server MUST deliver an iTIP 911 "REPLY" scheduling message to the Organizer to indicate the new 912 participation status of the Attendee. 914 If the Attendee adds an "EXDATE" property value to effectively remove 915 a recurrence instance, the server MUST deliver an iTIP "REPLY" 916 scheduling message to the Organizer to indicate that the Attendee has 917 declined the instance. 919 "SCHEDULE-STATUS" iCalendar property parameters are added or changed 920 on "ORGANIZER" iCalendar properties in the scheduling object resource 921 being modified as described in Section 7.3, with the value set as 922 described in Section 3.2.9. This will result in the updated calendar 923 object resource differing from the calendar data sent in the HTTP 924 request. As a result clients MAY reload the calendar data from the 925 server in order to update to the new server generated state 926 information. 928 3.2.2.4. Remove 930 When a scheduling object resource is removed by an Attendee, the 931 server behavior depends on the value of the "SCHEDULE-AGENT" 932 iCalendar property parameter on the "ORGANIZER" iCalendar properties: 934 +----------------+--------------------------------------------------+ 935 | SCHEDULE-AGENT | Action | 936 +----------------+--------------------------------------------------+ 937 | SERVER | The server will attempt to process the removal | 938 | (default) | taking into account any "Schedule-Reply" request | 939 | | header as per Section 8.1. | 940 | | | 941 | CLIENT | The server does no special processing of the | 942 | | resource. The client is assumed to be handling | 943 | | any Attendee replies etc. | 944 | | | 945 | NONE | The server does no special processing of the | 946 | | resource. | 947 +----------------+--------------------------------------------------+ 949 3.2.3. HTTP Methods 951 This section describes how use of various HTTP [RFC2616] and WebDAV 952 [RFC4918] methods on a scheduling object resource will cause a 953 create, modify or remove operation on that resource as described 954 above. The use of these methods is subject to the restrictions in 955 [RFC4791], in addition to what is described below. 957 3.2.3.1. PUT 959 When the server receives a PUT method request it MUST execute the 960 following operations, provided all appropriate preconditions are met: 962 +------------------------+--------------------------+---------------+ 963 | Existing Destination | Resulting Destination | Server | 964 | Resource | Resource | Operation | 965 +------------------------+--------------------------+---------------+ 966 | None | Calendar object resource | None | 967 | | | | 968 | None | Scheduling object | Create | 969 | | resource | | 970 | | | | 971 | Calendar object | Calendar object resource | None | 972 | resource | | | 973 | | | | 974 | Calendar object | Scheduling object | Create | 975 | resource | resource | | 976 | | | | 977 | Scheduling object | Calendar object resource | Remove | 978 | resource | | | 979 | | | | 980 | Scheduling object | Scheduling object | Modify | 981 | resource | resource | | 982 +------------------------+--------------------------+---------------+ 984 3.2.3.2. DELETE 986 When the server receives a DELETE method request targeted at a 987 scheduling object resource it MUST execute the Remove operation. 989 When the server receives a DELETE method request targeted at a 990 calendar collection it MUST execute the Remove operation on all 991 scheduling object resources contained in the calendar collection. 993 3.2.3.3. COPY 995 When the server receives a COPY method request it MUST execute the 996 following operations based on the source and destination collections 997 in the request: 999 +-----------------------+------------------------+------------------+ 1000 | Source Collection | Destination Collection | Server Operation | 1001 +-----------------------+------------------------+------------------+ 1002 | Non-calendar | Non-calendar | None | 1003 | collection | collection | | 1004 | | | | 1005 | Non-calendar | Calendar collection | (1) | 1006 | collection | | | 1007 | | | | 1008 | Calendar collection | Non-calendar | None | 1009 | | collection | | 1010 | | | | 1011 | Calendar collection | Calendar collection | (2) | 1012 +-----------------------+------------------------+------------------+ 1014 Note 1. The rules in Section 3.2.3.1 are applied for the destination 1015 of the COPY request. 1017 Note 2. The server MAY reject this as per Section 3.2.4.1, otherwise 1018 None. 1020 The behavior of a COPY method request on a calendar collection is 1021 undefined. 1023 3.2.3.4. MOVE 1025 When the server receives a MOVE method request it MUST execute the 1026 following operations based on the source and destination collections 1027 in the request: 1029 +-----------------------+------------------------+------------------+ 1030 | Source Collection | Destination Collection | Server Operation | 1031 +-----------------------+------------------------+------------------+ 1032 | Non-calendar | Non-calendar | None | 1033 | collection | collection | | 1034 | | | | 1035 | Non-calendar | Calendar collection | (1) | 1036 | collection | | | 1037 | | | | 1038 | Calendar collection | Non-calendar | (2) | 1039 | | collection | | 1040 | | | | 1041 | Calendar collection | Calendar collection | None | 1042 +-----------------------+------------------------+------------------+ 1044 Note 1. The rules in Section 3.2.3.1 are applied for the destination 1045 of the MOVE request. 1047 Note 2. The rules in Section 3.2.3.2 are applied for the source of 1048 the MOVE request. 1050 The behavior of a MOVE method request on a calendar collection is 1051 undefined. 1053 3.2.4. Additional Method Preconditions 1055 This specification defines method preconditions (see Section 16 of 1056 WebDAV [RFC4918]), in addition to the ones in [RFC4791], to provide 1057 machine-parseable information in error responses. 1059 3.2.4.1. CALDAV:unique-scheduling-object-resource Precondition 1061 Name: unique-scheduling-object-resource 1063 Namespace: urn:ietf:params:xml:ns:caldav 1065 Apply to: PUT, COPY, and MOVE 1067 Use with: 403 Forbidden 1069 Purpose: (precondition) -- Servers MAY reject requests to create a 1070 scheduling object resource with an iCalendar "UID" property value 1071 already in use by another scheduling object resource owned by the 1072 same user in other calendar collections. Servers SHOULD report 1073 the URL of the scheduling object resource that is already making 1074 use of the same "UID" property value in the DAV:href element. 1076 Definition: 1078 1080 Example: 1082 1084 /home/bernard/calendars/personal/abc123.ics 1085 1087 3.2.4.2. CALDAV:same-organizer-in-all-components Precondition 1089 Name: same-organizer-in-all-components 1091 Namespace: urn:ietf:params:xml:ns:caldav 1092 Apply to: PUT, COPY, and MOVE 1094 Use with: 403 Forbidden 1096 Purpose: (precondition) -- All the calendar components in a 1097 scheduling object resource MUST contain the same "ORGANIZER" 1098 property value when present. 1100 Definition: 1102 1104 3.2.4.3. CALDAV:allowed-organizer-scheduling-object-change Precondition 1106 Name: allowed-organizer-scheduling-object-change 1108 Namespace: urn:ietf:params:xml:ns:caldav 1110 Apply to: PUT, COPY, and MOVE 1112 Use with: 403 Forbidden 1114 Purpose: (precondition) -- Servers MAY impose restrictions on 1115 modifications allowed by an Organizer. For instance, servers MAY 1116 prevent the Organizer setting the "PARTSTAT" property parameter to 1117 a value other than "NEEDS-ACTION" if the corresponding "ATTENDEE" 1118 property has the "SCHEDULE-AGENT" property parameter set to 1119 "SERVER", or has no "SCHEDULE-AGENT" property parameter. See 1120 Section 3.2.1. 1122 Definition: 1124 1126 3.2.4.4. CALDAV:allowed-attendee-scheduling-object-change Precondition 1128 Name: allowed-attendee-scheduling-object-change 1130 Namespace: urn:ietf:params:xml:ns:caldav 1132 Apply to: PUT, COPY, and MOVE 1134 Use with: 403 Forbidden 1136 Purpose: (precondition) -- Servers MAY impose restrictions on 1137 modifications allowed by an Attendee, subject to the allowed 1138 changes specified in Section 3.2.2.1. 1140 Definition: 1142 1144 3.2.5. DTSTAMP and SEQUENCE Properties 1146 The server MUST ensure that a "DTSTAMP" iCalendar property is present 1147 and set the value to the UTC time that the scheduling message was 1148 generated (as required by iCalendar). 1150 The server MUST ensure that for each type of scheduling operation, 1151 the "SEQUENCE" iCalendar property value is updated as per iTIP 1152 [RFC5546]. 1154 3.2.6. Restrict Recurrence Instances Sent to Attendees 1156 Servers MUST ensure that Attendees only get information about 1157 recurrence instances that explicitly include them as an Attendee, 1158 when delivering scheduling messages for recurring calendar 1159 components. 1161 For example, if an Attendee is invited to only a single instance of a 1162 recurring event, the organizer scheduling object resource will 1163 contain an overridden instance in the form of a separate calendar 1164 component. That separate calendar component will include the 1165 "ATTENDEE" property referencing the "one-off" Attendee. That 1166 Attendee will not be listed in any other calendar components in the 1167 scheduling object resource. Any scheduling messages delivered to the 1168 Attendee will only contain information about this overridden 1169 instance. 1171 As another example, an Attendee could be excluded from one instance 1172 of a recurring event. In that case the organizer scheduling object 1173 resource will include an overridden instance with an "ATTENDEE" list 1174 that does not include the Attendee being excluded. Any scheduling 1175 messages delivered to the Attendee will not specify the overridden 1176 instance but rather include an "EXDATE" property in the "master" 1177 component that defines the recurrence set. 1179 3.2.7. Forcing the Server to Send a Scheduling Message 1181 The iCalendar property parameter "SCHEDULE-FORCE-SEND" defined in 1182 Section 7.2 can be used by a calendar user to force the server to 1183 send a scheduling message to an Attendee or the Organizer in a 1184 situation where the server would not normally send a scheduling 1185 message. For instance, an Organizer could use this property 1186 parameter to request an Attendee, that previously declined an 1187 invitation, to reconsider their participation status without being 1188 forced to modify the event. 1190 3.2.8. Attendee Participation Status 1192 This section specifies additional requirements on the handling of the 1193 "PARTSTAT" property parameter when the "SCHEDULE-AGENT" property 1194 parameter on the corresponding "ATTENDEE" property is set to the 1195 value "SERVER" or is not present. 1197 A reschedule occurs when any "DTSTART", "DTEND", "DURATION", "DUE", 1198 "RRULE", "RDATE", or "EXDATE" property changes in a calendar 1199 component such that existing recurrence instances are impacted by the 1200 changes, as shown in the table below. Servers MUST reset the 1201 "PARTSTAT" property parameter value of all "ATTENDEE" properties, 1202 except the one that corresponds to the Organizer, to "NEEDS-ACTION" 1203 for each calendar component change that causes any instance to be 1204 rescheduled. 1206 +-----------+-------------------------------------------------------+ 1207 | Property | Server Action | 1208 +-----------+-------------------------------------------------------+ 1209 | DTSTART, | Any change to these properties result in "PARTSTAT" | 1210 | DTEND, | being set to "NEEDS-ACTION" | 1211 | DURATION, | | 1212 | DUE | | 1213 | | | 1214 | | | 1215 | | | 1216 | RRULE | A change to or addition of this property that results | 1217 | | in the addition of new recurring instances or a | 1218 | | change in time for existing recurring instances | 1219 | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on | 1220 | | each affected component. | 1221 | | | 1222 | | | 1223 | | | 1224 | RDATE | A change to or addition of this property that results | 1225 | | in the addition of new recurring instances or a | 1226 | | change in time for existing recurring instances | 1227 | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on | 1228 | | each affected component. | 1229 | | | 1230 | | | 1231 | | | 1232 | EXDATE | A change to or removal of this property that results | 1233 | | in the re-instatement of recurring instances result | 1234 | | in "PARTSTAT" being set to "NEEDS-ACTION" on each | 1235 | | affected component. | 1236 +-----------+-------------------------------------------------------+ 1238 The server MAY allow the Organizer's client to change an Attendee's 1239 "PARTSTAT" property parameter value to "NEEDS-ACTION" at any other 1240 time (e.g., when the "LOCATION" property value changes, an Organizer 1241 might wish to re-invite Attendees who might be impacted by the 1242 change). 1244 3.2.9. Schedule Status Values 1246 When scheduling with an Attendee there are two types of status 1247 information that can be returned during the operation. The first 1248 type of status information is a "delivery" status that indicates 1249 whether the scheduling message from the Organizer to the Attendee was 1250 delivered or not, or what the current status of delivery is. The 1251 second type of status information is a "reply" status corresponding 1252 to the Attendee's own "REQUEST-STATUS" information from the 1253 scheduling message reply that is sent back to the Organizer. 1255 Similarly, when an Attendee sends a reply back to the Organizer, 1256 there will be "delivery" status information for the scheduling 1257 message sent to the Organizer. However, there is no "REQUEST-STATUS" 1258 sent back by the Organizer, so there is no equivalent of the "reply" 1259 status as per scheduling messages to Attendees. 1261 The "delivery" status information on an "ORGANIZER" or "ATTENDEE" 1262 iCalendar property is conveyed in the "SCHEDULE-STATUS" property 1263 parameter value (Section 7.3). The status code value for "delivery" 1264 status can be one of the following: 1266 +----------+--------------------------------------------------------+ 1267 | Delivery | Description | 1268 | Status | | 1269 | Code | | 1270 +----------+--------------------------------------------------------+ 1271 | 1.0 | The scheduling message is pending. i.e. the server is | 1272 | | still in the process of sending the message. The | 1273 | | status code value can be expected to change once the | 1274 | | server has completed its sending and delivery | 1275 | | attempts. | 1276 | | | 1277 | | | 1278 | | | 1279 | 1.1 | The scheduling message has been successfully sent. | 1280 | | However, the server does not have explicit information | 1281 | | about whether the scheduling message was successfully | 1282 | | delivered to the recipient. This state can occur with | 1283 | | "store and forward" style scheduling protocols such as | 1284 | | iMIP [RFC6047] (iTIP using email). | 1285 | | | 1286 | | | 1287 | | | 1288 | 1.2 | The scheduling message has been successfully | 1289 | | delivered. | 1290 | | | 1291 | | | 1292 | | | 1293 | 3.7 | The scheduling message was not delivered because the | 1294 | | server did not recognize the calendar user address as | 1295 | | a valid calendar user. Note that this code applies to | 1296 | | both Organizer and Attendee calendar user addresses. | 1297 | | | 1298 | | | 1299 | | | 1300 | 3.8 | The scheduling message was not delivered due to | 1301 | | insufficient privileges. Note that this code applies | 1302 | | to both privileges granted by both the Organizer and | 1303 | | Attendee calendar users. | 1304 | | | 1305 | | | 1306 | | | 1307 | 5.1 | The scheduling message was not delivered because the | 1308 | | server could not complete delivery of the message. | 1309 | | This is likely due to a temporary failure, and the | 1310 | | originator can try to send the message again at a | 1311 | | later time. | 1312 | | | 1313 | | | 1314 | 5.2 | The scheduling message was not delivered because the | 1315 | | server was not able to find a way to deliver the | 1316 | | message. This is likely a permanent failure, and the | 1317 | | originator ought not try to send the message again, at | 1318 | | least without verifying/correcting the calendar user | 1319 | | address of the recipient. | 1320 | | | 1321 | | | 1322 | | | 1323 | 5.3 | The scheduling message was not delivered and was | 1324 | | rejected because scheduling with that recipient is not | 1325 | | allowed. This is likely a permanent failure, and the | 1326 | | originator ought not try to send the message again. | 1327 +----------+--------------------------------------------------------+ 1329 The status code for "reply" status can be any of the valid iTIP 1330 [RFC5546] "REQUEST-STATUS" values. 1332 The 1.xx "REQUEST-STATUS" codes are new. This specification modifies 1333 item (2) of Section 3.6 of [RFC5546] by adding the following 1334 restriction: 1336 For a 1.xx code, all components MUST have exactly the same code. 1338 Definition of the new 1.xx codes is as follows: 1340 3.2.9.1. Status Code 1.0 1342 Status Code: 1.0 1344 Status Description: Pending. 1346 Status Exception Data: None. 1348 Description: Delivery of the iTIP message is pending. 1350 3.2.9.2. Status Code 1.1 1352 Status Code: 1.1 1354 Status Description: Sent. 1356 Status Exception Data: None. 1358 Description: The iTIP message has been sent, though no information 1359 about successful delivery is known. 1361 3.2.9.3. Status Code 1.2 1363 Status Code: 1.2 1365 Status Description: Delivered. 1367 Status Exception Data: None. 1369 Description: The iTIP message has been sent and delivered. 1371 3.2.10. Avoiding Conflicts when Updating Scheduling Object Resources 1373 Scheduling object resources on the server might change frequently as 1374 Attendees change their participation status, triggering updates to 1375 the Organizer, and refreshes of other Attendees' copies of the 1376 scheduling object resource. This can lead to an "inconsequential" 1377 change to a calendar user's data - one that does not directly impact 1378 their own participation status. When this occurs, clients have to 1379 reload calendar data and reconcile with changes being made by 1380 calendar users. To avoid the need for this, the server can instead 1381 merge calendar data changes from a client with changes made as a the 1382 result of a scheduling operation carried out by some other calendar 1383 user. 1385 This specification introduces a new WebDAV resource property CALDAV: 1386 schedule-tag with a corresponding response header "Schedule-Tag", and 1387 a new "If-Schedule-Tag-Match" request header to allow client changes 1388 to be appropriately merged with server changes in the case where the 1389 changes on the server were the result of an "inconsequential" 1390 scheduling message update (one which simply updates the status 1391 information of Attendees due to a reply from another Attendee). 1393 Servers MUST automatically resolve conflicts with "inconsequential" 1394 changes done to scheduling object resources when the "If-Schedule- 1395 Tag-Match" request header is specified. The If-Schedule-Tag-Match 1396 request header applies only to the Request-URI, and not to the 1397 Destination of a COPY or MOVE. 1399 A response to any successful GET or PUT request targeting a 1400 scheduling object resource MUST include a Schedule-Tag response 1401 header with the value set to the same value as the CALDAV:schedule- 1402 tag WebDAV property of the resource. 1404 A response to any successful COPY or MOVE request that specifies a 1405 Destination request header targeting a scheduling object resource 1406 MUST include a Schedule-Tag response header with the value set to the 1407 same value as the CALDAV:schedule-tag WebDAV property of the 1408 destination resource. 1410 Clients SHOULD use the If-Schedule-Tag-Match header on requests that 1411 update scheduling object resources, instead of HTTP ETag-based 1412 precondition tests (e.g., If-Match). Normal ETag-based precondition 1413 tests are used in all other cases, e.g., for synchronization. 1415 The value of the CALDAV:schedule-tag property changes according to 1416 these rules: 1418 o For an Organizer's copy of a scheduling object resource: 1420 1. The server MUST NOT change the CALDAV:schedule-tag property 1421 value when the scheduling object resource is updated as the 1422 result of automatically processing a scheduling message reply 1423 from an Attendee. For instance, when an Attendee replies to 1424 the Organizer, the CALDAV:schedule-tag property is unchanged 1425 after the Organizer's scheduling object resource has been 1426 automatically updated by the server with the Attendee's new 1427 participation status. 1429 2. The server MUST change CALDAV:schedule-tag property value when 1430 the scheduling object resource is changed directly via an HTTP 1431 request (e.g., PUT, COPY or MOVE). 1433 o For an Attendee's copy of a scheduling object resource: 1435 1. The server MUST change the CALDAV:schedule-tag property value 1436 when the scheduling object resource is changed as the result 1437 of processing a scheduling message update from an Organizer 1438 that contains changes other than just the participation status 1439 of Attendees. 1441 2. The server MUST NOT change the CALDAV:schedule-tag property 1442 value when the scheduling object resource is changed as the 1443 result of processing a scheduling message update from an 1444 Organizer that only specify changes in the participation 1445 status of Attendees. For instance, when Attendee "A" replies 1446 to Organizer "O", and Attendee "B" receives a scheduling 1447 message update from Organizer "O" with the new participation 1448 status of Attendee "A", the CALDAV:schedule-tag property of 1449 Attendee "B"s scheduling object resource would remain the 1450 same. 1452 3. The server MUST change the CALDAV:schedule-tag property value 1453 when the scheduling object resource is changed directly via an 1454 HTTP request (e.g., PUT, COPY or MOVE). 1456 3.2.10.1. PUT 1458 Clients MAY use the If-Schedule-Tag-Match request header to do a PUT 1459 request that ensures that "inconsequential" changes on the server do 1460 not result in a precondition error. The value of the request header 1461 is set to the last Schedule-Tag value received for the resource being 1462 modified. If the value of the If-Schedule-Tag-Match header matches 1463 the current value of the CALDAV:schedule-tag property the server MUST 1464 take any "ATTENDEE" property changes for all Attendees other than the 1465 owner of the scheduling object resource and apply those to the new 1466 resource being stored. Otherwise, the server MUST fail the request 1467 with a 412 Precondition Failed status code. 1469 3.2.10.2. DELETE, COPY or MOVE 1471 Clients MAY use the If-Schedule-Tag-Match request header to do a 1472 DELETE, COPY or MOVE request that ensures that "inconsequential" 1473 changes on the server do not result in a precondition error. The 1474 value of the request header is set to the last Schedule-Tag value 1475 received for the resource being deleted. If the value of the If- 1476 Schedule-Tag-Match header matches the current value of the CALDAV: 1477 schedule-tag property the server performs the normal DELETE, COPY or 1478 MOVE request processing for the resource. Otherwise, the server MUST 1479 fail the request with a 412 Precondition Failed status code. 1481 4. Processing Incoming Scheduling Messages 1483 Scheduling operations can cause the delivery of a scheduling message 1484 into an Organizer's or Attendee's scheduling Inbox collection. 1485 Servers MUST automatically process incoming scheduling messages using 1486 the rules defined by [RFC5546], by creating or updating the 1487 corresponding scheduling object resources on calendars owned by the 1488 owner of the scheduling Inbox collection. In addition, the 1489 scheduling message is stored in the scheduling Inbox collection as an 1490 indicator to the client that a scheduling operation has taken place. 1491 Scheduling messages are typically removed from the scheduling Inbox 1492 collection by the client once the calendar user has acknowledged the 1493 change. 1495 The server MUST take into account privileges on the scheduling Inbox 1496 collection when processing incoming scheduling messages, to determine 1497 whether delivery of the scheduling message is allowed. Privileges on 1498 calendars containing any matching scheduling object resource are not 1499 considered in this case (i.e., a schedule message from another user 1500 can cause modifications to resources in calendar collections that the 1501 other user would not normally have read or write access to). 1502 Additionally, servers MUST take into account any scheduling Inbox 1503 collection preconditions (see Section 2.2) when delivering the 1504 scheduling message, and it MUST take into account the similar 1505 preconditions on any calendar collection which contains, or would 1506 contain, the corresponding scheduling object resource. 1508 4.1. Processing Organizer Requests, Additions, and Cancellations 1510 For a scheduling message sent by an Organizer, the server first tries 1511 to locate a corresponding scheduling object resource belonging to the 1512 Attendee. If no matching scheduling object resource exists, the 1513 server treats the scheduling message as a new message, otherwise it 1514 is treated as an update. 1516 In the case of a new message, the server processes the scheduling 1517 message and creates a new scheduling object resource as per 1518 Section 4.3. 1520 In the case of an update, the server processes the scheduling message 1521 and updates the matching scheduling object resource belonging to the 1522 Attendee to reflect the changes sent by the Organizer. 1524 In each case, the scheduling message MUST only appear in the 1525 Attendee's scheduling Inbox collection once all automatic processing 1526 has been done. 1528 4.2. Processing Attendee Replies 1530 For a scheduling message reply sent by an Attendee, the server first 1531 locates the corresponding scheduling object resource belonging to the 1532 Organizer. If the corresponding scheduling object resource cannot be 1533 found, the server SHOULD ignore the scheduling message. 1535 The server MUST then update the "PARTSTAT" iCalendar property 1536 parameter value of each "ATTENDEE" iCalendar property in the 1537 scheduling object resource to match the changes indicated in the 1538 reply (taking into account the fact that an Attendee could have 1539 created a new overridden iCalendar component to indicate different 1540 participation status on one or more instances of a recurring event). 1542 The server MUST also update or add the "SCHEDULE-STATUS" property 1543 parameter on each matching "ATTENDEE" iCalendar property and set its 1544 value to that of the "REQUEST-STATUS" property in the reply, or to 1545 "2.0" if "REQUEST-STATUS" is not present (also taking into account 1546 recurrence instances). If there are multiple "REQUEST-STATUS" 1547 properties in the reply, the "SCHEDULE-STATUS" property parameter 1548 value is set to a comma-separated list of status codes, one from each 1549 "REQUEST-STATUS" property. 1551 The server SHOULD send scheduling messages to all the other Attendees 1552 indicating the change in participation status of the Attendee 1553 replying, subject to the recurrence requirements of Section 3.2.6. 1555 The scheduling message MUST only appear in the Organizer's scheduling 1556 Inbox collection once all automatic processing has been done. 1558 4.3. Default Calendar Collection 1560 The server processes scheduling messages received for an Attendee by 1561 creating a new scheduling object resource in a calendar collection 1562 belonging to the Attendee, when one does not already exist. A 1563 calendar user that is an Attendee in a scheduling operation MUST have 1564 at least one valid calendar collection available. If there is no 1565 valid calendar collection, then the server MUST reject the attempt to 1566 deliver the scheduling message to the Attendee. 1568 Servers MAY provide support for a default calendar collection, that 1569 is, the calendar collection in which new scheduling object resources 1570 will be created. The CALDAV:schedule-default-calendar-URL WebDAV 1571 property, which can be present on the scheduling Inbox collection of 1572 a calendar user, specifies if this calendar user has a default 1573 calendar collection. See Section 9.2. 1575 Servers SHOULD create new scheduling object resources in the default 1576 calendar collection, if the CALDAV:schedule-default-calendar-URL 1577 WebDAV property is set. 1579 Servers MAY allow clients to change the default calendar collection 1580 by changing the value of the CALDAV:schedule-default-calendar-URL 1581 WebDAV property on the scheduling Inbox collection. However, the 1582 server MUST ensure that any new value for that property refers to a 1583 valid calendar collection belonging to the owner of the scheduling 1584 Inbox collection. 1586 Servers MUST reject any attempt to delete the default calendar 1587 collection. 1589 4.3.1. Additional Method Preconditions 1591 This specification defines additional method preconditions (see 1592 Section 16 of WebDAV [RFC4918]) to provide machine-parseable 1593 information in error responses. 1595 4.3.1.1. CALDAV:default-calendar-needed Precondition 1597 Name: default-calendar-needed 1599 Namespace: urn:ietf:params:xml:ns:caldav 1601 Apply to: DELETE 1603 Use with: 403 Forbidden 1605 Purpose: (precondition) -- The client attempted to delete the 1606 calendar collection currently referenced by the CALDAV:schedule- 1607 default-calendar-URL property, or attempted to remove the CALDAV: 1608 schedule-default-calendar-URL property on the scheduling Inbox 1609 collection on a server that doesn't allow such operations. 1611 Definition: 1613 1615 4.3.1.2. CALDAV:valid-schedule-default-calendar-URL Precondition 1617 Name: valid-schedule-default-calendar-URL 1619 Namespace: urn:ietf:params:xml:ns:caldav 1620 Apply to: PROPPATCH 1622 Use with: 403 Forbidden 1624 Purpose: (precondition) -- The client attempted to set the CALDAV: 1625 schedule-default-calendar-URL property to a DAV:href element that 1626 doesn't reference a valid calendar collection. Note: Servers that 1627 do not allow clients to change the CALDAV:schedule-default- 1628 calendar-URL property would simply return the DAV:cannot-modify- 1629 protected-property precondition defined in Section 16 of WebDAV 1630 [RFC4918]. 1632 Definition: 1634 1636 5. Request for Busy Time Information 1638 Busy time information of one or more calendar users can be determined 1639 by submitting a POST request targeted at the scheduling Outbox 1640 collection of the calendar user requesting the information (the 1641 Organizer). To accomplish this, the request body MUST contain a 1642 "VFREEBUSY" calendar component with the "METHOD" iCalendar property 1643 set to the value "REQUEST" as specified in Section 3.3.2 of iTIP 1644 [RFC5546]. The resource identified by the Request-URI MUST be a 1645 resource collection of type CALDAV:schedule-outbox (Section 2.1). 1646 The "ORGANIZER" property value in the "VFREEBUSY" component MUST 1647 match one of the calendar user addresses of the owner of the Outbox 1648 collection. 1650 A response to a busy time request that indicates status for one or 1651 more calendar users MUST be an XML document with a CALDAV:schedule- 1652 response XML element as its root element. This element MUST contain 1653 one CALDAV:response element for each calendar user, with each of 1654 those containing elements that indicate which calendar user they 1655 correspond to, the scheduling status for that calendar user, any 1656 error codes and an optional description. For a successful busy time 1657 request, a CALDAV:calendar-data element is also present for each 1658 calendar user, containing the actual busy time information (i.e., an 1659 iCalendar "VFREEBUSY" component). See Section 10.1 for the detail on 1660 the child elements. See Appendix B.5 for an example busy time 1661 request and response. 1663 5.1. Status Codes 1665 The list below summarizes the most common status codes used for this 1666 method. However, clients need to be prepared to handle other 2/3/4/ 1667 5xx series status codes as well. 1669 200 (OK) - The command succeeded. 1671 204 (No Content) - The command succeeded. 1673 400 (Bad Request) - The client has provided an invalid scheduling 1674 message. 1676 403 (Forbidden) - The client cannot submit a scheduling message to 1677 the specified Request-URI. 1679 404 (Not Found) - The URL in the Request-URI was not present. 1681 423 (Locked) - The specified resource is locked and the client 1682 either is not a lock owner or the lock type requires a lock token 1683 to be submitted and the client did not submit it. 1685 5.2. Additional Method Preconditions 1687 The following are existing preconditions that are reused for the POST 1688 method on an Outbox collection. 1690 o DAV:need-privileges [RFC3744] 1692 o CALDAV:supported-calendar-data [RFC4791] 1694 o CALDAV:valid-calendar-data [RFC4791] 1696 o CALDAV:max-resource-size [RFC4791] 1698 The following are new method preconditions for the POST method on an 1699 Outbox collection. 1701 5.2.1. CALDAV:valid-scheduling-message Precondition 1703 Name: valid-scheduling-message 1705 Namespace: urn:ietf:params:xml:ns:caldav 1707 Apply to: POST 1709 Use with: 400 Bad Request 1711 Purpose: (precondition) -- The resource submitted in the POST 1712 request MUST obey all the restrictions specified in Section 3.3.2 1713 of iTIP [RFC5546]. 1715 Definition: 1717 1719 5.2.2. CALDAV:valid-organizer Precondition 1721 Name: valid-organizer 1723 Namespace: urn:ietf:params:xml:ns:caldav 1725 Apply to: POST 1727 Use with: 403 Forbidden 1729 Purpose: (precondition) -- The "ORGANIZER" property value in the 1730 POST request's scheduling message MUST match one of the calendar 1731 user addresses of the owner of the scheduling Outbox collection 1732 being targeted by the request; 1734 Definition: 1736 1738 6. Scheduling Privileges 1740 New scheduling privileges are defined in this section. All the 1741 scheduling privileges MUST be non-abstract and MUST appear in the 1742 DAV:supported-privilege-set property of scheduling Outbox and Inbox 1743 collections on which they are defined. 1745 The tables specified in Appendix A clarify which scheduling methods 1746 (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling 1747 privilege defined in this section. 1749 6.1. Privileges on Scheduling Inbox Collections 1751 This section defines new WebDAV ACL [RFC3744] privileges that are for 1752 use on scheduling Inbox collections. These privileges determine 1753 whether delivery of scheduling messages from a calendar user is 1754 allowed by the calendar user who "owns" the scheduling Inbox 1755 collection. This allows calendar users to choose which other 1756 calendar users can schedule with them. 1758 Note that when a scheduling message is delivered to a calendar user, 1759 in addition to a scheduling object resource being created in the 1760 calendar user's scheduling Inbox collection, a new scheduling object 1761 resource might be created or an existing one updated in a calendar 1762 belonging to the calendar user. In that case, the ability to create 1763 or update the scheduling object resource in the calendar is 1764 controlled by the privileges assigned to the scheduling Inbox 1765 collection. 1767 The privileges defined in this section are ignored if applied to a 1768 resource other than a scheduling Inbox collection. 1770 6.1.1. CALDAV:schedule-deliver Privilege 1772 CALDAV:schedule-deliver is an aggregate privilege as per Section 6.3. 1774 1776 6.1.2. CALDAV:schedule-deliver-invite Privilege 1778 The CALDAV:schedule-deliver-invite privilege controls the processing 1779 and delivery of scheduling messages coming from an Organizer. 1781 1783 6.1.3. CALDAV:schedule-deliver-reply Privilege 1785 The CALDAV:schedule-deliver-reply privilege controls the processing 1786 and delivery of scheduling messages coming from an Attendee. 1788 1790 6.1.4. CALDAV:schedule-query-freebusy Privilege 1792 The CALDAV:schedule-query-freebusy privilege controls freebusy 1793 requests targeted at the owner of the scheduling Inbox collection. 1795 1797 6.2. Privileges on Scheduling Outbox Collections 1799 This section defines new WebDAV ACL [RFC3744] privileges that are 1800 defined for use on scheduling Outbox collections. These privileges 1801 determine which calendar users are allowed to send scheduling 1802 messages on behalf of the calendar user who "owns" the scheduling 1803 Outbox collection. This allows calendar users to choose other 1804 calendar users who can act on their behalf (e.g. assistants working 1805 on behalf of their boss). 1807 The privileges defined in this section are ignored if applied to a 1808 resource other than a scheduling Outbox collection. 1810 6.2.1. CALDAV:schedule-send Privilege 1812 CALDAV:schedule-send is an aggregate privilege as per Section 6.3. 1814 1816 6.2.2. CALDAV:schedule-send-invite Privilege 1818 The CALDAV:schedule-send-invite privilege controls the sending of 1819 scheduling messages by Organizers. 1821 Users granted the DAV:bind privilege on a calendar collection, or 1822 DAV:write privilege on scheduling object resources, will also need 1823 the CALDAV:schedule-send-invite privilege granted on the scheduling 1824 Outbox collection of the owner of the calendar collection or 1825 scheduling object resource in order to be allowed to create, modify 1826 or delete scheduling object resources in a way that will trigger the 1827 CalDAV server to deliver scheduling messages to attendees. 1829 1831 6.2.3. CALDAV:schedule-send-reply Privilege 1833 The CALDAV:schedule-send-reply privilege controls the sending of 1834 scheduling messages by Attendees. 1836 Users granted the DAV:bind privilege on a calendar collection, or 1837 DAV:write privilege on scheduling object resources, will also need 1838 the CALDAV:schedule-send-reply privilege granted on the scheduling 1839 Outbox collection of the owner of the calendar collection or 1840 scheduling object resource in order to be allowed to create, modify 1841 or delete scheduling object resources in a way that will trigger the 1842 CalDAV server to deliver scheduling message replies to the organizer. 1844 1846 6.2.4. CALDAV:schedule-send-freebusy Privilege 1848 The CALDAV:schedule-send-freebusy privilege controls the use of the 1849 POST method to submit scheduling messages that specify the scheduling 1850 method "REQUEST" with a "VFREEBUSY" calendar component. 1852 1854 6.3. Aggregation of Scheduling Privileges 1856 Server implementations MUST aggregate the scheduling privileges as 1857 follows: 1859 DAV:all contains CALDAV:schedule-send and CALDAV:schedule-deliver; 1861 CALDAV:schedule-send contains CALDAV:schedule-send-invite, CALDAV: 1862 schedule-send-reply, and CALDAV:schedule-send-freebusy; 1864 CALDAV:schedule-deliver contains CALDAV:schedule-deliver-invite, 1865 CALDAV:schedule-deliver-reply, and CALDAV:schedule-query-freebusy. 1867 The following diagram illustrates how scheduling privileges are 1868 aggregated according to the above requirements. 1870 [DAV:all] (aggregate) 1871 | 1872 +-- [CALDAV:schedule-deliver] (aggregate) 1873 | | 1874 | +-- [CALDAV:schedule-deliver-invite] 1875 | +-- [CALDAV:schedule-deliver-reply] 1876 | +-- [CALDAV:schedule-query-freebusy] 1877 | 1878 +-- [CALDAV:schedule-send] (aggregate) 1879 | 1880 +-- [CALDAV:schedule-send-invite] 1881 +-- [CALDAV:schedule-send-reply] 1882 +-- [CALDAV:schedule-send-freebusy] 1884 7. Additional iCalendar Property Parameters 1886 This specification defines additional iCalendar property parameters 1887 to support the CalDAV scheduling extensions. 1889 7.1. Schedule Agent Parameter 1891 Parameter Name: SCHEDULE-AGENT 1893 Purpose: To specify the agent expected to deliver scheduling 1894 messages to the corresponding Organizer or Attendee. 1896 Format Definition: This property parameter is defined by the 1897 following notation: 1899 scheduleagentparam = "SCHEDULE-AGENT" "=" 1900 ("SERVER" ; The server handles scheduling 1901 / "CLIENT" ; The client handles scheduling 1902 / "NONE" ; No scheduling 1903 / x-name ; Experimental type 1904 / iana-token) ; Other IANA registered type 1905 ; 1906 ; If the parameter is not present its value defaults to SERVER. 1907 ; "x-name" and "iana-token" are defined in Section 3.1 of 1908 ; [RFC5545]. 1910 Description: This property parameter MAY be specified on "ORGANIZER" 1911 or "ATTENDEE" iCalendar properties. In the absence of this 1912 parameter, the value "SERVER" MUST be used for the default 1913 behavior. The value determines whether or not a scheduling 1914 operation on a server will cause a scheduling message to be sent 1915 to the corresponding calendar user identified by the "ORGANIZER" 1916 or "ATTENDEE" property value. When the value "SERVER" is 1917 specified, or the parameter is absent, then it is the server's 1918 responsibility to send a scheduling message as part of a 1919 scheduling operation. When the value "CLIENT" is specified, that 1920 indicates that the client is handling scheduling messages with the 1921 calendar user itself. When "NONE" is specified, no scheduling 1922 messages are being sent to the calendar user. 1924 Servers MUST NOT include this parameter in any scheduling messages 1925 sent as the result of a scheduling operation. 1927 Clients MUST NOT include this parameter in any scheduling messages 1928 that they themselves send. 1930 The parameter value MUST be the same on every "ORGANIZER" property 1931 in a scheduling object resource. 1933 The parameter value MUST be the same on each "ATTENDEE" property 1934 whose values match in a scheduling object resource. 1936 Servers and clients MUST treat x-name and iana-token values they 1937 do not recognize the same way as they would the "NONE" value. 1939 Example: 1941 ORGANIZER;SCHEDULE-AGENT=SERVER:mailto:bernard@example.com 1942 ATTENDEE;SCHEDULE-AGENT=NONE:mailto:cyrus@example.com 1944 7.2. Schedule Force Send Parameter 1946 Parameter Name: SCHEDULE-FORCE-SEND 1948 Purpose: To force a scheduling message to be sent to the calendar 1949 user specified by the property. 1951 Format Definition: This property parameter is defined by the 1952 following notation: 1954 scheduleforcesendparam = "SCHEDULE-FORCE-SEND" "=" 1955 ("REQUEST" ; Force a "REQUEST" 1956 / "REPLY" ; Force a "REPLY" 1957 / iana-token) 1958 ; 1959 ; "iana-token" is defined in Section 3.1 of [RFC5545]. Its value 1960 ; MUST be an IANA registered iCalendar "METHOD" property value. 1962 Description: This property parameter MAY be specified on "ATTENDEE" 1963 and "ORGANIZER" properties on which the "SCHEDULE-AGENT" property 1964 parameter is set to the value "SERVER" or is not specified. This 1965 property parameter is used to force a server to send a scheduling 1966 message to a specific calendar user in situations where the server 1967 would not send a scheduling message otherwise (e.g., when no 1968 change that warrants the delivery of a new scheduling message was 1969 performed on the scheduling object resource). An Organizer MAY 1970 specify this parameter on an "ATTENDEE" property with the value 1971 "REQUEST" to force a "REQUEST" scheduling message to be sent to 1972 this Attendee. An Attendee MAY specify this parameter on the 1973 "ORGANIZER" with the value "REPLY" to force a "REPLY" scheduling 1974 message to be sent to the Organizer. 1976 Servers MUST NOT preserve this property parameter in scheduling 1977 object resources, nor include it in any scheduling messages sent 1978 as the result of a scheduling operation. 1980 Clients MUST NOT include this parameter in any scheduling messages 1981 that they themselves send. 1983 Servers MUST set the "SCHEDULE-STATUS" parameter of the "ATTENDEE" 1984 or "ORGANIZER" to 2.3 (i.e., "Success, invalid property parameter 1985 ignored", see Section 3.6 of [RFC5546]) when the "SCHEDULE-FORCE- 1986 SEND" parameter is set to an iana-token value they do not 1987 recognize. 1989 Example: 1991 ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:cyrus@example.com 1992 ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard@example.com 1994 7.3. Schedule Status Parameter 1996 Parameter Name: SCHEDULE-STATUS 1998 Purpose: To specify the status codes returned from processing of the 1999 most recent scheduling message sent to the corresponding Attendee, 2000 or received from the corresponding Organizer. 2002 Format Definition: This property parameter is defined by the 2003 following notation: 2005 schedulestatusparam = "SCHEDULE-STATUS" "=" 2006 ( statcode 2007 / DQUOTE statcode *("," statcode) DQUOTE) 2008 ; 2009 ; "statcode" is defined in Section 3.8.8.3 of [RFC5545]. Value 2010 ; is a single "statcode" or a comma-separated list of "statcode" 2011 ; values. 2013 Description: This property parameter MAY be specified on the 2014 "ATTENDEE" and "ORGANIZER" properties. 2016 Servers MUST only add or change this property parameter on any 2017 "ATTENDEE" properties corresponding to calendar users who were 2018 sent a scheduling message via a scheduling operation. Clients 2019 SHOULD NOT change or remove this parameter if it was provided by 2020 the server. In the case where the client is handling the 2021 scheduling, the client MAY add, change or remove this parameter to 2022 indicate the last scheduling message status it received. 2024 Servers MUST add this parameter to any "ORGANIZER" properties 2025 corresponding to calendar users who were sent a scheduling message 2026 reply by an Attendee via a scheduling operation. Clients SHOULD 2027 NOT change or remove this parameter if it was provided by the 2028 server. In the case where the client is handling the scheduling, 2029 the client MAY add, change or remove this parameter to indicate 2030 the last scheduling message status it received. 2032 Servers MUST NOT include this parameter in any scheduling messages 2033 sent as the result of a scheduling operation. 2035 Clients MUST NOT include this parameter in any scheduling messages 2036 that they themselves send. 2038 Values for this property parameter are described in Section 3.2.9. 2040 Example: 2042 ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com 2043 ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com 2045 8. Additional Message Header Fields 2047 This specification defines additional HTTP request and response 2048 headers for use with CalDAV. 2050 8.1. Schedule-Reply Request Header 2052 Schedule-Reply = "Schedule-Reply" ":" ("T" | "F") 2054 Example: 2056 Schedule-Reply: F 2058 When an Attendee removes a scheduling object resource as per 2059 Section 3.2.2.4, and the Schedule-Reply header is not present, or 2060 present and set to the value "T" (true), the server MUST send an 2061 appropriate reply scheduling message with the Attendee's "PARTSTAT" 2062 iCalendar property parameter value set to "DECLINED" as part of its 2063 normal scheduling operation processing. 2065 When the Schedule-Reply header is set to the value "F" (false), the 2066 server MUST NOT send a scheduling message as part of its normal 2067 scheduling operation processing. 2069 The Schedule-Reply request header is used by a client to indicate to 2070 a server whether or not a scheduling operation ought to occur when an 2071 Attendee deletes a scheduling object resource. In particular it 2072 controls whether a reply scheduling message is sent to the Organizer 2073 as a result of the removal. There are situations in which 2074 unsolicited scheduling messages need to be silently removed (or 2075 ignored) for security or privacy reasons. This request header allows 2076 the scheduling object resource to be removed if such a need arises. 2078 8.2. Schedule-Tag Response Header 2080 The Schedule-Tag response header provides the current value of the 2081 CALDAV:schedule-tag property value. The behavior of this response 2082 header is described in Section 3.2.10. 2084 All scheduling object resources MUST support the Schedule-Tag header. 2086 Schedule-Tag = "Schedule-Tag" ":" opaque-tag 2087 ; "opaque-tag" is defined in Section 3.11 of [RFC2616] 2089 Example: 2091 Schedule-Tag: "12ab34-cd56ef" 2093 8.3. If-Schedule-Tag-Match Request Header 2095 The If-Schedule-Tag-Match request header field is used with a method 2096 to make it conditional. Clients can set this header to the value 2097 returned in the Schedule-Tag response header, or the CALDAV:schedule- 2098 tag property, of a scheduling object resource previously retrieved 2099 from the server to avoid overwriting "consequential" changes to the 2100 scheduling object resource. 2102 All scheduling object resources MUST support the If-Schedule-Tag- 2103 Match header. 2105 If-Schedule-Tag-Match = "If-Schedule-Tag-Match" ":" opaque-tag 2106 ; "opaque-tag" is defined in Section 3.11 of [RFC2616] 2108 Example: 2110 If-Schedule-Tag-Match: "12ab34-cd56ef" 2112 9. Additional WebDAV Properties 2114 This specification defines the following new WebDAV properties for 2115 use with CalDAV. 2117 9.1. CALDAV:schedule-calendar-transp Property 2119 Name: schedule-calendar-transp 2121 Namespace: urn:ietf:params:xml:ns:caldav 2123 Purpose: Determines whether the calendar object resources in a 2124 calendar collection will affect the owner's busy time information. 2126 Protected: This property MAY be protected and SHOULD NOT be returned 2127 by a PROPFIND allprop request (as defined in Section 14.2 of 2128 [RFC4918]). 2130 COPY/MOVE behavior: This property value SHOULD be kept during a MOVE 2131 operation, and SHOULD be copied and preserved in a COPY. 2133 Description: This property SHOULD be defined on all calendar 2134 collections. If present, it contains one of two XML elements that 2135 indicate whether the calendar object resources in the calendar 2136 collection ought to contribute to the owner's busy time. When the 2137 CALDAV:opaque element is used, all calendar object resources in 2138 the corresponding calendar collection MUST contribute to busy 2139 time, assuming access privileges and other iCalendar properties 2140 allow it to. When the CALDAV:transparent XML element is used, the 2141 calendar object resources in the corresponding calendar collection 2142 MUST NOT contribute to busy time. 2144 If this property is not present on a calendar collection, then the 2145 default value CALDAV:opaque MUST be assumed. 2147 Definition: 2149 2151 2152 2154 2155 2157 Example: 2159 2161 2162 2164 9.2. CALDAV:schedule-default-calendar-URL Property 2166 Name: schedule-default-calendar-URL 2168 Namespace: urn:ietf:params:xml:ns:caldav 2170 Purpose: Specifies a default calendar for an Attendee where new 2171 scheduling object resources are created. 2173 Protected: This property MAY be protected in the case where a server 2174 does not support changing the default calendar, or does not 2175 support a default calendar. 2177 COPY/MOVE behavior: This property is only defined on a scheduling 2178 Inbox collection which cannot be moved or copied. 2180 Description: This property MAY be defined on a scheduling Inbox 2181 collection. If present, it contains zero or one DAV:href XML 2182 elements. When a DAV:href element is present, its value indicates 2183 a URL to a calendar collection that is used as the default 2184 calendar. When no DAV:href element is present, it indicates that 2185 there is no default calendar. In the absence of this property 2186 there is no default calendar. When there is no default calendar 2187 the server is free to choose the calendar in which a new 2188 scheduling object resource is created. See Section 4.3. 2190 Definition: 2192 2194 Example: 2196 2198 /home/cyrus/calendars/work/ 2199 2201 9.3. CALDAV:schedule-tag Property 2203 Name: schedule-tag 2205 Namespace: urn:ietf:params:xml:ns:caldav 2207 Purpose: Indicates whether a scheduling object resource has had a 2208 "consequential" change made to it. 2210 Value: opaque-tag (defined in Section 3.11 of [RFC2616]) 2212 Protected: This property MUST be protected as only the server can 2213 update the value. 2215 COPY/MOVE behavior: This property value is determined by the server 2216 and MAY be different from the value on source resource. 2218 Description: The CALDAV:schedule-tag property MUST be defined on all 2219 scheduling object resources. This property is described in 2220 Section 3.2.10. 2222 Definition: 2224 2226 Example: 2228 "12345-67890" 2231 10. XML Element Definitions 2233 10.1. CALDAV:schedule-response XML Element 2235 Name: schedule-response 2237 Namespace: urn:ietf:params:xml:ns:caldav 2239 Purpose: Contains the set of responses for a POST method request. 2241 Description: See Section 5. 2243 Definition: 2245 2247 10.2. CALDAV:response XML Element 2249 Name: response 2251 Namespace: urn:ietf:params:xml:ns:caldav 2253 Purpose: Contains a single response for a POST method request. 2255 Description: See Section 5. 2257 Definition: 2259 2265 2269 10.3. CALDAV:recipient XML Element 2271 Name: recipient 2273 Namespace: urn:ietf:params:xml:ns:caldav 2275 Purpose: The calendar user address that the enclosing response for a 2276 POST method request is for. 2278 Description: See Section 5. 2280 Definition: 2282 2284 10.4. CALDAV:request-status XML Element 2286 Name: request-status 2288 Namespace: urn:ietf:params:xml:ns:caldav 2290 Purpose: The iTIP "REQUEST-STATUS" property value for this response. 2292 Description: See Section 5. 2294 Definition: 2296 2298 11. Security Considerations 2300 The process of scheduling involves the sending and receiving of 2301 scheduling messages. As a result, the security problems related to 2302 messaging in general are relevant here. In particular the 2303 authenticity of the scheduling messages needs to be verified. 2304 Servers and clients MUST use an HTTP connection protected with TLS as 2305 defined in [RFC2818] for all scheduling operations. Clients MUST use 2306 the procedures detailed in Section 6 of [RFC6125] to verify the 2307 authenticity of the server. Servers MUST make use of HTTP 2308 authentication [RFC2617] to verify the authenticity of the calendar 2309 user for whom the client is sending requests. 2311 11.1. Preventing Denial of Service Attacks 2313 Servers MUST ensure that clients cannot consume excessive server 2314 resources by carrying out "large" scheduling operations. In 2315 particular, servers SHOULD enforce CALDAV:max-resource-size, CALDAV: 2316 max-instances and CALDAV:max-attendees-per-instance pre-conditions as 2317 applicable for scheduling Inbox and Outbox collections. 2319 11.2. Verifying Scheduling Operations 2321 When handling a scheduling operation: 2323 1. Servers MUST verify that the principal associated with the DAV: 2324 owner of the calendar collection in which a scheduling object 2325 resource is being manipulated contains a CALDAV:schedule-outbox- 2326 URL property value. 2328 2. Servers MUST verify that the currently authenticated user has the 2329 CALDAV:schedule-send privilege, or a sub-privilege aggregated 2330 under this privilege, on the scheduling Outbox collection of the 2331 DAV:owner of the calendar collection in which a scheduling object 2332 resource is being manipulated. 2334 3. Servers MUST only deliver scheduling messages to recipients when 2335 the CALDAV:schedule-deliver privilege, or a sub-privilege 2336 aggregated under this privilege, is granted on the recipient's 2337 scheduling Inbox collection for the principal associated with the 2338 DAV:owner of the calendar collection in which a scheduling object 2339 resource is being manipulated. 2341 4. To prevent impersonation of calendar users, the server MUST 2342 verify that the "ORGANIZER" property in an organizer scheduling 2343 object resource matches one of the calendar user addresses of the 2344 DAV:owner of the calendar collection in which the resource is 2345 stored. 2347 5. To prevent spoofing of an existing scheduling object resource, 2348 servers MUST verify that the "UID" iCalendar property value in a 2349 new scheduling object resource does not match that of an existing 2350 scheduling object resource with a different "ORGANIZER" property 2351 value. 2353 11.3. Verifying Busy Time Information Requests 2355 When handling a POST request on a scheduling Outbox collection: 2357 1. Servers MUST verify that the principal associated with the 2358 calendar user address specified in the "ORGANIZER" property of 2359 the scheduling message data in the request contains a CALDAV: 2360 schedule-outbox-URL property value that matches the scheduling 2361 Outbox collection targeted by the request. 2363 2. Servers MUST verify that the currently authenticated user has the 2364 CALDAV:schedule-send privilege, or a sub-privilege aggregated 2365 under this privilege, on the scheduling Outbox collection 2366 targeted by the request. 2368 3. Servers MUST only return valid freebusy information for 2369 recipients when the CALDAV:schedule-deliver privilege, or a sub- 2370 privilege aggregated under this privilege, is granted on the 2371 recipient's scheduling Inbox collection for the principal 2372 associated with the DAV:owner of the scheduling Outbox collection 2373 targeted by the request. 2375 11.4. Privacy Issues 2377 This specification only defines how calendar users on the same server 2378 are able to schedule with each other - unauthenticated users have no 2379 way to carry out scheduling operations. Access control privileges 2380 (as per Section 6) can control which of those users can schedule with 2381 others. Calendar users not wishing to expose their calendar 2382 information to other users can do so by denying privileges to 2383 specific users, or all users, for all scheduling operations, or 2384 perhaps only freebusy. 2386 Attendees can also use the Schedule-Reply request header 2387 (Section 8.1) with the value set to "F" to prevent notification to an 2388 Organizer that a scheduling object resource was deleted. This allows 2389 Attendees to remove unwanted scheduling messages without any response 2390 to the Organizer. 2392 Servers MUST NOT expose any private iCalendar data, or WebDAV 2393 resource state information (URLs, WebDAV properties, etc) for one 2394 calendar user to another via scheduling messages or error responses 2395 to scheduling operations. In particular, as per Section 8.1 of 2396 [RFC4918], authorization errors MUST take preference over other 2397 errors. 2399 11.5. Mitigation of iTIP Threats 2401 Section 6.1 of iTIP [RFC5546] defines a set of potential threats in a 2402 scheduling system, and in Section 6.2 defines recommendations on how 2403 those can be addressed in protocols using iTIP. This specification 2404 addresses the iTIP threats in the following manner: 2406 Spoofing the Organizer Addressed by item 4 in Section 11.2. 2408 Spoofing the Attendee Addressed by item 2 in Section 11.2 and 2409 Section 3.2.2.1. 2411 Unauthorized Replacement of the Organizer Addressed by item 5 in 2412 Section 11.2. 2414 Eavesdropping and Data Integrity Addressed by requiring TLS. 2416 Flooding a Calendar Addressed by requirements in Section 11.1 2418 Unauthorized REFRESH Requests This specification does not support 2419 the REFRESH method. 2421 12. IANA Considerations 2423 12.1. Message Header Field Registrations 2425 The message header fields below are to be added to the Permanent 2426 Message Header Field Registry (see [RFC3864]). 2428 12.1.1. Schedule-Reply 2430 Header field name: Schedule-Reply 2432 Applicable protocol: http 2434 Status: standard 2436 Author/Change controller: IETF 2438 Specification document(s): this specification (Section 8.1) 2440 Related information: none 2442 12.1.2. Schedule-Tag 2444 Header field name: Schedule-Tag 2446 Applicable protocol: http 2448 Status: standard 2450 Author/Change controller: IETF 2452 Specification document(s): this specification (Section 8.2) 2454 Related information: none 2456 12.1.3. If-Schedule-Tag-Match 2458 Header field name: If-Schedule-Tag-Match 2460 Applicable protocol: http 2462 Status: standard 2464 Author/Change controller: IETF 2466 Specification document(s): this specification (Section 8.3) 2468 Related information: none 2470 12.2. iCalendar Property Parameter Registrations 2472 The following iCalendar property parameters are to be added to the 2473 iCalendar Property Parameter Registry defined in Section 8.3.3 of 2474 [RFC5545]. 2476 +---------------------+---------+-----------------------+ 2477 | Parameter | Status | Reference | 2478 +---------------------+---------+-----------------------+ 2479 | SCHEDULE-AGENT | Current | RFC XXXX, Section 7.1 | 2480 | | | | 2481 | SCHEDULE-STATUS | Current | RFC XXXX, Section 7.3 | 2482 | | | | 2483 | SCHEDULE-FORCE-SEND | Current | RFC XXXX, Section 7.2 | 2484 +---------------------+---------+-----------------------+ 2486 12.3. iCalendar REQUEST-STATUS Value Registrations 2488 The following iCalendar "REQUEST-STATUS" values are to be added to 2489 the iCalendar REQUEST-STATUS Value Registry defined in Section 7.3 of 2490 [RFC5546]. 2492 +-------------+---------+---------------------------+ 2493 | Status Code | Status | Reference | 2494 +-------------+---------+---------------------------+ 2495 | 1.0 | Current | RFC XXXX, Section 3.2.9.1 | 2496 | | | | 2497 | 1.1 | Current | RFC XXXX, Section 3.2.9.2 | 2498 | | | | 2499 | 1.2 | Current | RFC XXXX, Section 3.2.9.3 | 2500 +-------------+---------+---------------------------+ 2502 12.4. Additional iCalendar Elements Registries 2504 This specification adds two new IANA registries for iCalendar 2505 elements. Additional codes MAY be used, provided the process 2506 described in Section 8.2.1 of [RFC5545] is used to register them. 2508 12.4.1. Schedule Agent Values Registry 2510 The following table has been used to initialize the schedule agent 2511 values registry. 2513 +----------------+---------+-----------------------+ 2514 | Schedule Agent | Status | Reference | 2515 +----------------+---------+-----------------------+ 2516 | SERVER | Current | RFC XXXX, Section 7.1 | 2517 | | | | 2518 | CLIENT | Current | RFC XXXX, Section 7.1 | 2519 | | | | 2520 | NONE | Current | RFC XXXX, Section 7.1 | 2521 +----------------+---------+-----------------------+ 2523 12.4.2. Schedule Force Send Values Registry 2525 The following table has been used to initialize the schedule send 2526 values registry. 2528 +---------------------+---------+-----------------------+ 2529 | Schedule Force Send | Status | Reference | 2530 +---------------------+---------+-----------------------+ 2531 | REQUEST | Current | RFC XXXX, Section 7.2 | 2532 | | | | 2533 | REPLY | Current | RFC XXXX, Section 7.2 | 2534 +---------------------+---------+-----------------------+ 2536 13. Acknowledgements 2538 The authors would like to thank the following individuals for 2539 contributing their ideas and support for writing this specification: 2540 Mike Douglass, Lisa Dusseault, Red Dutta, Jacob Farkas, Jeffrey 2541 Harris, Helge Hess, Eliot Lear, Andrew McMillan, Alexey Melnikov, 2542 Arnaud Quillaud, Julian F. Reschke, Wilfredo Sanchez Vega, Simon 2543 Vaillancourt. 2545 The authors would also like to thank the Calendaring and Scheduling 2546 Consortium for advice with this specification, and for organizing 2547 interoperability testing events to help refine it. 2549 14. References 2551 14.1. Normative References 2553 [RFC2119] Bradner, S., "Key words for use in RFCs to 2554 Indicate Requirement Levels", BCP 14, 2555 RFC 2119, March 1997. 2557 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, 2558 H., Masinter, L., Leach, P., and T. Berners- 2559 Lee, "Hypertext Transfer Protocol -- 2560 HTTP/1.1", RFC 2616, June 1999. 2562 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., 2563 Lawrence, S., Leach, P., Luotonen, A., and L. 2564 Stewart, "HTTP Authentication: Basic and 2565 Digest Access Authentication", RFC 2617, 2566 June 1999. 2568 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2569 May 2000. 2571 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. 2572 Whitehead, "Web Distributed Authoring and 2573 Versioning (WebDAV) Access Control Protocol", 2574 RFC 3744, May 2004. 2576 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, 2577 "Registration Procedures for Message Header 2578 Fields", BCP 90, RFC 3864, September 2004. 2580 [RFC4791] Daboo, C., Desruisseaux, B., and L. 2581 Dusseault, "Calendaring Extensions to WebDAV 2582 (CalDAV)", RFC 4791, March 2007. 2584 [RFC4918] Dusseault, L., "HTTP Extensions for Web 2585 Distributed Authoring and Versioning 2586 (WebDAV)", RFC 4918, June 2007. 2588 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF 2589 for Syntax Specifications: ABNF", STD 68, 2590 RFC 5234, January 2008. 2592 [RFC5545] Desruisseaux, B., "Internet Calendaring and 2593 Scheduling Core Object Specification 2594 (iCalendar)", RFC 5545, September 2009. 2596 [RFC5546] Daboo, C., "iCalendar Transport-Independent 2597 Interoperability Protocol (iTIP)", RFC 5546, 2598 December 2009. 2600 [RFC6125] Saint-Andre, P. and J. Hodges, 2601 "Representation and Verification of Domain- 2602 Based Application Service Identity within 2603 Internet Public Key Infrastructure Using 2604 X.509 (PKIX) Certificates in the Context of 2605 Transport Layer Security (TLS)", RFC 6125, 2606 March 2011. 2608 [W3C.REC-xml-20081126] Yergeau, F., Paoli, J., Sperberg-McQueen, C., 2609 Maler, E., and T. Bray, "Extensible Markup 2610 Language (XML) 1.0 (Fifth Edition)", World 2611 Wide Web Consortium Recommendation REC-xml- 2612 20081126, November 2008, 2613 . 2615 14.2. Informative References 2617 [RFC6047] Melnikov, A., "iCalendar Message-Based 2618 Interoperability Protocol (iMIP)", RFC 6047, 2619 December 2010. 2621 Appendix A. Scheduling Privileges Summary 2623 A.1. Scheduling Inbox Privileges 2625 The following tables specify which scheduling privileges grant the 2626 right to a calendar user to deliver a scheduling message to the 2627 scheduling Inbox collection of another calendar user. The 2628 appropriate behavior depends on the calendar component type as well 2629 as the scheduling "METHOD" specified in the scheduling message. 2631 +--------------------------------+ 2632 | METHOD for VEVENT and VTODO | 2633 +-----------------------------+---------+-------+-----+--------+ 2634 | Scheduling Inbox Privilege | REQUEST | REPLY | ADD | CANCEL | 2635 +-----------------------------+---------+-------+-----+--------+ 2636 | schedule-deliver | * | * | * | * | 2637 | schedule-deliver-invite | * | | * | * | 2638 | schedule-deliver-reply | | * | | | 2639 | schedule-query-freebusy | | | | | 2640 +-----------------------------+---------+-------+-----+--------+ 2642 +----------------------+ 2643 | METHOD for VFREEBUSY | 2644 +-----------------------------+----------------------+ 2645 | Scheduling Inbox Privilege | REQUEST | 2646 +-----------------------------+----------------------+ 2647 | schedule-deliver | * | 2648 | schedule-deliver-invite | | 2649 | schedule-deliver-reply | | 2650 | schedule-query-freebusy | * | 2651 +-----------------------------+----------------------+ 2653 A.2. Scheduling Outbox Privileges 2655 The following tables specify which scheduling privileges grant the 2656 right to a calendar user to perform busy time information requests 2657 and to submit scheduling messages to other calendar users as the 2658 result of a scheduling operation. The appropriate behavior depends 2659 on the calendar component type as well as the scheduling "METHOD" 2660 specified in the scheduling message. 2662 +--------------------------------+ 2663 | METHOD for VEVENT and VTODO | 2664 +-----------------------------+---------+-------+-----+--------+ 2665 | Scheduling Outbox Privilege | REQUEST | REPLY | ADD | CANCEL | 2666 +-----------------------------+---------+-------+-----+--------+ 2667 | schedule-send | * | * | * | * | 2668 | schedule-send-invite | * | | * | * | 2669 | schedule-send-reply | | * | | | 2670 | schedule-send-freebusy | | | | | 2671 +-----------------------------+---------+-------+-----+--------+ 2673 +----------------------+ 2674 | METHOD for VFREEBUSY | 2675 +-----------------------------+----------------------+ 2676 | Scheduling Outbox Privilege | REQUEST | 2677 +-----------------------------+----------------------+ 2678 | schedule-send | * | 2679 | schedule-send-invite | | 2680 | schedule-send-reply | | 2681 | schedule-send-freebusy | * | 2682 +-----------------------------+----------------------+ 2684 Appendix B. Example Scheduling Operations 2686 This section describes some example scheduling operations that give a 2687 general idea of how scheduling is carried out between CalDAV clients 2688 and servers from the perspective of meeting Organizers and Attendees. 2690 The server is assumed to be hosted in the "example.com" domain, and 2691 users whose email address is at the "example.com" domain are assumed 2692 to be hosted by the server. In addition, the email addresses in the 2693 "example.net" domain are also valid email addresses for calendar 2694 users hosted by the server. Calendar users with an email address at 2695 the "example.org" domain are assumed to not be hosted by the server. 2697 In the following examples the requests and responses are incomplete 2698 and are only for illustrative purposes. In particular, HTTP 2699 authentication headers and behaviors are not shown, even though they 2700 are required in normal operation. 2702 B.1. Example: Organizer Inviting Multiple Attendees 2704 In the following example, Cyrus invites Wilfredo, Bernard and Mike to 2705 a single instance event by simply creating a new scheduling object 2706 resource in one of his calendar collections by using the PUT method. 2708 >> Request << 2710 PUT /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 2711 Host: cal.example.com 2712 Content-Type: text/calendar; charset="utf-8" 2713 Content-Length: xxxx 2714 If-None-Match: * 2716 BEGIN:VCALENDAR 2717 VERSION:2.0 2718 PRODID:-//Example Corp.//CalDAV Client//EN 2719 BEGIN:VEVENT 2720 UID:9263504FD3AD 2721 SEQUENCE:0 2722 DTSTAMP:20090602T185254Z 2723 DTSTART:20090602T160000Z 2724 DTEND:20090602T170000Z 2725 TRANSP:OPAQUE 2726 SUMMARY:Lunch 2727 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 2728 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 2729 mailto:cyrus@example.com 2730 ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT 2731 =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@ 2732 example.com 2733 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 2734 NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex 2735 ample.net 2736 ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A 2737 CTION;RSVP=TRUE:mailto:mike@example.org 2738 END:VEVENT 2739 END:VCALENDAR 2741 >> Response << 2743 HTTP/1.1 201 Created 2744 Content-Length: 0 2745 Date: Tue, 02 Jun 2009 18:52:54 GMT 2746 Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT 2747 ETag: "d85561cfe74a4e785eb4639451b434fb" 2748 Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" 2750 Once the event creation has been completed, Cyrus's client will 2751 retrieve the event back from the server to get the schedule status of 2752 each Attendee, as well as record the Schedule-Tag value for future 2753 use. In this example, the server reports that a scheduling message 2754 was delivered to Wilfredo, a scheduling message is still pending for 2755 Bernard, and the server was unable to deliver a scheduling message to 2756 Mike. 2758 >> Request << 2760 GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 2761 Host: cal.example.com 2763 >> Response << 2765 HTTP/1.1 200 OK 2766 Date: Tue, 02 Jun 2009 18:52:58 GMT 2767 Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT 2768 ETag: "eb897deabc8939589da116714bc99265" 2769 Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" 2770 Content-Type: text/calendar; charset="utf-8" 2771 Content-Length: xxxx 2773 BEGIN:VCALENDAR 2774 VERSION:2.0 2775 PRODID:-//Example Corp.//CalDAV Server//EN 2776 BEGIN:VEVENT 2777 UID:9263504FD3AD 2778 SEQUENCE:0 2779 DTSTAMP:20090602T185300Z 2780 DTSTART:20090602T160000Z 2781 DTEND:20090602T170000Z 2782 TRANSP:OPAQUE 2783 SUMMARY:Lunch 2784 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 2785 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 2786 mailto:cyrus@example.com 2787 ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT 2788 =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS= 2789 1.2:mailto:wilfredo@e 2790 xample.com 2791 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 2792 NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS= 2793 1.0:mailto:bernard@example.net 2794 ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A 2795 CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org 2796 END:VEVENT 2797 END:VCALENDAR 2799 B.2. Example: Attendee Receiving an Invitation 2801 In the following example, Wilfredo's client retrieves and deletes the 2802 new scheduling message that appeared in his scheduling Inbox 2803 collection after the server automatically processed it and created a 2804 new scheduling object resource in his default calendar collection. 2806 >> Request << 2808 GET /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1 2809 Host: cal.example.com 2811 >> Response << 2813 HTTP/1.1 200 OK 2814 Date: Tue, 02 Jun 2009 18:59:58 GMT 2815 Last-Modified: Tue, 02 Jun 2009 18:59:58 GMT 2816 ETag: "da116714bc9926c89395895eb897deab" 2817 Content-Type: text/calendar; charset="utf-8" 2818 Content-Length: xxxx 2820 BEGIN:VCALENDAR 2821 VERSION:2.0 2822 PRODID:-//Example Corp.//CalDAV Server//EN 2823 METHOD:REQUEST 2824 BEGIN:VEVENT 2825 UID:9263504FD3AD 2826 SEQUENCE:0 2827 DTSTAMP:20090602T185254Z 2828 DTSTART:20090602T160000Z 2829 DTEND:20090602T170000Z 2830 TRANSP:OPAQUE 2831 SUMMARY:Lunch 2832 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 2833 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 2834 mailto:cyrus@example.com 2835 ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT 2836 =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@ 2837 example.com 2838 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 2839 NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex 2840 ample.net 2841 ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A 2842 CTION;RSVP=TRUE:mailto:mike@example.org 2843 END:VEVENT 2844 END:VCALENDAR 2846 >> Request << 2848 DELETE /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1 2849 Host: cal.example.com 2850 >> Response << 2852 HTTP/1.1 204 No Content 2853 Date: Tue, 02 Jun 2009 20:40:36 GMT 2855 B.3. Example: Attendee Replying to an Invitation 2857 In the following example, Wilfredo accepts Cyrus's invitation and 2858 sets an alarm reminder on the event. It uses the If-Schedule-Tag- 2859 Match precondition behavior to ensure it does not overwrite any 2860 significant changes from the organizer that might have occurred after 2861 it retrieved the initial resource data. 2863 >> Request << 2865 PUT /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1 2866 Host: cal.example.com 2867 If-Schedule-Tag-Match: "e78f23ed-0188-4bab-938d-2aeb3324c7e8" 2868 Content-Type: text/calendar; charset="utf-8" 2869 Content-Length: xxxx 2871 BEGIN:VCALENDAR 2872 VERSION:2.0 2873 PRODID:-//Example Corp.//CalDAV Client//EN 2874 BEGIN:VEVENT 2875 UID:9263504FD3AD 2876 SEQUENCE:0 2877 DTSTAMP:20090602T185254Z 2878 DTSTART:20090602T160000Z 2879 DTEND:20090602T170000Z 2880 TRANSP:OPAQUE 2881 SUMMARY:Lunch 2882 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 2883 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 2884 mailto:cyrus@example.com 2885 ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT 2886 =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam 2887 ple.com 2888 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 2889 NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex 2890 ample.net 2891 ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A 2892 CTION;RSVP=TRUE:mailto:mike@example.org 2893 BEGIN:VALARM 2894 TRIGGER:-PT15M 2895 ACTION:DISPLAY 2896 DESCRIPTION:Reminder 2897 END:VALARM 2898 END:VEVENT 2899 END:VCALENDAR 2901 >> Response << 2903 HTTP/1.1 200 OK 2904 Content-Length: 0 2905 Date: Tue, 02 Jun 2009 18:57:54 GMT 2906 Last-Modified: Tue, 02 Jun 2009 18:57:54 GMT 2907 ETag: "eb4639451b434fbd85561cfe74a4e785" 2908 Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41" 2910 Once the event modification has been completed, Wilfredo's client 2911 will retrieve the event back from the server to get the schedule 2912 status of the Organizer. 2914 >> Request << 2916 GET /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1 2917 Host: cal.example.com 2918 >> Response << 2920 HTTP/1.1 200 OK 2921 Date: Tue, 02 Jun 2009 19:03:03 GMT 2922 Last-Modified: Tue, 02 Jun 2009 19:02:21 GMT 2923 ETag: "5eb897deabda116714bc9926c8939589" 2924 Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41" 2925 Content-Type: text/calendar; charset="utf-8" 2926 Content-Length: xxxx 2928 BEGIN:VCALENDAR 2929 VERSION:2.0 2930 PRODID:-//Example Corp.//CalDAV Client//EN 2931 BEGIN:VEVENT 2932 UID:9263504FD3AD 2933 SEQUENCE:0 2934 DTSTAMP:20090602T190221Z 2935 DTSTART:20090602T160000Z 2936 DTEND:20090602T170000Z 2937 TRANSP:OPAQUE 2938 SUMMARY:Lunch 2939 ORGANIZER;CN="Cyrus Daboo";SCHEDULE-STATUS=1.2:mailto:cyrus@ex 2940 ample.com 2941 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 2942 mailto:cyrus@example.com 2943 ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT 2944 =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam 2945 ple.com 2946 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 2947 NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex 2948 ample.net 2949 ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A 2950 CTION;RSVP=TRUE:mailto:mike@example.org 2951 BEGIN:VALARM 2952 TRIGGER:-PT15M 2953 ACTION:DISPLAY 2954 DESCRIPTION:Reminder 2955 END:VALARM 2956 END:VEVENT 2957 END:VCALENDAR 2959 B.4. Example: Organizer Receiving a Reply to an Invitation 2961 On reception of Wilfredo's reply, Cyrus's server will automatically 2962 update Cyrus's scheduling object resource, make Wilfredo's scheduling 2963 message available in Cyrus's scheduling Inbox collection, and deliver 2964 an updated scheduling message to Bernard to share Wilfredo's updated 2965 participation status. In this example, Cyrus's client retrieves and 2966 deletes this scheduling message in his scheduling Inbox collection. 2968 >> Request << 2970 GET /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1 2971 Host: cal.example.com 2973 >> Response << 2975 HTTP/1.1 200 OK 2976 Date: Tue, 02 Jun 2009 19:05:02 GMT 2977 Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT 2978 ETag: "9265eb897deabc8939589da116714bc9" 2979 Content-Type: text/calendar; charset="utf-8" 2980 Content-Length: xxxx 2982 BEGIN:VCALENDAR 2983 VERSION:2.0 2984 PRODID:-//Example Corp.//CalDAV Server//EN 2985 METHOD:REPLY 2986 BEGIN:VEVENT 2987 UID:9263504FD3AD 2988 SEQUENCE:0 2989 DTSTAMP:20090602T185754Z 2990 DTSTART:20090602T160000Z 2991 DTEND:20090602T170000Z 2992 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 2993 ATTENDEE;CN="Wilfredo Sanchez Vega";PARTSTAT=ACCEPTED:mailto:w 2994 ilfredo@example.com 2995 REQUEST-STATUS:2.0;Success 2996 END:VEVENT 2997 END:VCALENDAR 2999 >> Request << 3001 DELETE /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1 3002 Host: cal.example.com 3004 >> Response << 3006 HTTP/1.1 204 No Content 3007 Date: Tue, 02 Jun 2009 19:05:05 GMT 3009 Cyrus's client then retrieves the event back from the server with 3010 Wilfredo's updated participation status. 3012 >> Request << 3014 GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 3015 Host: cal.example.com 3017 >> Response << 3019 HTTP/1.1 200 OK 3020 Date: Tue, 02 Jun 2009 19:05:02 GMT 3021 Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT 3022 ETag: "eb897deabc8939589da116714bc99265" 3023 Schedule-Tag: "132cab27-1fe3-67ab-de13-abd348d1dee3" 3024 Content-Type: text/calendar; charset="utf-8" 3025 Content-Length: xxxx 3027 BEGIN:VCALENDAR 3028 VERSION:2.0 3029 PRODID:-//Example Corp.//CalDAV Server//EN 3030 BEGIN:VEVENT 3031 UID:9263504FD3AD 3032 SEQUENCE:0 3033 DTSTAMP:20090602T190420Z 3034 DTSTART:20090602T160000Z 3035 DTEND:20090602T170000Z 3036 TRANSP:OPAQUE 3037 SUMMARY:Lunch 3038 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3039 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 3040 mailto:cyrus@example.com 3041 ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT 3042 =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=2.0: 3043 mailto:wilfredo@example.com 3044 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 3045 NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1 3046 .0:mailto:bernard@example.net 3047 ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A 3048 CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org 3049 END:VEVENT 3050 END:VCALENDAR 3052 B.5. Example: Organizer Requesting Busy Time Information 3054 In this example, Cyrus requests the busy time information of 3055 Wilfredo, Bernard and Mike. 3057 >> Request << 3059 POST /home/cyrus/calendars/outbox/ HTTP/1.1 3060 Host: cal.example.com 3061 Content-Type: text/calendar; charset="utf-8" 3062 Content-Length: xxxx 3064 BEGIN:VCALENDAR 3065 VERSION:2.0 3066 PRODID:-//Example Corp.//CalDAV Client//EN 3067 METHOD:REQUEST 3068 BEGIN:VFREEBUSY 3069 UID:4FD3AD926350 3070 DTSTAMP:20090602T190420Z 3071 DTSTART:20090602T000000Z 3072 DTEND:20090604T000000Z 3073 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3074 ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com 3075 ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net 3076 ATTENDEE;CN="Mike Douglass":mailto:mike@example.org 3077 END:VFREEBUSY 3078 END:VCALENDAR 3080 >> Response << 3082 HTTP/1.1 200 OK 3083 Date: Tue, 02 Jun 2009 20:07:34 GMT 3084 Content-Type: application/xml; charset="utf-8" 3085 Content-Length: xxxx 3087 3088 3090 3091 3092 mailto:wilfredo@example.com 3093 3094 2.0;Success 3095 BEGIN:VCALENDAR 3096 VERSION:2.0 3097 PRODID:-//Example Corp.//CalDAV Server//EN 3098 METHOD:REPLY 3099 BEGIN:VFREEBUSY 3100 UID:4FD3AD926350 3101 DTSTAMP:20090602T200733Z 3102 DTSTART:20090602T000000Z 3103 DTEND:20090604T000000Z 3104 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3105 ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com 3106 FREEBUSY;FBTYPE=BUSY:20090602T110000Z/20090602T120000Z 3107 FREEBUSY;FBTYPE=BUSY:20090603T170000Z/20090603T180000Z 3108 END:VFREEBUSY 3109 END:VCALENDAR 3110 3111 3112 3113 3114 mailto:bernard@example.net 3115 3116 2.0;Success 3117 BEGIN:VCALENDAR 3118 VERSION:2.0 3119 PRODID:-//Example Corp.//CalDAV Server//EN 3120 METHOD:REPLY 3121 BEGIN:VFREEBUSY 3122 UID:4FD3AD926350 3123 DTSTAMP:20090602T200733Z 3124 DTSTART:20090602T000000Z 3125 DTEND:20090604T000000Z 3126 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3127 ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net 3128 FREEBUSY;FBTYPE=BUSY:20090602T150000Z/20090602T160000Z 3129 FREEBUSY;FBTYPE=BUSY:20090603T090000Z/20090603T100000Z 3130 FREEBUSY;FBTYPE=BUSY:20090603T180000Z/20090603T190000Z 3131 END:VFREEBUSY 3132 END:VCALENDAR 3133 3134 3135 3136 3137 mailto:mike@example.org 3138 3139 3.7;Invalid calendar user 3140 3141 3143 B.6. Example: User Attempting to Invite Attendee on behalf of Organizer 3145 In the following example, Cyrus attempts to create, on behalf of 3146 Wilfredo, an event with Bernard specified as an Attendee. The 3147 request fails since Wilfredo didn't grant Cyrus the right to invite 3148 other calendar users on his behalf. 3150 >> Request << 3152 PUT /home/wilfredo/calendars/work/def456.ics HTTP/1.1 3153 Host: cal.example.com 3154 Content-Type: text/calendar; charset="utf-8" 3155 Content-Length: xxxx 3156 If-None-Match: * 3158 BEGIN:VCALENDAR 3159 VERSION:2.0 3160 PRODID:-//Example Corp.//CalDAV Client//EN 3161 BEGIN:VEVENT 3162 UID:3504F926D3AD 3163 SEQUENCE:0 3164 DTSTAMP:20090602T190221Z 3165 DTSTART:20090602T230000Z 3166 DTEND:20090603T000000Z 3167 TRANSP:OPAQUE 3168 SUMMARY:Dinner 3169 ORGANIZER;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com 3170 ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT=A 3171 CCEPTED:mailto:wilfredo@example.com 3172 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=NE 3173 EDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl 3174 e.net 3175 END:VEVENT 3176 END:VCALENDAR 3178 >> Response << 3180 HTTP/1.1 403 Forbidden 3181 Content-Type: application/xml; charset="utf-8" 3182 Content-Length: xxxx 3184 3185 3186 3187 3188 /home/wilfredo/calendars/outbox/ 3189 3190 3191 3192 3194 B.7. Example: Attendee Declining an Instance of a Recurring Event 3196 In the following example, Bernard declines the second recurrence 3197 instance of a daily recurring event he's been invited to by Cyrus. 3199 >> Request << 3201 PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1 3202 Host: cal.example.com 3203 Content-Type: text/calendar; charset="utf-8" 3204 Content-Length: xxxx 3205 If-Schedule-Tag-Match: "7775FB30-7534-489E-A79A-0EA147B933EB" 3207 BEGIN:VCALENDAR 3208 VERSION:2.0 3209 PRODID:-//Example Corp.//CalDAV Client//EN 3210 BEGIN:VTIMEZONE 3211 TZID:America/Montreal 3212 BEGIN:STANDARD 3213 DTSTART:20071104T020000 3214 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3215 TZNAME:EST 3216 TZOFFSETFROM:-0400 3217 TZOFFSETTO:-0500 3218 END:STANDARD 3219 BEGIN:DAYLIGHT 3220 DTSTART:20070311T020000 3221 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3222 TZNAME:EDT 3223 TZOFFSETFROM:-0500 3224 TZOFFSETTO:-0400 3225 END:DAYLIGHT 3226 END:VTIMEZONE 3227 BEGIN:VEVENT 3228 UID:9263504FD3AD 3229 SEQUENCE:0 3230 DTSTAMP:20090602T185254Z 3231 DTSTART;TZID=America/Montreal:20090601T150000 3232 DTEND;TZID=America/Montreal:20090601T160000 3233 RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5 3234 TRANSP:OPAQUE 3235 SUMMARY:Review Internet-Draft 3236 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3237 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 3238 mailto:cyrus@example.com 3239 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 3240 ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl 3241 e.net 3243 END:VEVENT 3244 BEGIN:VEVENT 3245 UID:9263504FD3AD 3246 SEQUENCE:0 3247 DTSTAMP:20090603T183823Z 3248 RECURRENCE-ID;TZID=America/Montreal:20090602T150000 3249 DTSTART;TZID=America/Montreal:20090602T150000 3250 DTEND;TZID=America/Montreal:20090602T160000 3251 TRANSP:TRANSPARENT 3252 SUMMARY:Review Internet-Draft 3253 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3254 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 3255 mailto:cyrus@example.com 3256 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 3257 DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl 3258 e.net 3259 END:VEVENT 3260 END:VCALENDAR 3262 >> Response << 3264 HTTP/1.1 200 OK 3265 Content-Length: 0 3266 Date: Tue, 02 Jun 2009 18:52:54 GMT 3267 Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT 3268 ETag: "d85561cfe74a4e785eb4639451b434fb" 3269 Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" 3271 Bernard's participation status update will cause his server to 3272 deliver a scheduling message to Cyrus. Cyrus's client will find the 3273 following reply message from Bernard in Cyrus's scheduling Inbox 3274 collection: 3276 >> Request << 3278 GET /home/cyrus/calendars/inbox/9263504FD3AD.ics HTTP/1.1 3279 Host: cal.example.com 3280 >> Response << 3282 HTTP/1.1 200 OK 3283 Date: Tue, 02 Jun 2009 18:52:58 GMT 3284 Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT 3285 ETag: "eb897deabc8939589da116714bc99265" 3286 Content-Type: text/calendar; charset="utf-8" 3287 Content-Length: xxxx 3289 BEGIN:VCALENDAR 3290 VERSION:2.0 3291 PRODID:-//Example Corp.//CalDAV Client//EN 3292 METHOD:REPLY 3293 BEGIN:VTIMEZONE 3294 TZID:America/Montreal 3295 BEGIN:STANDARD 3296 DTSTART:20071104T020000 3297 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3298 TZNAME:EST 3299 TZOFFSETFROM:-0400 3300 TZOFFSETTO:-0500 3301 END:STANDARD 3302 BEGIN:DAYLIGHT 3303 DTSTART:20070311T020000 3304 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3305 TZNAME:EDT 3306 TZOFFSETFROM:-0500 3307 TZOFFSETTO:-0400 3308 END:DAYLIGHT 3309 END:VTIMEZONE 3310 BEGIN:VEVENT 3311 UID:9263504FD3AD 3312 SEQUENCE:0 3313 DTSTAMP:20090603T183823Z 3314 RECURRENCE-ID;TZID=America/Montreal:20090602T150000 3315 DTSTART;TZID=America/Montreal:20090602T150000 3316 DTEND;TZID=America/Montreal:20090602T160000 3317 SUMMARY:Review Internet-Draft 3318 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3319 ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED: 3320 mailto:bernard@example.net 3321 REQUEST-STATUS:2.0;Success 3322 END:VEVENT 3323 END:VCALENDAR 3325 B.8. Example: Attendee Removing an Instance of a Recurring Event 3327 In the following example, Bernard removes from his calendar the third 3328 recurrence instance of a daily recurring event he's been invited to 3329 by Cyrus. This is accomplished by the addition of an "EXDATE" 3330 property to the scheduling object resource stored by Bernard. 3332 >> Request << 3334 PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1 3335 Host: cal.example.com 3336 Content-Type: text/calendar; charset="utf-8" 3337 Content-Length: xxxx 3338 If-Schedule-Tag-Match: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" 3340 BEGIN:VCALENDAR 3341 VERSION:2.0 3342 PRODID:-//Example Corp.//CalDAV Client//EN 3343 BEGIN:VTIMEZONE 3344 TZID:America/Montreal 3345 BEGIN:STANDARD 3346 DTSTART:20071104T020000 3347 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3348 TZNAME:EST 3349 TZOFFSETFROM:-0400 3350 TZOFFSETTO:-0500 3351 END:STANDARD 3352 BEGIN:DAYLIGHT 3353 DTSTART:20070311T020000 3354 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3355 TZNAME:EDT 3356 TZOFFSETFROM:-0500 3357 TZOFFSETTO:-0400 3358 END:DAYLIGHT 3359 END:VTIMEZONE 3360 BEGIN:VEVENT 3361 UID:9263504FD3AD 3362 SEQUENCE:0 3363 DTSTAMP:20090602T185254Z 3364 DTSTART;TZID=America/Montreal:20090601T150000 3365 DTEND;TZID=America/Montreal:20090601T160000 3366 RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5 3367 EXDATE;TZID=America/Montreal:20090603T150000 3368 TRANSP:OPAQUE 3369 SUMMARY:Review Internet-Draft 3370 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3371 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 3372 mailto:cyrus@example.com 3374 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 3375 ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl 3376 e.net 3377 END:VEVENT 3378 BEGIN:VEVENT 3379 UID:9263504FD3AD 3380 SEQUENCE:0 3381 DTSTAMP:20090603T183823Z 3382 RECURRENCE-ID;TZID=America/Montreal:20090602T150000 3383 DTSTART;TZID=America/Montreal:20090602T150000 3384 DTEND;TZID=America/Montreal:20090602T160000 3385 TRANSP:TRANSPARENT 3386 SUMMARY:Review Internet-Draft 3387 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3388 ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: 3389 mailto:cyrus@example.com 3390 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= 3391 DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl 3392 e.net 3393 END:VEVENT 3394 END:VCALENDAR 3396 Bernard's deletion of a recurrence instance will cause his server to 3397 deliver a scheduling message to Cyrus. Cyrus's client will find the 3398 following reply message from Bernard in Cyrus's scheduling Inbox 3399 collection: 3401 >> Request << 3403 GET /home/cyrus/calendars/inbox/6504923FD3AD.ics HTTP/1.1 3404 Host: cal.example.com 3405 >> Response << 3407 HTTP/1.1 200 OK 3408 Date: Tue, 02 Jun 2009 18:52:58 GMT 3409 Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT 3410 ETag: "eb897deabc8939589da116714bc99265" 3411 Content-Type: text/calendar; charset="utf-8" 3412 Content-Length: xxxx 3414 BEGIN:VCALENDAR 3415 VERSION:2.0 3416 PRODID:-//Example Corp.//CalDAV Client//EN 3417 METHOD:REPLY 3418 BEGIN:VTIMEZONE 3419 TZID:America/Montreal 3420 BEGIN:STANDARD 3421 DTSTART:20071104T020000 3422 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU 3423 TZNAME:EST 3424 TZOFFSETFROM:-0400 3425 TZOFFSETTO:-0500 3426 END:STANDARD 3427 BEGIN:DAYLIGHT 3428 DTSTART:20070311T020000 3429 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU 3430 TZNAME:EDT 3431 TZOFFSETFROM:-0500 3432 TZOFFSETTO:-0400 3433 END:DAYLIGHT 3434 END:VTIMEZONE 3435 BEGIN:VEVENT 3436 UID:9263504FD3AD 3437 SEQUENCE:0 3438 DTSTAMP:20090603T183823Z 3439 RECURRENCE-ID;TZID=America/Montreal:20090603T150000 3440 DTSTART;TZID=America/Montreal:20090603T150000 3441 DTEND;TZID=America/Montreal:20090603T160000 3442 SUMMARY:Review Internet-Draft 3443 ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com 3444 ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED: 3445 mailto:bernard@example.net 3446 REQUEST-STATUS:2.0;Success 3447 END:VEVENT 3448 END:VCALENDAR 3450 Appendix C. Changes (to be removed by RFC Editor prior to publication) 3452 C.1. Changes in -12 3454 a. AppDir: More reworking of various sections for clarity. 3456 b. AppDir: Removed terminology items defined in other specs. 3458 c. AppDir: Now updates 5546. 3460 d. AppDir: MAY instead of can in 3.2.10.1/2. 3462 e. Fixed inconsistent whitespace in examples. 3464 f. IESG: added x-name and iana-token references in ABNF. 3466 g. IESG: clarified that allowed attendee changes are in addition to 3467 other pre-conditions. 3469 h. IESG: added privacy statement to address potential "leakage" of 3470 private data via scheduling messages or error responses. 3472 i. IESG: scrubbed through some RFC2119 language to avoid unnecessary 3473 use and repetition. 3475 C.2. Changes in -11 3477 a. Major editorial changes to remove "cruft" that built up over 3478 time, to reduce repetitive statements, and to improve clarity. 3480 b. SecDir: Added "Preventing Denial of Service Attacks" security 3481 sub-section. 3483 c. SecDir: Added reference to RFC6125 and clarified how clients and 3484 server authenticate each other. 3486 d. SecDir: Added "Mitigation of iTIP Threats" security sub-section. 3488 e. SecDir: Added new text to privacy sub-section. 3490 f. Fixed some XML examples. 3492 C.3. Changes in -10 3494 a. Updated to RFC 6047 reference. 3496 b. Various minor clarifications to behavior and terminology done. 3498 c. Clarified that Inbox/Outbox are the server's responsibility to 3499 create. 3501 d. Changed MAY to SHOULD for server rejecting organizer PARTSTAT 3502 changes of attendees. 3504 e. Allow COMPLETED as a valid attendee change. 3506 f. Allow SCHEDULE-STATUS as a valid attendee change on SCHEDULE- 3507 AGENT=CLIENT attendee properties. 3509 g. COPY or MOVE on a calendar collection now declared to be 3510 undefined. 3512 h. Changed precondition error codes from 409 to 403. 3514 i. Clarified that rules 5546 must be used when server processes 3515 incoming scheduling messages. 3517 j. default-calendar-delete-allowed -> default-calendar-needed. 3519 k. Clarified that SCHEDULE-AGENT must be the same on all matching 3520 properties. 3522 l. Added more text justifying the need for calendar-user-type 3523 property. 3525 C.4. Changes in -09 3527 a. Fixed some examples. 3529 b. Tweaked XML conventions. 3531 c. Removed description in SCHEDULE-STATUS example values. 3533 d. Tweaked 3.7 and 3.8 SCHEDULE-STATUS description to indicate it 3534 applies to the Organizer as well as Attendee. 3536 e. Updated to RFC 5545 reference. 3538 f. AD Review: clarified text about inbox resource deletion being 3539 acknowledgment of change. 3541 g. AD Review: clarified description of freebusy Outbox POST. 3543 h. AD Review: registered new 1.xx request-status codes and added new 3544 restriction on usage as per iTIP. 3546 i. AD Review: changes SHOULD NOT to MUST NOT for new property 3547 parameters when clients send scheduling messages. 3549 j. AD Review: CALDAV:schedule-calendar-transp now preserved during 3550 COPY. 3552 k. AD Review: changed CALDAV- to CALDAV: in acl descriptions. 3554 l. AD Review: fixed various minor typos. 3556 m. AD Review: Added text to new principal properties to indicate 3557 that if they are not present, then the user is not enabled for 3558 the various scheduling operations. 3560 n. AD Review: clarified use of CALDAV:calendar-data element in 3561 CALDAV:response element. 3563 o. AD Review: made reference to 5545 IANA registry procedures for 3564 the two new element registries. 3566 p. AD Review: Fixed description of B5. example. 3568 q. Fixed SCHEDULE-AGENT/SCHEDULE-STATUS behavior for Attendee 3569 replies. 3571 C.5. Changes in -08 3573 a. Added "Updates 4791". 3575 b. XML conventions changed to match that in CardDAV spec. 3577 c. Reworded child response behavior for Outbox. 3579 d. Reworded "octet size". 3581 e. If-Schedule-Match descriptions changed to remove implication that 3582 it is purely a conditional operation. 3584 f. Schedule-Reply header descriptions generalized to resource 3585 removal rather than just HTTP DELETE. 3587 g. Fixed various examples. 3589 C.6. Changes in -07 3591 a. Restructured document. 3593 b. Clarified that CALDAV:schedule-calendar-transp only applies to 3594 calendar collection. 3596 c. Removed CALDAV:schedule-state property on scheduling messages in 3597 the scheduling Inbox collection. 3599 d. Added conditional requests on scheduling object resources. 3601 e. Added section on handling of PARTSTAT. 3603 f. Added SCHEDULE-FORCE-SEND iCalendar property parameter. 3605 g. Added clarification on child resources in scheduling Outbox 3606 collections. 3608 h. Clarified Attendee changes that server MUST allow, and removed 3609 restrictions on changes that Attendee MUST NOT do. 3611 i. Added Example Scheduling Transactions appendix. 3613 j. Scheduling privileges are no longer required to be non-abstract. 3615 k. Removed handling of REFRESH requests. 3617 l. Removed handling of VJOURNAL components. 3619 m. Completed IANA Considerations section. 3621 n. Added references to RFC3283 and RFC5234. 3623 o. Updated references to iCalendar, iTIP and iMIP. 3625 C.7. Changes in -06 3627 a. Removed distinction between scheduling calendar collections and 3628 basic calendar collections - now just have calendar collections. 3630 b. Clients now "MAY" reload data rather than "SHOULD" reload data. 3632 c. Fixed in examples. 3634 d. Removed CALDAV:attachments-allowed precondition on POST to Outbox 3635 as that is no longer relevant. 3637 e. Added CALDAV:default-calendar-delete-allowed precondition for 3638 DELETE. 3640 f. Relaxed MUST->MAY for Organizer setting PARTSTAT value. 3642 g. Tweaked restrictions on Create/Modify to emphasize that 4791 3643 restrictions also apply. 3645 h. Added comment that 'opaque' is the default when the CALDAV: 3646 schedule-calendar-transp property is not present. 3648 i. Description of Schedule-Reply header changed to reflect that it 3649 is only relevant for Attendees. 3651 j. Minor typos fixed. 3653 C.8. Changes in -05 3655 This draft has changed substantially since the -04 version. The 3656 primary reason for this change was implementation experience from a 3657 number of vendors who implemented products based on the earlier 3658 drafts. Experience showed that the client/server interaction was not 3659 reliable in keeping scheduling messages synchronized between 3660 organizer and attendees. In addition the latency in updates due to 3661 clients being offline proved unacceptable to users. These issues led 3662 to the redesign of this specification to support a server-based 3663 processing model that eliminates all the problems seen previously. 3664 Whilst this adds significant complexity to the server in that it 3665 needs to be a full blown iTIP processing agent, it does remove a lot 3666 of the same complexity from clients, opening up the possibility of 3667 supporting complex scheduling behaviors even with "thin" clients. 3669 In the judgement of the authors, we consider this new specification 3670 to be a substantial improvement over the old one and believe it 3671 represents a stronger protocol that will lead to better 3672 interoperability. 3674 Authors' Addresses 3676 Cyrus Daboo 3677 Apple Inc. 3678 1 Infinite Loop 3679 Cupertino, CA 95014 3680 USA 3682 EMail: cyrus@daboo.name 3683 URI: http://www.apple.com/ 3685 Bernard Desruisseaux 3686 Oracle Corporation 3687 600 Blvd. de Maisonneuve West 3688 Suite 1900 3689 Montreal, QC H3A 3J2 3690 CANADA 3692 EMail: bernard.desruisseaux@oracle.com 3693 URI: http://www.oracle.com/