diff options
Diffstat (limited to 'vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt | 5544 |
1 files changed, 0 insertions, 5544 deletions
diff --git a/vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt b/vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt deleted file mode 100644 index bcb2520f0..000000000 --- a/vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt +++ /dev/null @@ -1,5544 +0,0 @@ - - - -Network Working Group C. Daboo -Internet-Draft Apple Inc. -Updates: 4791 (if approved) B. Desruisseaux -Intended status: Standards Track Oracle -Expires: March 10, 2012 September 7, 2011 - - - CalDAV Scheduling Extensions to WebDAV - draft-desruisseaux-caldav-sched-10 - -Abstract - - This document defines extensions to the CalDAV "calendar-access" - feature to specify a standard way of performing scheduling - transactions with iCalendar-based calendar components. This document - defines the "calendar-auto-schedule" feature of CalDAV. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on March 10, 2012. - -Copyright Notice - - Copyright (c) 2011 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 1] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.4. Notational Conventions . . . . . . . . . . . . . . . . . . 8 - 1.5. XML Namespaces and Processing . . . . . . . . . . . . . . 8 - 2. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 10 - 3. Scheduling Support . . . . . . . . . . . . . . . . . . . . . . 11 - 3.1. Example OPTIONS Request . . . . . . . . . . . . . . . . . 11 - 4. Scheduling Collections . . . . . . . . . . . . . . . . . . . . 12 - 4.1. Scheduling Outbox Collection . . . . . . . . . . . . . . . 12 - 4.2. Scheduling Inbox Collection . . . . . . . . . . . . . . . 13 - 4.3. Calendaring Reports Extensions . . . . . . . . . . . . . . 15 - 5. Scheduling Transactions . . . . . . . . . . . . . . . . . . . 16 - 5.1. Identifying Scheduling Object Resources . . . . . . . . . 16 - 5.2. Handling Scheduling Object Resources . . . . . . . . . . . 16 - 5.2.1. Organizer Scheduling Object Resources . . . . . . . . 16 - 5.2.1.1. Create . . . . . . . . . . . . . . . . . . . . . . 17 - 5.2.1.2. Modify . . . . . . . . . . . . . . . . . . . . . . 18 - 5.2.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . 20 - 5.2.2. Attendee Scheduling Object Resources . . . . . . . . . 20 - 5.2.2.1. Allowed Attendee Changes . . . . . . . . . . . . . 20 - 5.2.2.2. Create . . . . . . . . . . . . . . . . . . . . . . 21 - 5.2.2.3. Modify . . . . . . . . . . . . . . . . . . . . . . 22 - 5.2.2.4. Remove . . . . . . . . . . . . . . . . . . . . . . 23 - 5.2.3. HTTP Methods . . . . . . . . . . . . . . . . . . . . . 24 - 5.2.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 24 - 5.2.3.2. COPY . . . . . . . . . . . . . . . . . . . . . . . 24 - 5.2.3.3. MOVE . . . . . . . . . . . . . . . . . . . . . . . 25 - 5.2.3.4. DELETE . . . . . . . . . . . . . . . . . . . . . . 26 - 5.2.4. Additional Method Preconditions . . . . . . . . . . . 26 - 5.2.4.1. CALDAV:unique-scheduling-object-resource - Precondition . . . . . . . . . . . . . . . . . . . 26 - 5.2.4.2. CALDAV:same-organizer-in-all-components - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 2] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Precondition . . . . . . . . . . . . . . . . . . . 26 - 5.2.4.3. CALDAV:allowed-organizer-scheduling-object-chan - Precondition . . . . . . . . . . . . . . . . . . . 27 - 5.2.4.4. CALDAV:allowed-attendee-scheduling-object-chang - Precondition . . . . . . . . . . . . . . . . . . . 28 - 5.2.5. DTSTAMP and SEQUENCE Properties . . . . . . . . . . . 28 - 5.2.6. Restrict Recurrence Instances Sent to Attendees . . . 28 - 5.2.7. Forcing the Server to Send a Scheduling Message . . . 29 - 6. Processing Incoming Scheduling Messages . . . . . . . . . . . 30 - 6.1. Processing Organizer Requests, Additions, and - Cancellations . . . . . . . . . . . . . . . . . . . . . . 30 - 6.2. Processing Attendee Replies . . . . . . . . . . . . . . . 31 - 6.3. Scheduling Messages as Notifications . . . . . . . . . . . 31 - 6.4. Default Calendar Collection . . . . . . . . . . . . . . . 31 - 6.4.1. Additional Method Preconditions . . . . . . . . . . . 32 - 6.4.1.1. CALDAV:default-calendar-needed Precondition . . . 32 - 6.4.1.2. CALDAV:valid-schedule-default-calendar-URL - Precondition . . . . . . . . . . . . . . . . . . . 33 - 7. Request for Busy Time Information . . . . . . . . . . . . . . 34 - 7.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 34 - 7.2. Additional Method Preconditions . . . . . . . . . . . . . 34 - 7.2.1. DAV:need-privileges Precondition . . . . . . . . . . . 34 - 7.2.2. CALDAV:supported-collection Precondition . . . . . . . 35 - 7.2.3. CALDAV:supported-calendar-data Precondition . . . . . 36 - 7.2.4. CALDAV:valid-calendar-data Precondition . . . . . . . 36 - 7.2.5. CALDAV:valid-scheduling-message Precondition . . . . . 37 - 7.2.6. CALDAV:valid-organizer Precondition . . . . . . . . . 37 - 7.2.7. CALDAV:max-resource-size Precondition . . . . . . . . 38 - 7.3. Response to a POST request . . . . . . . . . . . . . . . . 38 - 8. Avoiding Conflicts when Updating Scheduling Object - Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 8.1. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 - 8.2. DELETE, COPY or MOVE . . . . . . . . . . . . . . . . . . . 42 - 9. Other Scheduling Considerations . . . . . . . . . . . . . . . 44 - 9.1. Attendee Participation Status . . . . . . . . . . . . . . 44 - 9.2. Schedule Status Values . . . . . . . . . . . . . . . . . . 45 - 10. Additional iCalendar Property Parameters . . . . . . . . . . . 49 - 10.1. Schedule Agent Parameter . . . . . . . . . . . . . . . . . 49 - 10.2. Schedule Force Send Parameter . . . . . . . . . . . . . . 50 - 10.3. Schedule Status Parameter . . . . . . . . . . . . . . . . 51 - 11. Additional Message Header Fields . . . . . . . . . . . . . . . 53 - 11.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 53 - 11.2. Schedule-Tag Response Header . . . . . . . . . . . . . . . 53 - 11.3. If-Schedule-Tag-Match Request Header . . . . . . . . . . . 54 - 12. Additional WebDAV Properties . . . . . . . . . . . . . . . . . 55 - 12.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 55 - 12.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 56 - 12.3. CALDAV:schedule-tag Property . . . . . . . . . . . . . . . 57 - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 3] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - 13. Scheduling Access Control . . . . . . . . . . . . . . . . . . 58 - 13.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 58 - 13.1.1. Privileges on Scheduling Inbox Collections . . . . . . 58 - 13.1.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . 58 - 13.1.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . 59 - 13.1.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . 59 - 13.1.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . 59 - 13.1.2. Privileges on Scheduling Outbox Collections . . . . . 59 - 13.1.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . 59 - 13.1.2.2. CALDAV:schedule-send-invite Privilege . . . . . . 60 - 13.1.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . 60 - 13.1.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . 60 - 13.1.3. Aggregation of Scheduling Privileges . . . . . . . . . 60 - 13.2. Additional Principal Properties . . . . . . . . . . . . . 61 - 13.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 61 - 13.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 62 - 13.2.3. CALDAV:calendar-user-address-set Property . . . . . . 62 - 13.2.4. CALDAV:calendar-user-type Property . . . . . . . . . . 63 - 14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 65 - 14.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 65 - 14.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 65 - 14.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 65 - 14.4. CALDAV:request-status XML Element . . . . . . . . . . . . 66 - 15. Security Considerations . . . . . . . . . . . . . . . . . . . 67 - 15.1. Verifying Scheduling Transactions . . . . . . . . . . . . 67 - 15.2. Verifying Busy Time Information Requests . . . . . . . . . 67 - 15.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 68 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 - 16.1. Message Header Field Registrations . . . . . . . . . . . . 69 - 16.1.1. Schedule-Reply . . . . . . . . . . . . . . . . . . . . 69 - 16.1.2. Schedule-Tag . . . . . . . . . . . . . . . . . . . . . 69 - 16.1.3. If-Schedule-Tag-Match . . . . . . . . . . . . . . . . 69 - 16.2. iCalendar Property Parameter Registrations . . . . . . . . 70 - 16.3. iCalendar REQUEST-STATUS Value Registrations . . . . . . . 70 - 16.4. Additional iCalendar Elements Registries . . . . . . . . . 70 - 16.4.1. Schedule Agent Values Registry . . . . . . . . . . . . 70 - 16.4.2. Schedule Force Send Values Registry . . . . . . . . . 71 - 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72 - 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 - 18.1. Normative References . . . . . . . . . . . . . . . . . . . 73 - 18.2. Informative References . . . . . . . . . . . . . . . . . . 74 - Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 75 - A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 75 - A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 75 - Appendix B. Example Scheduling Transactions . . . . . . . . . . . 77 - B.1. Example: Organizer Inviting Multiple Attendees . . . . . . 77 - B.2. Example: Attendee Receiving an Invitation . . . . . . . . 79 - B.3. Example: Attendee Replying to an Invitation . . . . . . . 81 - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 4] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - B.4. Example: Organizer Receiving a Reply to an Invitation . . 83 - B.5. Example: Organizer Requesting Busy Time Information . . . 85 - B.6. Example: User Attempting to Invite Attendee on behalf - of Organizer . . . . . . . . . . . . . . . . . . . . . . . 87 - B.7. Example: Attendee Declining an Instance of a Recurring - Event . . . . . . . . . . . . . . . . . . . . . . . . . . 88 - B.8. Example: Attendee Removing an Instance of a Recurring - Event . . . . . . . . . . . . . . . . . . . . . . . . . . 92 - Appendix C. Changes (to be removed by RFC Editor prior to - publication) . . . . . . . . . . . . . . . . . . . . 95 - C.1. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 95 - C.2. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 95 - C.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 96 - C.4. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 97 - C.5. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 97 - C.6. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 98 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 5] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -1. Introduction - - This document specifies extensions to the CalDAV "calendar-access" - [RFC4791] feature to enable scheduling of iCalendar-based [RFC5545] - calendar components between Calendar Users. This extension leverages - the scheduling methods defined in the iCalendar Transport-independent - Interoperability Protocol (iTIP) [RFC5546] to permit Calendar Users - to perform scheduling transactions such as schedule, reschedule, - respond to scheduling request or cancel calendar components, as well - as search for busy time information. - - Discussion of this Internet-Draft is taking place on the mailing list - <https://www.ietf.org/mailman/listinfo/caldav>. - -1.1. Terminology - - This specification uses much of the same terminology as iCalendar - [RFC5545], iTIP [RFC5546], WebDAV [RFC4918], and CalDAV [RFC4791]. - The following definitions are provided to aid the reader in - understanding this specification. - - Calendar User (CU): An entity (often a human) that accesses calendar - information [RFC3283]. - - Calendar collection: A resource that acts as a container of - references to child calendar object resources [RFC4791]. - - Calendar object resource: A resource representing a calendar object - (event, to-do, journal entry, or other calendar components) - [RFC4791]. - - Scheduling object resource: A calendar object resource contained in - a calendar collection for which the server will take care of - sending scheduling messages on behalf of the owner of the calendar - collection. - - Organizer scheduling object resource: A scheduling object resource - owned by an Organizer. - - Attendee scheduling object resource: A scheduling object resource - owned by an Attendee. - - Automatic scheduling transaction: Add, change or remove operations - on a scheduling object resource for which the server will deliver - scheduling messages to other Calendar Users. - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 6] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Scheduling message: A calendar object that describes a scheduling - transaction such as schedule, reschedule, reply, or cancel. - - Scheduling Outbox collection: A resource at which busy time - information requests are targeted. - - Scheduling Inbox collection: A collection in which incoming - scheduling messages are delivered. - -1.2. Approach - - iTIP [RFC5546] outlines a model where Calendar Users exchange - scheduling messages with one another. Often times, clients are made - responsible for generating and sending scheduling messages as well as - processing incoming scheduling messages. This approach yields a - number of problems, including: - - o For most updates to a calendar component, clients are responsible - for sending appropriate scheduling messages to the Organizer or - the Attendees. - - o The handling of incoming scheduling messages and the updates to - calendars impacted by those messages only occurs when clients are - active. - - o Due to the update latency, it is possible for calendars of - different Calendar Users to reflect different, inaccurate states. - - This specification uses an alternative approach where the server is - made responsible for sending scheduling messages and processing - incoming scheduling messages. This approach frees the clients from - the submission and processing of scheduling messages and ensures - better consistency of calendar data across users' calendars. The - operation of creating, modifying or deleting a calendar component in - a calendar is enough to trigger the server to deliver the necessary - scheduling messages to the appropriate Calendar Users. - -1.3. Limitations - - While the scheduling features described in this specification are - based on iTIP [RFC5546], some of its more advanced features have - deliberately been left out in order to keep this specification - simple. In particular, the following iTIP [RFC5546] features are not - covered: publishing, countering, delegating, refreshing and - forwarding calendar components, as well as replacing the Organizer of - a calendar component. - - The goal of this specification is to provide the essential scheduling - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 7] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - features needed. It is expected that future extensions will be - developed to address the more advanced features. - -1.4. Notational Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - The Augmented BNF (ABNF) syntax used by this document to specify the - format definition of new iCalendar elements is defined in [RFC5234]. - - The Augmented BNF (ABNF) syntax used by this document to specify the - format definition of new message header fields to be used with the - HTTP/1.1 protocol is described in Section 2.1 of [RFC2616]. Since - this Augmented BNF uses the basic production rules provided in - Section 2.2 of [RFC2616], these rules apply to this document as well. - - The term "protected" is used in the Conformance field of WebDAV - property definitions as defined in Section 15 of [RFC4918]. - -1.5. XML Namespaces and Processing - - This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section - 3.2) as a purely notational convention. WebDAV request and response - bodies cannot be validated by a DTD due to the specific extensibility - rules defined in Section 17 of [RFC4918] and due to the fact that all - XML elements defined by that specification use the XML namespace name - "DAV:". In particular: - - 1. element names use the "DAV:" namespace, - - 2. element ordering is irrelevant unless explicitly stated, - - 3. extension elements (elements not already defined as valid child - elements) may be added anywhere, except when explicitly stated - otherwise, - - 4. extension attributes (attributes not already defined as valid for - this element) may be added anywhere, except when explicitly - stated otherwise. - - The XML elements specified in this document are defined in the - "urn:ietf:params:xml:ns:caldav" XML namespace registered by CalDAV - [RFC4791]. - - When XML element types in the namespaces "DAV:" and - "urn:ietf:params:xml:ns:caldav" are referenced in this document - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 8] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - outside of the context of an XML fragment, the strings "DAV:" and - "CALDAV:" will be prefixed to the element types, respectively. - - This document inherits, and sometimes extends, DTD productions from - Section 14 of [RFC4918]. - - Also note that some CalDAV XML element names are identical to WebDAV - XML element names, though their namespace differs. Care must be - taken not to confuse the two sets of names. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 9] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -2. Scheduling Process - - The process of scheduling an event between different parties often - involves a series of steps with different actors playing particular - roles during the whole process. Typically there is an event - "Organizer" whose role is to schedule an event between one or more - "Attendees", and this is done by sending out invitations and handling - responses from each Attendee. - - This process can typically be broken down into two phases. - - In the first phase, the Organizer will query the busy time - information of each Attendee to determine the most appropriate time - for the event. This request is sometimes called a "freebusy" lookup. - - In the second phase, the Organizer sends out invitations to each - Attendee using the time previously determined from the freebusy - lookup. There then follows exchanges between Organizer and Attendees - regarding the invitation. Some Attendees may choose to attend at the - time proposed by the Organizer, others may decline to attend. The - Organizer needs to process each of the replies from the Attendees and - take appropriate action to confirm the event, reschedule it or - perhaps cancel it. - - The user expectation as to how a calendaring and scheduling system - should respond in each of these two phases is somewhat different. In - the case of a freebusy lookup, users expect to get back results - immediately so that they can then move on to the invitation phase as - quickly as possible. In the case of invitations, it is expected that - each Attendee will reply with their participation status in their own - time, so delays in receiving replies are anticipated. Thus - calendaring and scheduling systems should treat these two operational - phases in different ways to accommodate the user expectations, which - is what this specification does. - - While the scenario described above only covers the case of scheduling - events between Calendar Users, and requesting busy time information, - this specification also provides support for the scheduling of to-dos - between Calendar Users. For the majority of the following - discussion, scheduling of events and freebusy lookups will be - discussed, as these are the more common operations. - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 10] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -3. Scheduling Support - - A server that supports the features described in this document MUST - include "calendar-auto-schedule" as a field in the DAV response - header from an OPTIONS request on any resource that supports any - scheduling actions, properties, privileges or methods. - - To advertise support for the CalDAV "calendar-auto-schedule" feature - a server is REQUIRED to support and advertise support for the CalDAV - "calendar-access" [RFC4791] feature. - -3.1. Example OPTIONS Request - - In this example, the OPTIONS response indicates that the server - supports the "calendar-access" and "calendar-auto-schedule" features - and that the resource "/home/cyrus/calendars/inbox/" supports the - scheduling actions, properties, privileges and methods defined in - this specification. - - >> Request << - - OPTIONS /home/cyrus/calendars/inbox/ HTTP/1.1 - Host: cal.example.com - - >> Response << - - HTTP/1.1 204 No Content - Date: Thu, 31 Mar 2011 09:00:00 GMT - Allow: OPTIONS, GET, HEAD, DELETE, TRACE, PROPFIND - Allow: PROPPATCH, LOCK, UNLOCK, REPORT, ACL - DAV: 1, 2, 3, access-control - DAV: calendar-access, calendar-auto-schedule - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 11] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -4. Scheduling Collections - - This specification introduces new collection resource types that are - used to manage scheduling object resources, and scheduling - privileges, as well as provide scheduling functionality. It is the - server's responsibility to create these collection resources, and - clients have no way to create or delete them. - -4.1. Scheduling Outbox Collection - - A scheduling Outbox collection is used as the target for busy time - information requests, and to manage privileges that apply to outgoing - scheduling requests. - - A scheduling Outbox collection MUST report the DAV:collection and - CALDAV:schedule-outbox XML elements in the value of the DAV: - resourcetype property. The element type declaration for CALDAV: - schedule-outbox is: - - <!ELEMENT schedule-outbox EMPTY> - - Example: - - <D:resourcetype xmlns:D="DAV:"> - <D:collection/> - <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/> - </D:resourcetype> - - New WebDAV ACL [RFC3744] privileges can be set on the scheduling - Outbox collection to control who is allowed to send scheduling - messages on behalf of the Calendar User associated with the - scheduling Outbox collection. See Section 13.1 for more details. - - A scheduling Outbox collection MUST NOT be a child (at any depth) of - a calendar collection resource. - - The following WebDAV properties specified in CalDAV "calendar-access" - [RFC4791] MAY also be defined on scheduling Outbox collections: - - CALDAV:supported-calendar-component-set - when present this - indicates the allowed calendar component types for scheduling - messages submitted to the scheduling Outbox collection with the - POST method. - - CALDAV:supported-calendar-data - when present this indicates the - allowed media types for scheduling messages submitted to the - scheduling Outbox collection with the POST method. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 12] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - CALDAV:max-resource-size - when present this indicates the maximum - size in octets of a resource that the server is willing to accept - for scheduling messages submitted to the scheduling Outbox - collection with the POST method. - - CALDAV:min-date-time - when present this indicates the earliest - date and time (in UTC) that the server is willing to accept for - any DATE or DATE-TIME value in scheduling messages submitted to - the scheduling Outbox collection with the POST method. - - CALDAV:max-date-time - when present this indicates the latest date - and time (in UTC) that the server is willing to accept for any - DATE or DATE-TIME value in scheduling messages submitted to the - scheduling Outbox collection with the POST method. - - CALDAV:max-attendees-per-instance - when present this indicates - the maximum number of ATTENDEE properties in any instance of - scheduling messages submitted to the scheduling Outbox collection - with the POST method. Specifically, this limits the total number - of Attendees whose freebusy information can be queried in a single - request. - - The use of child resources in a scheduling Outbox collection is - reserved for future revisions or extensions of this specification. - -4.2. Scheduling Inbox Collection - - A scheduling Inbox collection contains copies of incoming scheduling - messages. These may be requests sent by an Organizer, or replies - sent by an Attendee in response to a request. The scheduling Inbox - collection is also used to manage scheduling privileges. - - A scheduling Inbox collection MUST report the DAV:collection and - CALDAV:schedule-inbox XML elements in the value of the DAV: - resourcetype property. The element type declaration for CALDAV: - schedule-inbox is: - - <!ELEMENT schedule-inbox EMPTY> - - Example: - - <D:resourcetype xmlns:D="DAV:"> - <D:collection/> - <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/> - </D:resourcetype> - - Scheduling Inbox collections MUST only contain calendar object - resources that obey the restrictions specified in iTIP [RFC5546]. - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 13] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Consequently, scheduling Inbox collections MUST NOT contain any types - of collection resources. Restrictions defined in Section 4.1 of - CalDAV "calendar-access" [RFC4791] on calendar object resources - contained in calendar collections (e.g., "UID" uniqueness) do not - apply to calendar object resources contained in a scheduling Inbox - collection. Thus, multiple calendar object resources contained in a - scheduling Inbox collection can have the same "UID" property value - (i.e., multiple scheduling messages for the same calendar component). - - New WebDAV ACL [RFC3744] privileges can be set on the scheduling - Inbox collection to control from whom the Calendar User associated - with the scheduling Inbox collection will accept scheduling messages - from. See Section 13.1 for more details. - - A scheduling Inbox collection MUST NOT be a child (at any depth) of a - calendar collection resource. - - The following WebDAV properties specified in CalDAV "calendar-access" - [RFC4791] MAY also be defined on scheduling Inbox collections: - - CALDAV:calendar-timezone - when present this contains a time zone - that the server can use when calendar date-time operations are - carried out, for example when a time-range CALDAV:calendar-query - REPORT is targeted at a scheduling Inbox collection. - - CALDAV:supported-calendar-component-set - when present this - indicates the allowed calendar component types for scheduling - messages delivered to the scheduling Inbox collection. - - CALDAV:supported-calendar-data - when present this indicates the - allowed media types for scheduling messages delivered to the - scheduling Inbox collection. - - CALDAV:max-resource-size - when present this indicates the maximum - size in octets of a resource that the server is willing to accept - for scheduling messages delivered to the scheduling Inbox - collection. - - CALDAV:min-date-time - when present this indicates the earliest - date and time (in UTC) that the server is willing to accept for - any DATE or DATE-TIME value in scheduling messages delivered to - the scheduling Inbox collection. - - CALDAV:max-date-time - when present this indicates the latest date - and time (in UTC) that the server is willing to accept for any - DATE or DATE-TIME value in scheduling messages delivered to the - scheduling Inbox collection. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 14] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - CALDAV:max-instances - when present this indicates the maximum - number of recurrence instances in scheduling messages delivered to - the scheduling Inbox collection. - - CALDAV:max-attendees-per-instance - when present this indicates - the maximum number of ATTENDEE properties in any instance of - scheduling messages delivered to the scheduling Inbox collection. - -4.3. Calendaring Reports Extensions - - This specification extends the CALDAV:calendar-query and CALDAV: - calendar-multiget REPORTs to return results for calendar object - resources in scheduling Inbox collections. - - When a CALDAV:calendar-query REPORT includes a time-range query and - targets a scheduling Inbox collection, if any calendar object - resources contain "VEVENT" calendar components that do not include a - "DTSTART" iCalendar property (as allowed by iTIP [RFC5546]) then such - components MUST always match the time-range query test. - - Note that the CALDAV:free-busy-query REPORT is not supported on - scheduling Inbox collections. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 15] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -5. Scheduling Transactions - - When a calendar object resource is created, modified or removed from - a calendar collection, the server examines the calendar data and - checks to see whether the data represents a scheduling object - resource. If it does, the server will automatically attempt to - deliver a scheduling message to the appropriate Calendar Users. - Several types of scheduling operations can occur in this case, - equivalent to iTIP "REQUEST", "REPLY", "CANCEL", and "ADD" - operations. - -5.1. Identifying Scheduling Object Resources - - Calendar object resources on which the server performs automatic - scheduling transactions are referred to as scheduling object - resources. There are two types of scheduling object resources: - organizer scheduling object resources, and attendee scheduling object - resources. - - A calendar object resource is considered to be a valid organizer - scheduling object resource if the "ORGANIZER" iCalendar property is - present and set in all the calendar components to a value that - matches one of the calendar user addresses of the owner of the - calendar collection. - - A calendar object resource is considered to be a valid attendee - scheduling object resource if the "ORGANIZER" iCalendar property is - present and set in all the calendar components to the same value and - doesn't match one of the calendar user addresses of the owner of the - calendar collection, and at least one of the "ATTENDEE" iCalendar - property values matches one of the calendar user addresses of the - owner of the calendar collection. - - The creation of attendee scheduling object resources is typically - done by the server, with the resource being created in an appropriate - calendar collection (see Section 6.4). - -5.2. Handling Scheduling Object Resources - - The server's behavior when processing a scheduling object resource - depends on whether it is owned by the Organizer or an Attendee - specified in the calendar data. - -5.2.1. Organizer Scheduling Object Resources - - An Organizer can create, modify or remove a scheduling object - resource. The create, modify and remove behaviors for the server are - each described next, and the way these are invoked via HTTP requests - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 16] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - is described in Section 5.2.3. - - The Organizer of a calendar component may also be an Attendee of that - calendar component. In such cases the server MUST NOT send a - scheduling message to the Attendee that matches the Organizer. - -5.2.1.1. Create - - When a scheduling object resource is created by the Organizer, the - server will inspect each "ATTENDEE" property to determine if a - scheduling message should be delivered to this Attendee according to - the value of the "SCHEDULE-AGENT" property parameter (see - Section 10.1) as described in the table below: - - +------------------+-------------+ - | SCHEDULE-AGENT | iTIP METHOD | - +==================+=============+ - | SERVER (default) | REQUEST | - +------------------+-------------+ - | CLIENT | -- | - +------------------+-------------+ - | NONE | -- | - +------------------+-------------+ - - The attempt to deliver the scheduling message will either succeed or - fail. In all cases, the server MUST add a "SCHEDULE-STATUS" - iCalendar property parameter (see Section 10.3) to the "ATTENDEE" - iCalendar property in the scheduling object resource being created, - and set its value as described in Section 9.2. This will result in - the created calendar object resource differing from the calendar data - sent in the HTTP request. As a result clients MAY reload the - calendar data from the server in order to update to the new server - generated state information. Servers MUST NOT set the "SCHEDULE- - STATUS" property parameter on the "ATTENDEE" property of Attendees - for which it did not attempt to deliver a scheduling message. - - Restrictions: - - 1. The server SHOULD reject any attempt to set the "PARTSTAT" - iCalendar property parameter value of the "ATTENDEE" iCalendar - property of other users in the calendar object resource to a - value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property - parameter value is not present or set to the value "SERVER". - - 2. The server MAY reject attempts to create a scheduling object - resource that specifies a "UID" property value already specified - in a scheduling object resource contained in another calendar - collection of the Organizer. - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 17] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - 3. The server MUST take into account scheduling privileges as - described in Section 13.1 when handling the creation of a - scheduling object resource. - - 4. Restrictions on calendar object resources defined in Section 4.1 - of [RFC4791] MUST also be enforced. - - The server MUST return an error with the CALDAV:allowed-organizer- - scheduling-object-change precondition code (Section 5.2.4.3) when the - Organizer attempts to change the iCalendar data in a manner that is - forbidden. - -5.2.1.2. Modify - - When a scheduling object resource is modified by the Organizer, the - server will inspect each "ATTENDEE" property in the new calendar data - to determine which ones have the "SCHEDULE-AGENT" iCalendar property - parameter. It will then need to compare this with the "ATTENDEE" - properties in the existing calendar object resource that is being - modified. - - For each Attendee in the old and new calendar data on a per-instance - basis, and taking into account the addition or removal of Attendees, - the server will determine whether to deliver a scheduling message to - the Attendee. The following table determines whether the server - needs to deliver a scheduling message, and if so which iTIP - scheduling method to use. The values "SERVER", "CLIENT", and "NONE" - in the top and left titles of the table refer to the "SCHEDULE-AGENT" - parameter value of the "ATTENDEE" property, and the values "<Absent>" - and "<Removed>" are used to cover the cases where the "ATTENDEE" - property is not present (Old) or is being removed (New). - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 18] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - +---------------+-----------------------------------------------+ - | | New | - | ATTENDEE +-----------+-----------+-----------+-----------+ - | | <Removed> | SERVER | CLIENT | NONE | - | | | (default) | | | - +===+===========+===========+===========+===========+===========+ - | | <Absent> | -- | REQUEST / | -- | -- | - | | | | ADD | | | - | +-----------+-----------+-----------+-----------+-----------+ - | | SERVER | CANCEL | REQUEST | CANCEL | CANCEL | - | O | (default) | | | | | - | l +-----------+-----------+-----------+-----------+-----------+ - | d | CLIENT | -- | REQUEST / | -- | -- | - | | | | ADD | | | - | +-----------+-----------+-----------+-----------+-----------+ - | | NONE | -- | REQUEST / | -- | -- | - | | | | ADD | | | - +---+-----------+-----------+-----------+-----------+-----------+ - - The attempt to deliver the scheduling message will either succeed or - fail. In all cases, the server MUST add a "SCHEDULE-STATUS" - iCalendar property parameter to the "ATTENDEE" iCalendar property in - the scheduling object resource being modified, and set its value as - described in Section 9.2. This will result in the created calendar - object resource differing from the calendar data sent in the HTTP - request. As a result clients MAY reload the calendar data from the - server in order to update to the new server generated state - information. - - Restrictions: - - 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar - property parameter value of the "ATTENDEE" iCalendar property of - other users in the calendar object resource to a value other than - "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value - is not present or set to the value "SERVER". - - 2. The server MUST take into account scheduling privileges as - described in Section 13.1 when handling the modification of a - scheduling object resource. - - 3. Restrictions on calendar object resources defined in Section 4.1 - of [RFC4791] MUST also be enforced. - - The server MUST return an error with the CALDAV:allowed-organizer- - scheduling-object-change precondition code (Section 5.2.4.3) when the - Organizer attempts to change the iCalendar data in a manner that is - forbidden. - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 19] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -5.2.1.3. Remove - - When a scheduling object resource is removed by the Organizer, the - server will inspect each "ATTENDEE" property in the scheduling object - resource being removed to determine which ones have the "SCHEDULE- - AGENT" iCalendar property parameter. - - For each Attendee the server will determine whether to attempt to - deliver a scheduling message into the Attendee's scheduling Inbox - collection, based on the table below: - - +------------------+-------------+ - | SCHEDULE-AGENT | iTIP METHOD | - +==================+=============+ - | SERVER (default) | CANCEL | - +------------------+-------------+ - | CLIENT | -- | - +------------------+-------------+ - | NONE | -- | - +------------------+-------------+ - - Restrictions: - - 1. The server MUST take into account scheduling privileges as - described in Section 13.1 when handling the deletion of a - scheduling object resource. - -5.2.2. Attendee Scheduling Object Resources - - An Attendee can create, modify or remove a scheduling object resource - by issuing HTTP requests with an appropriate method. The create, - modify and remove behaviors for the server are each described next, - and the way these are invoked via HTTP requests is described in - Section 5.2.3. - -5.2.2.1. Allowed Attendee Changes - - Attendees are allowed to make some changes to a scheduling object - resource, though key properties such as start time, end time, - location, and summary are typically under the control of the - Organizer. - - The server MUST allow Attendees to: - - 1. change their own "PARTSTAT" iCalendar property parameter value. - - 2. add, modify or remove any "TRANSP" iCalendar properties. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 20] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - 3. add, modify or remove any "PERCENT-COMPLETE" iCalendar - properties. - - 4. add, modify or remove any "COMPLETED" iCalendar properties. - - 5. add, modify or remove any "VALARM" iCalendar components. - - 6. add, modify or remove the "CALSCALE" iCalendar property within - the top-level "VCALENDAR" component. - - 7. modify the "PRODID" iCalendar property within the top-level - "VCALENDAR" component. - - 8. add "EXDATE" iCalendar properties and possibly remove components - for overridden recurrence instances. - - 9. add, modify or remove any "CREATED", "DTSTAMP" and "LAST- - MODIFIED" iCalendar properties. - - 10. add, modify or remove "SCHEDULE-STATUS" iCalendar property - parameters on "ATTENDEE" properties that have a "SCHEDULE-AGENT" - parameter set to "CLIENT". - - 11. add new components to represent overridden recurrence instances, - provided the only changes to the recurrence instance follow the - rules above. - - The server MUST return an error with the CALDAV:allowed-attendee- - scheduling-object-change precondition code (Section 5.2.4.4) when the - Attendee attempts to change the iCalendar data in a manner forbidden - by the server. - -5.2.2.2. Create - - Typically an Attendee does not create scheduling object resources, as - scheduling messages delivered to them on the server are automatically - processed by the server and placed on one of their calendars (see - Section 6). However, in some cases a scheduling message may get - delivered directly to the client, and the Attendee may wish to store - that on the server. In that case the client creates a scheduling - object resource in a suitable calendar belonging to the Attendee. It - can then set the "SCHEDULE-AGENT" iCalendar property parameter on all - "ORGANIZER" iCalendar properties in the resource to determine how the - server treats the resource. The value of the "SCHEDULE-AGENT" - iCalendar property parameter on all "ORGANIZER" iCalendar properties - MUST be the same. - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 21] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - +----------------+--------------------------------------------------+ - | SCHEDULE-AGENT | Action | - +----------------+--------------------------------------------------+ - | SERVER | The server will attempt to process changes to | - | (default) | the resource using the normal rules for attendee | - | | scheduling object resources. | - | | | - | CLIENT | The server does no special processing of the | - | | resource. The client is assumed to be handling | - | | Attendee replies etc. | - | | | - | NONE | The server does no special processing of the | - | | resource. | - +----------------+--------------------------------------------------+ - - In some cases a server may not be able to process an Attendee - scheduling object resource that originated from another system (i.e., - where the server is unable to deliver scheduling messages to the - Organizer). In such cases the server MUST add a "SCHEDULE-STATUS" - iCalendar property parameter to all "ORGANIZER" iCalendar properties - in the resource with a suitable value indicating a error. - -5.2.2.3. Modify - - When a scheduling object resource is modified by an Attendee, the - server behavior depends on the value of the "SCHEDULE-AGENT" - iCalendar property parameter on the "ORGANIZER" iCalendar properties: - - +----------------+--------------------------------------------------+ - | SCHEDULE-AGENT | Action | - +----------------+--------------------------------------------------+ - | SERVER | The server will attempt to process the removal | - | (default) | using the behavior listed below. | - | | | - | CLIENT | The server does no special processing of the | - | | resource. The client is assumed to be handling | - | | any Attendee replies etc. | - | | | - | NONE | The server does no special processing of the | - | | resource. | - +----------------+--------------------------------------------------+ - - The server will inspect the changes by comparing the new scheduling - object resource with the existing scheduling object resource. - - If the Attendee changes one or more "PARTSTAT" iCalendar property - values on any component, or adds an overridden component with a - changed "PARTSTAT" property, then the server MUST deliver an iTIP - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 22] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - "REPLY" scheduling message to the Organizer to indicate the new - participation status of the Attendee. - - If the Attendee adds an "EXDATE" property value to effectively remove - a recurrence instance, the server MUST deliver an iTIP "REPLY" - scheduling message to the Organizer to indicate that the Attendee has - declined the instance (i.e., the Attendee's "PARTSTAT" iCalendar - property parameter value is set to "DECLINED"). - - The attempt to deliver the scheduling message will either succeed or - fail. In all cases, the server MUST add a "SCHEDULE-STATUS" - iCalendar property parameter to the "ORGANIZER" iCalendar property in - the scheduling object resource being created, and set its value as - described in Section 9.2. This will result in the created calendar - object resource differing from the calendar data sent in the HTTP - request. As a result clients MAY reload the calendar data from the - server in order to update to the new server generated state - information. - -5.2.2.4. Remove - - When a scheduling object resource is removed by an Attendee, the - server behavior depends on the value of the "SCHEDULE-AGENT" - iCalendar property parameter on the "ORGANIZER" iCalendar properties: - - +----------------+--------------------------------------------------+ - | SCHEDULE-AGENT | Action | - +----------------+--------------------------------------------------+ - | SERVER | The server will attempt to process the removal | - | (default) | using either behaviors (1) or (2) listed below. | - | | | - | CLIENT | The server does no special processing of the | - | | resource. The client is assumed to be handling | - | | any Attendee replies etc. | - | | | - | NONE | The server does no special processing of the | - | | resource. | - +----------------+--------------------------------------------------+ - - 1. If the HTTP request contains a "Schedule-Reply" request header - set to the value "T" or there is no "Schedule-Reply" request - header, then the server MUST attempt to deliver a scheduling - message to the Organizer indicating that the Attendee has a - "PARTSTAT" iCalendar property parameter value set to "DECLINED". - That is, the Attendee has chosen not to attend any instances. If - the server is unable to deliver the scheduling message, the - remove action MUST fail, and an appropriate "SCHEDULE-STATUS" - iCalendar property parameter set on the "ORGANIZER" property in - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 23] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - the scheduling object resource stored by the server. - - 2. If the HTTP request contains a "Schedule-Reply" request header - set to the value "F", the server MUST NOT attempt to deliver a - scheduling message. The resource is simply removed. This - provides the client a way to silently remove unwanted scheduling - messages. - -5.2.3. HTTP Methods - - This section describes how use of various HTTP methods on a - scheduling object resource will cause a create, modify or remove - action on that resource as described above. The use of these methods - is subject to the restrictions in [RFC4791], in addition to what is - described below. - -5.2.3.1. PUT - - When a PUT method request is received, the server will execute the - following actions, provided all appropriate preconditions are met: - - +--------------------------+--------------------------+-------------+ - | Existing Destination | Resulting Destination | Server | - | Resource | Resource | Action | - +--------------------------+--------------------------+-------------+ - | None | Calendar object resource | None | - | | | | - | None | Scheduling object | Create | - | | resource | | - | | | | - | Calendar object resource | Calendar object resource | None | - | | | | - | Calendar object resource | Scheduling object | Create | - | | resource | | - | | | | - | Scheduling object | Calendar object resource | Remove | - | resource | | | - | | | | - | Scheduling object | Scheduling object | Modify | - | resource | resource | | - +--------------------------+--------------------------+-------------+ - -5.2.3.2. COPY - - When a COPY method request is received, the server will execute the - following actions based on the source and destination collections in - the request: - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 24] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - +-------------------------+-------------------------+---------------+ - | Source Collection | Destination Collection | Server Action | - +-------------------------+-------------------------+---------------+ - | Non-calendar collection | Non-calendar collection | None | - | | | | - | Non-calendar collection | Calendar collection | (1) | - | | | | - | Calendar collection | Non-calendar collection | None | - | | | | - | Calendar collection | Calendar collection | (2) | - +-------------------------+-------------------------+---------------+ - - Note 1. The same rules as used for PUT above are applied for the - destination of the COPY request. - - Note 2. The server MAY reject this as per Section 5.2.4.1, otherwise - None. - - The behavior of a COPY method request on a calendar collection is - undefined. - -5.2.3.3. MOVE - - When a MOVE method request is received, the server will execute the - following actions based on the source and destination collections in - the request: - - +-------------------------+-------------------------+---------------+ - | Source Collection | Destination Collection | Server Action | - +-------------------------+-------------------------+---------------+ - | Non-calendar collection | Non-calendar collection | None | - | | | | - | Non-calendar collection | Calendar collection | (1) | - | | | | - | Calendar collection | Non-calendar collection | (2) | - | | | | - | Calendar collection | Calendar collection | None | - +-------------------------+-------------------------+---------------+ - - Note 1. The same rules as used for PUT above are applied for the - destination of the MOVE request. - - Note 2. The same rules as used for DELETE below are applied for the - source of the MOVE request. - - The behavior of a MOVE method request on a calendar collection is - undefined. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 25] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -5.2.3.4. DELETE - - When a DELETE method is targeted at a scheduling object resource the - server will execute the Remove action. - - When a DELETE method is targeted at a calendar collection the server - will execute the Remove action on all scheduling object resources - contained in the calendar collection. - -5.2.4. Additional Method Preconditions - - This specification defines method preconditions (see Section 16 of - WebDAV [RFC4918]), in addition to the ones in [RFC4791], to provide - machine-parsable information in error responses. - -5.2.4.1. CALDAV:unique-scheduling-object-resource Precondition - - Name: unique-scheduling-object-resource - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: PUT, COPY, and MOVE - - Use with: 403 Forbidden - - Purpose: (precondition) -- Servers MAY reject requests to create a - scheduling object resource with an iCalendar "UID" property value - already in use by another scheduling object resource owned by the - same user in other calendar collections. Servers SHOULD report - the URL of the scheduling object resource that is already making - use of the same "UID" property value in the DAV:href element. - - Definition: - - <!ELEMENT unique-scheduling-object-resource (DAV:href?)> - - Example: - - <C:unique-scheduling-object-resource xmlns:D="DAV:" - xmlns:C="urn:ietf:params:xml:ns:caldav"> - <D:href>/home/bernard/calendars/personal/abc123.ics</D:href> - </C:unique-scheduling-object-resource> - -5.2.4.2. CALDAV:same-organizer-in-all-components Precondition - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 26] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Name: same-organizer-in-all-components - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: PUT, COPY, and MOVE - - Use with: 403 Forbidden - - Purpose: (precondition) -- All the calendar components in a - scheduling object resource MUST contain the same "ORGANIZER" - property value when present. - - Definition: - - <!ELEMENT same-organizer-in-all-components EMPTY> - - Example: - - <C:same-organizer-in-all-components - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -5.2.4.3. CALDAV:allowed-organizer-scheduling-object-change Precondition - - Name: allowed-organizer-scheduling-object-change - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: PUT, COPY, and MOVE - - Use with: 403 Forbidden - - Purpose: (precondition) -- Servers MAY impose restrictions on - modifications allowed by an Organizer. For instance, servers MAY - prevent the Organizer setting the "PARTSTAT" property parameter to - a value other than "NEEDS-ACTION" if the corresponding "ATTENDEE" - property has the "SCHEDULE-AGENT" property parameter set to - "SERVER", or has no "SCHEDULE-AGENT" property parameter. See - Section 5.2.1. - - Definition: - - <!ELEMENT allowed-organizer-scheduling-object-change EMPTY> - - Example: - - <C:allowed-organizer-scheduling-object-change - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 27] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -5.2.4.4. CALDAV:allowed-attendee-scheduling-object-change Precondition - - Name: allowed-attendee-scheduling-object-change - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: PUT, COPY, and MOVE - - Use with: 403 Forbidden - - Purpose: (precondition) -- Servers MAY impose restrictions on - modifications allowed by an Attendee. Attendee modifications that - servers MUST allow are specified in Section 5.2.2.1. - - Definition: - - <!ELEMENT allowed-attendee-scheduling-object-change EMPTY> - - Example: - - <C:allowed-attendee-scheduling-object-change - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -5.2.5. DTSTAMP and SEQUENCE Properties - - Whenever the server generates a scheduling message for delivery to a - Calendar User, it MUST ensure that a "DTSTAMP" iCalendar property is - present and MUST set the value to the UTC time that the scheduling - message was generated (as required by iCalendar). - - iTIP [RFC5546] places certain requirements on how the "SEQUENCE" - iCalendar property value in scheduling messages changes. The server - MUST ensure that for each type of scheduling operation, the - "SEQUENCE" iCalendar property value is appropriately updated. If the - client does not update the "SEQUENCE" iCalendar property itself when - that is required, the server MUST update the property. - -5.2.6. Restrict Recurrence Instances Sent to Attendees - - When delivering scheduling messages for recurring calendar components - to Attendees, servers MUST ensure that Attendees only get information - about recurrence instances that explicitly include them as an - Attendee. - - For example, if an Attendee is invited to a single recurrence - instance of a recurring event, and no others, the scheduling object - resource contained in the Organizer's calendar collection will - contain an overridden instance in the form of a separate calendar - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 28] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - component. That separate calendar component will include the - "ATTENDEE" property referencing the "one-off" Attendee. That - Attendee will not be listed in any other calendar components in the - scheduling object resource. Any scheduling messages delivered to the - Attendee will only contain information about this overridden - instance. - - As another example, an Attendee could be excluded from one instance - of a recurring event. In that case the scheduling object resource - contained in the calendar collection of the Organizer will include an - overridden instance with an "ATTENDEE" list that does not include the - Attendee being excluded. The scheduling message that will be - delivered to the Attendee will not specify the overridden instance - but rather include an "EXDATE" property in the master recurring - component defining the recurrence set. - -5.2.7. Forcing the Server to Send a Scheduling Message - - The iCalendar property parameter "SCHEDULE-FORCE-SEND" defined in - Section 10.2 can be used by a Calendar User to force the server to - send a scheduling message to an Attendee or the Organizer in a - situation where the server would not normally send a scheduling - message. For instance, an Organizer could use this property - parameter to request an Attendee, that previously declined an - invitation, to reconsider their participation status without being - forced to modify the event. - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 29] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -6. Processing Incoming Scheduling Messages - - Scheduling operations can cause the delivery of a scheduling message - into an Organizer's or Attendee's scheduling Inbox collection. In - the former case the scheduling messages are replies from Attendees, - in the latter case the scheduling messages are requests, - cancellations or additions from the Organizer. - - Servers MUST automatically process incoming scheduling messages using - the rules defined by [RFC5546], by creating or updating the - corresponding scheduling object resources on calendars owned by the - owner of the scheduling Inbox collection. In addition, the - scheduling message is stored in the scheduling Inbox collection as an - indicator to the client that a scheduling operation has taken place. - - The server MUST take into account privileges on the scheduling Inbox - collection when processing incoming scheduling messages, to determine - whether delivery of the scheduling message is allowed. Privileges on - calendars containing any matching scheduling object resource are not - considered in this case (i.e., a schedule message from another user - can cause modifications to resources in calendar collections that the - other user would not normally have read or write access to). - Additionally, servers MUST take into account any scheduling Inbox - collection preconditions (see Section 4.2) when delivering the - scheduling message, and it MUST take into account the similar - preconditions on any calendar collection which contains, or would - contain, the corresponding scheduling object resource. - -6.1. Processing Organizer Requests, Additions, and Cancellations - - For a scheduling message sent by an Organizer, the server first tries - to locate a corresponding scheduling object resource belonging to the - Attendee. If no matching scheduling object resource exists, the - server treats the scheduling message as a new message, otherwise it - is treated as an update. - - In the case of a new message, the server MUST process the scheduling - message and create a new scheduling object resource in an appropriate - calendar collection for the Attendee. - - In the case of an update, the server MUST process the scheduling - message and update the matching scheduling object resource belonging - to the Attendee to reflect the changes sent by the Organizer. - - In each case, the scheduling message MUST only appear in the - Attendee's scheduling Inbox collection once all automatic processing - has been done. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 30] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -6.2. Processing Attendee Replies - - For a scheduling message reply sent by an Attendee, the server first - locates the corresponding scheduling object resource belonging to the - Organizer. - - The server MUST then update the "PARTSTAT" iCalendar property - parameter value of each "ATTENDEE" iCalendar property in the - scheduling object resource to match the changes indicated in the - reply (taking into account the fact that an Attendee could have - created a new overridden iCalendar component to indicate different - participation status on one or more recurrence instances of a - recurring event). - - The server MUST also update or add the "SCHEDULE-STATUS" property - parameter on each matching "ATTENDEE" iCalendar property and set its - value to that of the "REQUEST-STATUS" property in the reply, or to - "2.0" if "REQUEST-STATUS" is not present (also taking into account - recurrence instances). If there are multiple "REQUEST-STATUS" - properties in the reply, the "SCHEDULE-STATUS" property parameter - value is set to a comma-separated list of status codes, one from each - "REQUEST-STATUS" property. - - The server SHOULD send scheduling messages to all the other Attendees - indicating the change in participation status of the Attendee - replying, subject to the recurrence requirements of Section 5.2.6. - - The scheduling message MUST only appear in the Organizer's scheduling - Inbox collection once all automatic processing has been done. - -6.3. Scheduling Messages as Notifications - - Once the processing of an incoming scheduling message is completed by - the server, the message is made available as a child resource in the - scheduling Inbox collection of the Calendar User that received the - message, to serve as a notification that a change has been made to - the corresponding scheduling object resource. Scheduling messages - are typically removed from the scheduling Inbox collection by the - client once the calendar user has acknowledged the change. - -6.4. Default Calendar Collection - - The server is REQUIRED to process scheduling messages received for an - Attendee by creating a new scheduling object resource in a calendar - collection belonging to the Attendee, when one does not already - exist. A Calendar User that is an Attendee in a scheduling operation - MUST have at least one valid calendar collection available. If there - is no valid calendar collection, then the server MUST reject the - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 31] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - attempt to deliver the scheduling message to the Attendee. - - Servers MAY provide support for a default calendar collection, that - is, the calendar collection in which new scheduling object resources - will be created. The CALDAV:schedule-default-calendar-URL WebDAV - property, which can be present on the scheduling Inbox collection of - a Calendar User, specifies if this Calendar User has a default - calendar collection. See Section 12.2. - - Servers SHOULD create new scheduling object resources in the default - calendar collection, if the CALDAV:schedule-default-calendar-URL - WebDAV property is set. - - Servers MAY allow clients to change the default calendar collection - by changing the value of the CALDAV:schedule-default-calendar-URL - WebDAV property on the scheduling Inbox collection. However, the - servers MUST ensure that any new value for that property refers to a - valid calendar collection belonging to the owner of the scheduling - Inbox collection. - - Servers MUST reject any attempt to delete the default calendar - collection. - -6.4.1. Additional Method Preconditions - - This specification defines additional method preconditions (see - Section 16 of WebDAV [RFC4918]) to provide machine-parsable - information in error responses. - -6.4.1.1. CALDAV:default-calendar-needed Precondition - - Name: default-calendar-needed - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: DELETE - - Use with: 403 Forbidden - - Purpose: (precondition) -- The client attempted to delete the - calendar collection currently referenced by the CALDAV:schedule- - default-calendar-URL property, or attempted to remove the CALDAV: - schedule-default-calendar-URL property on the scheduling Inbox - collection on a server that doesn't allow such operations. - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 32] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Definition: - - <!ELEMENT default-calendar-needed EMPTY> - - Example: - - <C:default-calendar-needed - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -6.4.1.2. CALDAV:valid-schedule-default-calendar-URL Precondition - - Name: valid-schedule-default-calendar-URL - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: PROPPATCH - - Use with: 403 Forbidden - - Purpose: (precondition) -- The client attempted to set the CALDAV: - schedule-default-calendar-URL property to a DAV:href element that - doesn't reference a valid calendar collection. Note: Servers that - do not allow clients to change the CALDAV:schedule-default- - calendar-URL property would simply return the DAV:cannot-modify- - protected-property precondition defined in Section 16 of WebDAV - [RFC4918]. - - Definition: - - <!ELEMENT valid-schedule-default-calendar-URL EMPTY> - - Example: - - <C:valid-schedule-default-calendar-URL - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 33] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -7. Request for Busy Time Information - - The POST method is used to request busy time information of one or - more Calendar Users by submitting a request at the scheduling Outbox - collection of the Calendar User requesting the information (the - Organizer). To accomplish this, the request body of a POST method - MUST contain a "VFREEBUSY" calendar component with the "METHOD" - iCalendar property set to the value "REQUEST" as specified in Section - 3.3.2 of iTIP [RFC5546]. The resource identified by the Request-URI - MUST be a resource collection of type CALDAV:schedule-outbox - (Section 4.1). The "ORGANIZER" property in the "VFREEBUSY" component - MUST match that of the Calendar User who "owns" the Outbox - collection. - -7.1. Status Codes - - The following are examples of response codes one would expect to be - used for this method. However, unless explicitly prohibited, any - 2/3/4/5xx series response code can be used in a response. - - 200 (OK) - The command succeeded. - - 204 (No Content) - The command succeeded. - - 400 (Bad Request) - The client has provided an invalid scheduling - message. - - 403 (Forbidden) - The client cannot submit a scheduling message to - the specified Request-URI. - - 404 (Not Found) - The URL in the Request-URI was not present. - - 423 (Locked) - The specified resource is locked and the client - either is not a lock owner or the lock type requires a lock token - to be submitted and the client did not submit it. - -7.2. Additional Method Preconditions - - This specification defines additional method preconditions for the - POST method. Preconditions defined in WebDAV ACL [RFC3744] and - CalDAV [RFC4791] that applies to the POST method are also listed here - for completeness. - -7.2.1. DAV:need-privileges Precondition - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 34] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Name: need-privileges - - Namespace: DAV: - - Apply to: POST - - Use with: 403 Forbidden - - Purpose: (precondition) -- The currently authenticated user MUST be - granted the CALDAV:schedule-send-freebusy privilege on the - scheduling Outbox collection being targeted by the request. - - Definition: - - <!ELEMENT DAV:need-privileges (DAV:resource)* > - <!ELEMENT DAV:resource (DAV:href, DAV:privilege) > - - Example: - - <D:need-privileges xmlns:D="DAV:" - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - <D:resource> - <D:href>/home/bernard/calendars/outbox/</D:href> - <D:privilege><C:schedule-send-freebusy/></D:privilege> - </D:resource> - </D:need-privileges> - -7.2.2. CALDAV:supported-collection Precondition - - Name: supported-collection - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: POST - - Use with: 400 Bad Request - - Purpose: (precondition) -- The Request-URI MUST identify the - location of a scheduling Outbox collection. - - Definition: - - <!ELEMENT supported-collection EMPTY > - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 35] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Example: - - <C:supported-collection xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -7.2.3. CALDAV:supported-calendar-data Precondition - - Name: supported-calendar-data - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: POST - - Use with: 400 Bad Request - - Purpose: (precondition) -- The resource body submitted in the POST - request MUST be a supported media type (e.g., text/calendar). - - Definition: - - <!ELEMENT supported-calendar-data EMPTY > - - Example: - - <C:supported-calendar-data - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -7.2.4. CALDAV:valid-calendar-data Precondition - - Name: valid-calendar-data - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: POST - - Use with: 400 Bad Request - - Purpose: (precondition) -- The resource submitted in the POST - request MUST be valid data for the media type being specified - (e.g., a valid iCalendar object). - - Definition: - - <!ELEMENT valid-calendar-data EMPTY> - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 36] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Example: - - <C:valid-calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -7.2.5. CALDAV:valid-scheduling-message Precondition - - Name: valid-scheduling-message - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: POST - - Use with: 400 Bad Request - - Purpose: (precondition) -- The resource submitted in the POST - request MUST obey all restrictions specified for the POST request - (e.g., the scheduling message follow the restrictions of iTIP). - - Definition: - - <!ELEMENT valid-scheduling-message EMPTY > - - Example: - - <C:valid-scheduling-message - xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -7.2.6. CALDAV:valid-organizer Precondition - - Name: valid-organizer - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: POST - - Use with: 403 Forbidden - - Purpose: (precondition) -- The Calendar User identified by the - "ORGANIZER" property in the POST request's scheduling message MUST - be the Calendar User (or one of the Calendar Users) associated - with the scheduling Outbox collection being targeted by the - request; - - Definition: - - <!ELEMENT valid-organizer EMPTY > - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 37] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Example: - - <C:valid-organizer xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -7.2.7. CALDAV:max-resource-size Precondition - - Name: max-resource-size - - Namespace: urn:ietf:params:xml:ns:caldav - - Apply to: POST - - Use with: 403 Forbidden - - Purpose: (precondition) -- The resource submitted in the POST - request MUST have a size in octets less than or equal to the value - of the CALDAV:max-resource-size property (defined in Section 5.2.5 - of [RFC4791]) specified on the scheduling Outbox collection - targeted by the request. - - Definition: - - <!ELEMENT max-resource-size EMPTY > - - Example: - - <C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"/> - -7.3. Response to a POST request - - A POST request can return freebusy information for one or more - Calendar Users. Thus the response needs to contain separate status - information for each recipient. This specification defines a new XML - response body to convey multiple recipient status. - - A response to a POST method that indicates status for one or more - recipients MUST be an XML document with a CALDAV:schedule-response - XML element as its root element. This element MUST contain one - CALDAV:response element for each recipient, with each of those - containing elements that indicate which recipient they correspond to, - the scheduling status for that recipient, any error codes and an - optional description. See Section 14.1 for the detail on the child - elements. - - In the case of a successful freebusy request, the CALDAV:response - elements can also contain CALDAV:calendar-data elements which contain - freebusy information (e.g., an iCalendar VFREEBUSY component) - indicating the busy state of the corresponding recipient. See - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 38] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Appendix B.5 for an example freebusy request and response. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 39] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -8. Avoiding Conflicts when Updating Scheduling Object Resources - - Because replies from Attendees and updates from Organizers are - automatically processed by the server, clients might be in a - situation where their copy of a calendar resource is different from - the one currently on the server. When an Attendee or Organizer makes - a change to the client's copy of the calendar resource, if the client - writes the data to the server it could overwrite the changes already - made there. Typically, clients use the ETag value and If-Match - request headers to avoid the "lost update problem". - - Clients can also use ETag and If-Match to avoid this problem. - However, when doing so the client will likely have to resolve the - differences between the new resource and the original one, and the - changes made by the Attendee or Organizer in the client. This can be - a complicated comparison particularly when recurring components are - present. - - Additionally, the data on the server may change frequently as - Attendees change their participation status, triggering updates to - the Organizer, and consequently other Attendees' copies of the - scheduling object resource. If the ETag/If-Match behavior were used, - clients would be forced to reconcile their cached copy of a - scheduling object resource with the updated one on the server in - order to attempt to write the user's changes back. This could lead - to a race condition that can effectively result in a temporary denial - of service when, for example, there is an event with a large Attendee - list. A "storm" of updates will occur if Attendees all start - responding at the same time, and this would prevent Attendees and the - Organizer from being able to update their own copies of the - scheduling object resource as the server copy is changing frequently. - - A solution is to have the server determine the best way to merge - changes made on the server with changes being made by the client. - For example, if an Attendee changes their participation status and - triggers an update to the Organizer's copy of the event, but the - Organizer also updates their cached copy of the event and attempts to - write it back, rather than failing on a conditional If-Match when the - Organizer writes their data, the server would instead take the - changes made by the Organizer and apply the Attendee changes and - store the result. Thus a form of "weak" ETag matching behavior is - needed such that scheduling changes made automatically on the server - do not invalidate the tag, so that when clients store data - conditionally based on the tag value, the server knows it can apply - the merge behavior. - - In order to do that, this specification introduces a new WebDAV - resource property CALDAV:schedule-tag with a corresponding response - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 40] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request - header to allow client changes to be appropriately merged with server - changes in the case where the changes on the server were the result - of an "inconsequential" scheduling message update. An - "inconsequential" scheduling message is one which simply updates the - status information of Attendees due to a reply from an Attendee. - - Servers MUST support requests targeted at scheduling object resources - using the "If-Schedule-Tag-Match" request header. Consequently, the - server MUST support the "Schedule-Tag" response header and CALDAV: - schedule-tag property for scheduling object resources. Servers MUST - automatically resolve conflicts with "inconsequential" changes done - to scheduling object resources when the "If-Schedule-Tag-Match" - request header is specified. - - The If-Schedule-Tag-Match request header applies only to the Request- - URI, and not to the Destination of a COPY or MOVE in the same way as - the If-Match request header. - - Clients SHOULD use the If-Schedule-Tag-Match header on requests that - update scheduling object resources. - - A response to any successful GET or PUT request targeting a - scheduling object resource MUST include a Schedule-Tag response - header with the value set to the same value as the CALDAV:schedule- - tag WebDAV property of the resource. - - A response to any successful COPY or MOVE request that specifies a - Destination request header targeting a scheduling object resource - MUST include a Schedule-Tag response header with the value set to the - same value as the CALDAV:schedule-tag WebDAV property of the resource - identified in the Request-URI. - - The Schedule-Tag feature is designed to be used to address the - problem of "inconsequential" changes on the server only. Normal ETag - operations are used in all other cases, e.g., for synchronization. - - The value of the CALDAV:schedule-tag property changes according to - these rules: - - o For an Organizer's copy of a scheduling object resource: - - 1. The server MUST NOT change the CALDAV:schedule-tag property - value when the scheduling object resource is updated as the - result of automatically processing a scheduling message reply - from an Attendee. For instance, when an Attendee replies to - the Organizer, the CALDAV:schedule-tag property is unchanged - after the Organizer's scheduling object resource has been - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 41] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - automatically updated by the server with the Attendee's new - participation status. - - 2. The server MUST change CALDAV:schedule-tag property value when - the scheduling object resource is changed directly via an HTTP - request (e.g., PUT, COPY or MOVE). - - o For an Attendee's copy of a scheduling object resource: - - 1. The server MUST change the CALDAV:schedule-tag property value - when the scheduling object resource is changed as the result - of processing a scheduling message update from an Organizer - that contains changes other than just the participation status - of Attendees. - - 2. The server MUST NOT change the CALDAV:schedule-tag property - value when the scheduling object resource is changed as the - result of processing a scheduling message update from an - Organizer that only specify changes in the participation - status of Attendees. For instance, when Attendee "A" replies - to Organizer "O", and Attendee "B" receives a scheduling - message update from Organizer "O" with the new participation - status of Attendee "A", the CALDAV:schedule-tag property of - Attendee "B"s scheduling object resource MUST NOT be changed. - - 3. The server MUST change the CALDAV:schedule-tag property value - when the scheduling object resource is changed directly via an - HTTP request (e.g., PUT, COPY or MOVE). - -8.1. PUT - - Clients can use the If-Schedule-Tag-Match request header to do a PUT - request that ensures that "inconsequential" changes on the server do - not result in a precondition error. The value of the request header - is set to the last Schedule-Tag value received for the resource being - modified. If the value of the If-Schedule-Tag-Match header matches - the current value of the CALDAV:schedule-tag property the server MUST - take any "ATTENDEE" property changes for all Attendees other than the - owner of the scheduling object resource and apply those to the new - resource being stored. Otherwise, the server MUST fail the request - with a 412 Precondition Failed status code. - -8.2. DELETE, COPY or MOVE - - Clients can use the If-Schedule-Tag-Match request header to do a - DELETE, COPY or MOVE request that ensures that "inconsequential" - changes on the server do not result in a precondition error. The - value of the request header is set to the last Schedule-Tag value - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 42] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - received for the resource being deleted. If the value of the If- - Schedule-Tag-Match header matches the current value of the CALDAV: - schedule-tag property the server performs the normal DELETE, COPY or - MOVE request processing for the resource. Otherwise, the server MUST - fail the request with a 412 Precondition Failed status code. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 43] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -9. Other Scheduling Considerations - -9.1. Attendee Participation Status - - This section specifies additional requirements on the handling of the - "PARTSTAT" property parameter when the "SCHEDULE-AGENT" property - parameter on the corresponding "ATTENDEE" property is set to the - value "SERVER" or is not present. - - Clients SHOULD, and servers MUST reset the "PARTSTAT" property - parameter value of all "ATTENDEE" properties, except the one that - corresponds to the Organizer, to "NEEDS-ACTION" when the Organizer - reschedules an event. - - A reschedule of an event occurs when any "DTSTART", "DTEND", - "DURATION", "DUE", "RRULE", "RDATE", or "EXDATE" property changes in - a calendar component such that existing recurrence instances are - impacted by the changes, as shown in the table below. - - +-----------+-------------------------------------------------------+ - | Property | Server Action | - +-----------+-------------------------------------------------------+ - | DTSTART, | Any change to these properties MUST result in | - | DTEND, | "PARTSTAT" being set to "NEEDS-ACTION" | - | DURATION, | | - | DUE | | - | | | - | | | - | | | - | RRULE | A change to or addition of this property that results | - | | in the addition of new recurring instances or a | - | | change in time for existing recurring instances MUST | - | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on | - | | each affected component. | - | | | - | | | - | | | - | RDATE | A change to or addition of this property that results | - | | in the addition of new recurring instances or a | - | | change in time for existing recurring instances MUST | - | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on | - | | each affected component. | - | | | - | | | - | | | - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 44] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - | EXDATE | A change to or removal of this property that results | - | | in the re-instatement of recurring instances MUST | - | | result in "PARTSTAT" being set to "NEEDS-ACTION" on | - | | each affected component. | - +-----------+-------------------------------------------------------+ - - The server MAY allow the Organizer's client to change an Attendee's - "PARTSTAT" property parameter value to "NEEDS-ACTION" at any other - time (e.g., when the "LOCATION" property value changes, an Organizer - might wish to re-invite Attendees who may be impacted by the change). - -9.2. Schedule Status Values - - When scheduling with an Attendee there are two types of status - information that can be returned during the transaction. The first - type of status information is a "delivery" status that indicates - whether the scheduling message from the Organizer to the Attendee was - delivered or not, or what the current status of delivery is. The - second type of status information is a "reply" status corresponding - to the Attendee's own "REQUEST-STATUS" information from the - scheduling message reply that is sent back to the Organizer. - - Similarly, when an Attendee sends a reply back to the Organizer, - there will be "delivery" status information for the scheduling - message sent to the Organizer. However, there is no "REQUEST-STATUS" - sent back by the Organizer, so there is no equivalent of the "reply" - status as per scheduling messages to Attendees. - - The "delivery" status information on an "ORGANIZER" or "ATTENDEE" - iCalendar property is conveyed in the "SCHEDULE-STATUS" property - parameter value (Section 10.3). The status code value for "delivery" - status can be one of the following: - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 45] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - +----------+--------------------------------------------------------+ - | Delivery | Description | - | Status | | - | Code | | - +----------+--------------------------------------------------------+ - | 1.0 | The scheduling message is pending. i.e. the server is | - | | still in the process of sending the message. The | - | | status code value can be expected to change once the | - | | server has completed its sending and delivery | - | | attempts. | - | | | - | | | - | | | - | 1.1 | The scheduling message has been successfully sent. | - | | However, the server does not have explicit information | - | | about whether the scheduling message was successfully | - | | delivered to the recipient. This state can occur with | - | | "store and forward" style scheduling protocols such as | - | | iMIP [RFC6047] (iTIP using email). | - | | | - | | | - | | | - | 1.2 | The scheduling message has been successfully | - | | delivered. | - | | | - | | | - | | | - | 3.7 | The scheduling message was not delivered because the | - | | server did not recognize the calendar user address as | - | | a valid calendar user. Note that this code applies to | - | | both Organizer and Attendee calendar user addresses. | - | | | - | | | - | | | - | 3.8 | The scheduling message was not delivered due to | - | | insufficient privileges. Note that this code applies | - | | to both privileges granted by both the Organizer and | - | | Attendee calendar users. | - | | | - | | | - | | | - | 5.1 | The scheduling message was not delivered because the | - | | server could not complete delivery of the message. | - | | This is likely due to a temporary failure, and the | - | | originator can try to send the message again at a | - | | later time. | - | | | - | | | - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 46] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - | 5.2 | The scheduling message was not delivered because the | - | | server was not able to find a suitable way to deliver | - | | the message. This is likely a permanent failure, and | - | | the originator should not try to send the message | - | | again, at least without verifying/correcting the | - | | calendar user address of the recipient. | - | | | - | | | - | | | - | 5.3 | The scheduling message was not delivered and was | - | | rejected because scheduling with that recipient is not | - | | allowed. This is likely a permanent failure, and the | - | | originator should not try to send the message again. | - +----------+--------------------------------------------------------+ - - The status code for "reply" status can be any of the valid iTIP - [RFC5546] "REQUEST-STATUS" values. - - The 1.xx "REQUEST-STATUS" codes are new. This specification modifies - item (2) of Section 3.6 of [RFC5546] by adding the following - restriction: - - For a 1.xx code, all components MUST have exactly the same code. - - Definition of the new 1.xx codes is as follows: - -9.2.1. Status Code 1.0 - - Status Code: 1.0 - - Status Description: Pending. - - Status Exception Data: None. - - Description: Delivery of the iTIP message is pending. - -9.2.2. Status Code 1.1 - - Status Code: 1.1 - - Status Description: Sent. - - Status Exception Data: None. - - Description: The iTIP message has been sent, though no information - about successful delivery is known. - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 47] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -9.2.3. Status Code 1.2 - - Status Code: 1.2 - - Status Description: Delivered. - - Status Exception Data: None. - - Description: The iTIP message has been sent and delivered. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 48] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -10. Additional iCalendar Property Parameters - - This specification defines additional iCalendar property parameters - to support the CalDAV scheduling extensions. - -10.1. Schedule Agent Parameter - - Parameter Name: SCHEDULE-AGENT - - Purpose: To specify the agent expected to deliver scheduling - messages to the corresponding Organizer or Attendee. - - Format Definition: This property parameter is defined by the - following notation: - - scheduleagentparam = "SCHEDULE-AGENT" "=" - ("SERVER" ; The server handles scheduling - / "CLIENT" ; The client handles scheduling - / "NONE" ; No scheduling - / x-name ; Experimental type - / iana-token) ; Other IANA registered type - ; - ; Default is SERVER - - Description: This property parameter MAY be specified on "ORGANIZER" - or "ATTENDEE" iCalendar properties. In the absence of this - parameter, the value "SERVER" MUST be used for the default - behavior. The value determines whether or not an automatic - scheduling transaction on a server will cause a scheduling message - to be sent to the corresponding Calendar User identified by the - "ORGANIZER" or "ATTENDEE" property value. When the value "SERVER" - is specified, or the parameter is absent, then it is the server's - responsibility to send a scheduling message as part of an - automatic scheduling transaction. When the value "CLIENT" is - specified, that indicates that the client is handling scheduling - messages with the Calendar User itself. When "NONE" is specified, - no scheduling messages are being sent to the Calendar User. - - Servers MUST NOT include this parameter in any scheduling messages - sent as the result of an automatic scheduling transaction. - - Clients MUST NOT include this parameter in any scheduling messages - that they themselves send. - - The parameter value MUST be the same on every "ORGANIZER" property - in a scheduling object resource. - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 49] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - The parameter value MUST be the same on each "ATTENDEE" property - whose values match in a scheduling object resource. - - Servers and clients MUST treat x-name and iana-token values they - do not recognize the same way as they would the "NONE" value. - - Example: - - ORGANIZER;SCHEDULE-AGENT=SERVER:mailto:bernard@example.com - - ATTENDEE;SCHEDULE-AGENT=NONE:mailto:cyrus@example.com - -10.2. Schedule Force Send Parameter - - Parameter Name: SCHEDULE-FORCE-SEND - - Purpose: To force a scheduling message to be sent to the Calendar - User specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - scheduleforcesendparam = "SCHEDULE-FORCE-SEND" "=" - ("REQUEST" ; Force a "REQUEST" - / "REPLY" ; Force a "REPLY" - / iana-token) ; IANA registered method - - Description: This property parameter MAY be specified on "ATTENDEE" - and "ORGANIZER" properties on which the "SCHEDULE-AGENT" property - parameter is set to the value "SERVER" or is not specified. This - property parameter is used to force a server to send a scheduling - message to a specific Calendar User in situations where the server - would not send a scheduling message otherwise (e.g., when no - change that warrants the delivery of a new scheduling message was - performed on the scheduling object resource). An Organizer MAY - specify this parameter on an "ATTENDEE" property with the value - "REQUEST" to force a "REQUEST" scheduling message to be sent to - this Attendee. An Attendee MAY specify this parameter on the - "ORGANIZER" with the value "REPLY" to force a "REPLY" scheduling - message to be sent to the Organizer. - - Servers MUST NOT preserve this property parameter in scheduling - object resources, nor include it in any scheduling messages sent - as the result of an automatic scheduling transaction. - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 50] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Clients MUST NOT include this parameter in any scheduling messages - that they themselves send. - - Servers MUST set the "SCHEDULE-STATUS" parameter of the "ATTENDEE" - or "ORGANIZER" to 2.3 (i.e., "Success, invalid property parameter - ignored", see Section 3.6 of [RFC5546]) when the "SCHEDULE-FORCE- - SEND" parameter is set to a x-name or iana-token value they do not - recognize. - - Example: - - ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard@example.com - - ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:cyrus@example.com - -10.3. Schedule Status Parameter - - Parameter Name: SCHEDULE-STATUS - - Purpose: To specify the status codes returned from processing of the - most recent scheduling message sent to the corresponding Attendee, - or received from the corresponding Organizer. - - Format Definition: This property parameter is defined by the - following notation: - - schedulestatusparam = "SCHEDULE-STATUS" "=" - ( statcode - / DQUOTE statcode *("," statcode) DQUOTE) - ; "statcode" is defined in Section 3.8.8.3 of - ; [RFC5545]. Value is a single - ; "statcode" or a comma-separated list of "statcode" values. - - Description: This property parameter MAY be specified on the - "ATTENDEE" and "ORGANIZER" properties. - - Servers MUST add this property parameter to any "ATTENDEE" - properties corresponding to Calendar Users who were sent a - scheduling message via an automatic scheduling transaction. - Clients SHOULD NOT change or remove this parameter if it was - provided by the server. In the case where the client is handling - the scheduling, the client MAY add, change or remove this - parameter to indicate the last scheduling message status it - received. - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 51] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Servers MUST add this parameter to any "ORGANIZER" properties - corresponding to Calendar Users who were sent a scheduling message - reply by an Attendee via an automatic scheduling transaction. - Clients SHOULD NOT change or remove this parameter if it was - provided by the server. In the case where the client is handling - the scheduling, the client MAY add, change or remove this - parameter to indicate the last scheduling message status it - received. - - Servers MUST NOT include this parameter in any scheduling messages - sent as the result of an automatic scheduling transaction. - - Clients MUST NOT include this parameter in any scheduling messages - that they themselves send. - - Suitable values for this property parameter are described in - Section 9.2. - - Example: - - ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com - - ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 52] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -11. Additional Message Header Fields - - This specification defines additional HTTP request and response - headers for use with CalDAV. - -11.1. Schedule-Reply Request Header - - - Schedule-Reply = "Schedule-Reply" ":" ("T" | "F") - - Example: - - Schedule-Reply: F - - When an Attendee removes a scheduling object resource, and the - Schedule-Reply header is not present, or present and set to the value - "T", the server MUST send an appropriate reply scheduling message - with the Attendee's "PARTSTAT" iCalendar property parameter value set - to "DECLINED" as part of its normal automatic scheduling transaction - processing. - - When the Schedule-Reply header is set to the value "F", the server - MUST NOT send a scheduling message as part of its normal automatic - scheduling transaction processing. - - The Schedule-Reply request header is used by a client to indicate to - a server whether or not an automatic scheduling transaction should - occur when an Attendee deletes a scheduling object resource. In - particular it controls whether a reply scheduling message is sent to - the Organizer as a result of the removal. There are situations in - which unsolicited scheduling messages need to be silently removed (or - ignored) for security or privacy reasons. This request header allows - the scheduling object resource to be removed if such a need arises. - - All scheduling object resources MUST support the Schedule-Reply - request header. - -11.2. Schedule-Tag Response Header - - The Schedule-Tag response header provides the current value of the - CALDAV:schedule-tag property value. The behavior of this response - header is described in Section 8. - - All scheduling object resources MUST support the Schedule-Tag header. - - Schedule-Tag = "Schedule-Tag" ":" opaque-tag - ; "opaque-tag" is defined in Section 3.11 of [RFC2616] - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 53] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Example: - - Schedule-Tag: "12ab34-cd56ef" - -11.3. If-Schedule-Tag-Match Request Header - - The If-Schedule-Tag-Match request header field is used with a method - to make it conditional. Clients can set this header to the value - returned in the Schedule-Tag response header, or the CALDAV:schedule- - tag property, of a scheduling object resource previously retrieved - from the server to avoid overwriting "consequential" changes to the - scheduling object resource. - - All scheduling object resources MUST support the If-Schedule-Tag- - Match header. - - If-Schedule-Tag-Match = "If-Schedule-Tag-Match" ":" opaque-tag - ; "opaque-tag" is defined in Section 3.11 of [RFC2616] - - Example: - - If-Schedule-Tag-Match: "12ab34-cd56ef" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 54] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -12. Additional WebDAV Properties - - This specification defines the following new WebDAV properties for - use with CalDAV. - -12.1. CALDAV:schedule-calendar-transp Property - - Name: schedule-calendar-transp - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Determines whether the calendar object resources in a - calendar collection will affect the owner's freebusy. - - Protected: This property MAY be protected and SHOULD NOT be returned - by a PROPFIND allprop request (as defined in Section 14.2 of - [RFC4918]). - - COPY/MOVE behavior: This property value SHOULD be kept during a MOVE - operation, and SHOULD be copied and preserved in a COPY. - - Description: This property SHOULD be defined on all calendar - collections. If present, it contains one of two XML elements that - indicate whether the calendar object resources in the calendar - collection should contribute to the owner's freebusy or not. When - the CALDAV:opaque element is used, all calendar object resources - in the corresponding calendar collection MUST contribute to - freebusy, assuming access privileges and other iCalendar - properties allow it to. When the CALDAV:transparent XML element - is used, the calendar object resources in the corresponding - calendar collection MUST NOT contribute to freebusy. - - If this property is not present on a calendar collection, then the - default value CALDAV:opaque MUST be assumed. - - Definition: - - <!ELEMENT schedule-calendar-transp (opaque | transparent) > - - <!ELEMENT opaque EMPTY> - <!-- Affect busy time searches --> - - <!ELEMENT transparent EMPTY> - <!-- Invisible to busy time searches --> - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 55] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Example: - - <C:schedule-calendar-transp - xmlns:C="urn:ietf:params:xml:ns:caldav"> - <C:opaque/> - </C:schedule-calendar-transp> - -12.2. CALDAV:schedule-default-calendar-URL Property - - Name: schedule-default-calendar-URL - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Specifies a default calendar for an Attendee where new - scheduling object resources are created. - - Protected: This property MAY be protected in the case where a server - does not support changing the default calendar, or does not - support a default calendar. - - COPY/MOVE behavior: This property is only defined on a scheduling - Inbox collection which cannot be moved or copied. - - Description: This property MAY be defined on a scheduling Inbox - collection. If present, it contains zero or one DAV:href XML - elements. When a DAV:href element is present, its value indicates - a URL to a calendar collection that is used as the default - calendar. When no DAV:href element is present, it indicates that - there is no default calendar. In the absence of this property - there is no default calendar. When there is no default calendar - the server is free to choose the calendar in which a new - scheduling object resource is created. See Section 6.4. - - Definition: - - <!ELEMENT schedule-default-calendar-URL (DAV:href?) > - - Example: - - <C:schedule-default-calendar-URL xmlns:D="DAV:" - xmlns:C="urn:ietf:params:xml:ns:caldav"> - <D:href>/home/cyrus/calendars/work/</D:href> - </C:schedule-default-calendar-URL> - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 56] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -12.3. CALDAV:schedule-tag Property - - Name: schedule-tag - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Indicates whether a scheduling object resource has had a - "consequential" change made to it. - - Value: opaque-tag (defined in Section 3.11 of [RFC2616]) - - Protected: This property MUST be protected as only the server can - update the value. - - COPY/MOVE behavior: This property is only defined on scheduling - object resources. It MUST be preserved when a scheduling object - resource is copied or moved and the resulting resource is also a - scheduling object resource. If the source resource is not a - scheduling object resource but the destination resource is, this - property MUST be added to the destination resource. - - Description: The CALDAV:schedule-tag property MUST be defined on all - scheduling object resources. This property is described in - Section 8. - - Definition: - - <!ELEMENT schedule-tag (#PCDATA) > - - Example: - - <C:schedule-tag xmlns:C="urn:ietf:params:xml:ns:caldav" - >"12345-67890"</C:schedule-tag> - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 57] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -13. Scheduling Access Control - -13.1. Scheduling Privileges - - CalDAV servers MUST support and adhere to the requirements of WebDAV - ACL [RFC3744]. Furthermore, CalDAV servers that advertise support - for the "calendar-auto-schedule" feature MUST also support the - scheduling privileges defined in this section. - - All the scheduling privileges MUST be non-abstract and MUST appear in - the DAV:supported-privilege-set property of scheduling Outbox and - Inbox collections on which they are defined. - - The tables specified in Appendix A clarify which scheduling methods - (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling - privilege defined in this section. - -13.1.1. Privileges on Scheduling Inbox Collections - - This section defines new WebDAV ACL privileges that are for use on - scheduling Inbox collections. These privileges determine whether - delivery of scheduling messages from a calendar user is allowed by - the calendar user who "owns" the scheduling Inbox collection. This - allows calendar users to choose which other calendar users can - schedule with them. - - Note that when a scheduling message is delivered to a calendar user, - in addition to a scheduling object resource being created in the - calendar user's scheduling Inbox collection, a new scheduling object - resource might be created or an existing one updated in a calendar - belonging to the calendar user. In that case, the ability to create - or update the scheduling object resource in the calendar is - controlled by the privileges assigned to the scheduling Inbox - collection. - - The privileges defined in this section are ignored if applied to a - resource other than a scheduling Inbox collection. - -13.1.1.1. CALDAV:schedule-deliver Privilege - - CALDAV:schedule-deliver is an aggregate privilege that contains all - the scheduling privileges that control the processing and delivery of - incoming scheduling messages, that is, CALDAV:schedule-deliver-invite - and CALDAV:schedule-deliver-reply, as well as freebusy requests - targeted at the owner of the scheduling Inbox collection, that is, - CALDAV:schedule-query-freebusy. - - <!ELEMENT schedule-deliver EMPTY > - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 58] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -13.1.1.2. CALDAV:schedule-deliver-invite Privilege - - The CALDAV:schedule-deliver-invite privilege controls the processing - and delivery of scheduling messages coming from an Organizer. - - <!ELEMENT schedule-deliver-invite EMPTY > - -13.1.1.3. CALDAV:schedule-deliver-reply Privilege - - The CALDAV:schedule-deliver-reply privilege controls the processing - and delivery of scheduling messages coming from an Attendee. - - <!ELEMENT schedule-deliver-reply EMPTY > - -13.1.1.4. CALDAV:schedule-query-freebusy Privilege - - The CALDAV:schedule-query-freebusy privilege controls freebusy - requests targeted at the owner of the scheduling Inbox collection. - - <!ELEMENT schedule-query-freebusy EMPTY > - -13.1.2. Privileges on Scheduling Outbox Collections - - This section defines new WebDAV ACL privileges that are defined for - use on scheduling Outbox collections. These privileges determine - which calendar users are allowed to send scheduling messages on - behalf of the calendar user who "owns" the scheduling Outbox - collection. This allows calendar users to choose other calendar - users who can act on their behalf to send schedule messages to other - calendar users (e.g. assistants working on behalf of their boss). - - The privileges defined in this section are ignored if applied to a - resource other than a scheduling Outbox collection. - -13.1.2.1. CALDAV:schedule-send Privilege - - CALDAV:schedule-send is an aggregate privilege that contains all the - scheduling privileges that control the use of methods that will cause - scheduling messages to be delivered to other users, that is, CALDAV: - schedule-send-invite and CALDAV:schedule-send-reply, as well as - freebusy requests to be targeted at other users, that is, CALDAV: - schedule-send-freebusy. - - <!ELEMENT schedule-send EMPTY > - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 59] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -13.1.2.2. CALDAV:schedule-send-invite Privilege - - The CALDAV:schedule-send-invite privilege controls the sending of - scheduling messages by Organizers. - - Users granted the DAV:bind privilege on a calendar collection, or - DAV:write privilege on scheduling object resources, will also need - the CALDAV:schedule-send-invite privilege granted on the scheduling - Outbox collection of the owner of the calendar collection or - scheduling object resource in order to be allowed to create, modify - or delete scheduling object resources in a way that will trigger the - CalDAV server to deliver organizer scheduling messages to other - calendar users. - - <!ELEMENT schedule-send-invite EMPTY > - -13.1.2.3. CALDAV:schedule-send-reply Privilege - - The CALDAV:schedule-send-reply privilege controls the sending of - scheduling messages by Attendees. - - Users granted the DAV:bind privilege on a calendar collection, or - DAV:write privilege on scheduling object resources, will also need - the CALDAV:schedule-send-reply privilege granted on the scheduling - Outbox collection of the owner of the calendar collection or - scheduling object resource in order to be allowed to create, modify - or delete scheduling object resources in a way that will trigger the - CalDAV server to deliver attendee scheduling messages to other - calendar users. - - <!ELEMENT schedule-send-reply EMPTY > - -13.1.2.4. CALDAV:schedule-send-freebusy Privilege - - The CALDAV:schedule-send-freebusy privilege controls the use of the - POST method to submit scheduling messages that specify the scheduling - method "REQUEST" with a "VFREEBUSY" calendar component. - - <!ELEMENT schedule-send-freebusy EMPTY > - -13.1.3. Aggregation of Scheduling Privileges - - Server implementations MUST aggregate the scheduling privileges as - follows: - - DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule- - deliver; - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 60] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite, - CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy; - - CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver- - invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query- - freebusy. - - The following diagram illustrates how scheduling privileges are - aggregated according to the above requirements. - - [DAV:all] (aggregate) - | - +-- [CALDAV:schedule-deliver] (aggregate) - | | - | +-- [CALDAV:schedule-deliver-invite] - | +-- [CALDAV:schedule-deliver-reply] - | +-- [CALDAV:schedule-query-freebusy] - | - +-- [CALDAV:schedule-send] (aggregate) - | - +-- [CALDAV:schedule-send-invite] - +-- [CALDAV:schedule-send-reply] - +-- [CALDAV:schedule-send-freebusy] - -13.2. Additional Principal Properties - - This section defines new properties for WebDAV principal resources as - defined in [RFC3744]. These properties are likely to be protected - but the server MAY allow them to be written by appropriate users. - -13.2.1. CALDAV:schedule-inbox-URL Property - - Name: schedule-inbox-URL - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Identify the URL of the scheduling Inbox collection owned - by the associated principal resource. - - Protected: This property MAY be protected. - - PROPFIND behavior: This property SHOULD NOT be returned by a - PROPFIND allprop request (as defined in Section 14.2 of - [RFC4918]). - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 61] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - COPY/MOVE behavior: This property value SHOULD be preserved in COPY - and MOVE operations. - - Description: This property is needed for a client to determine where - the scheduling Inbox collection of the current user is located so - that processing of scheduling messages can occur. If not present, - then the associated calendar user is not enabled for reception of - scheduling messages on the server. - - Definition: - - <!ELEMENT schedule-inbox-URL (DAV:href)> - -13.2.2. CALDAV:schedule-outbox-URL Property - - Name: schedule-outbox-URL - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Identify the URL of the scheduling Outbox collection owned - by the associated principal resource. - - Protected: This property MAY be protected. - - PROPFIND behavior: This property SHOULD NOT be returned by a - PROPFIND allprop request (as defined in Section 14.2 of - [RFC4918]). - - COPY/MOVE behavior: This property value SHOULD be preserved in COPY - and MOVE operations. - - Description: This property is needed for a client to determine where - the scheduling Outbox collection of the current user is located so - that sending of scheduling messages can occur. If not present, - then the associated calendar user is not enabled for the sending - of scheduling messages on the server. - - Definition: - - <!ELEMENT schedule-outbox-URL DAV:href> - -13.2.3. CALDAV:calendar-user-address-set Property - - Name: calendar-user-address-set - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 62] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Identify the calendar addresses of the associated principal - resource. - - Protected: This property MAY be protected. - - PROPFIND behavior: This property SHOULD NOT be returned by a - PROPFIND allprop request (as defined in Section 14.2 of - [RFC4918]). - - COPY/MOVE behavior: This property value SHOULD be preserved in COPY - and MOVE operations. - - Description: Support for this property is REQUIRED. This property - is needed to map calendar user addresses in iCalendar data to - principal resources and their associated scheduling Inbox and - Outbox collections. In the event that a user has no well defined - identifier for their calendar user address, the URI of their - principal resource can be used. This property SHOULD be - searchable using the DAV:principal-property-search REPORT. The - DAV:principal-search-property-set REPORT SHOULD identify this - property as such. If not present, then the associated calendar - user is not enabled for scheduling on the server. - - Definition: - - <!ELEMENT calendar-user-address-set (DAV:href*)> - - Example: - - <C:calendar-user-address-set xmlns:D="DAV:" - xmlns:C="urn:ietf:params:xml:ns:caldav"> - <D:href>mailto:bernard@example.com</D:href> - <D:href>mailto:bernard.desruisseaux@example.com</D:href> - </C:calendar-user-address-set> - -13.2.4. CALDAV:calendar-user-type Property - - Name: calendar-user-type - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Identifies the calendar user type of the associated - principal resource. - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 63] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Value: Same values allowed for the iCalendar "CUTYPE" property - parameter defined in Section 3.2.3 of [RFC5545]. - - Protected: This property MAY be protected. - - PROPFIND behavior: This property SHOULD NOT be returned by a - PROPFIND allprop request (as defined in Section 14.2 of - [RFC4918]). - - COPY/MOVE behavior: This property value SHOULD be preserved in COPY - and MOVE operations. - - Description: Clients can query principal resources in order to - lookup attendees available on the server. When doing this, it is - useful to know, or restrict the query to, certain types of - calendar user (e.g., only search for "people", or only search for - "rooms"). This property MAY be defined on principal resources to - indicate the type of calendar user associated with the principal - resource. Its value is the same as the iCalendar "CUTYPE" - property parameter that can be used on "ATTENDEE" properties. - This property SHOULD be searchable using the DAV:principal- - property-search REPORT. The DAV:principal-search-property-set - REPORT SHOULD identify this property as such. - - Definition: - - <!ELEMENT calendar-user-type (#PCDATA) > - - Example: - - <C:calendar-user-type - xmlns:C="urn:ietf:params:xml:ns:caldav">INDIVIDUAL< - /C:calendar-user-type> - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 64] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -14. XML Element Definitions - -14.1. CALDAV:schedule-response XML Element - - Name: schedule-response - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Contains the set of responses for a POST method request. - - Description: See Section 7.3. - - Definition: - - <!ELEMENT schedule-response (response*)> - -14.2. CALDAV:response XML Element - - Name: response - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: Contains a single response for a POST method request. - - Description: See Section 7.3. - - Definition: - - <!ELEMENT response (recipient, - request-status, - calendar-data?, - DAV:error?, - DAV:responsedescription?)> - - <!-- CALDAV:calendar-data is defined in Section 9.6 of - RFC 4791 and when used here uses the definition with - content (#PCDATA) only --> - -14.3. CALDAV:recipient XML Element - - Name: recipient - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: The calendar user address that the enclosing response for a - POST method request is for. - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 65] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Description: See Section 7.3. - - Definition: - - <!ELEMENT recipient (DAV:href)> - -14.4. CALDAV:request-status XML Element - - Name: request-status - - Namespace: urn:ietf:params:xml:ns:caldav - - Purpose: The iTIP "REQUEST-STATUS" property value for this response. - - Description: See Section 7.3. - - Definition: - - <!ELEMENT request-status (#PCDATA) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 66] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -15. Security Considerations - - The process of scheduling involves the sending and receiving of - scheduling messages. As a result, the security problems related to - messaging in general are relevant here. In particular the - authenticity of the scheduling messages needs to be verified. - Servers and clients MUST use an HTTP connection protected with TLS as - defined in [RFC2818] for all scheduling transactions. - -15.1. Verifying Scheduling Transactions - - When handling a scheduling transaction: - - Servers MUST verify that the principal associated with the DAV: - owner of the calendar collection in which a scheduling object - resource is being manipulated contains a CALDAV:schedule-outbox- - URL property value. - - Servers MUST verify that the currently authenticated user has the - CALDAV:schedule-send privilege, or a suitable sub-privilege - aggregated under this privilege, on the scheduling Outbox - collection of the DAV:owner of the calendar collection in which a - scheduling object resource is being manipulated. - - Servers MUST only deliver scheduling messages to recipients when - the CALDAV:schedule-deliver privilege, or a suitable sub-privilege - aggregated under this privilege, is granted on the recipient's - scheduling Inbox collection for the principal associated with the - DAV:owner of the calendar collection in which a scheduling object - resource is being manipulated. - - To prevent impersonation of calendar users, the server MUST verify - that the "ORGANIZER" property in an organizer scheduling object - resource matches one of the calendar user addresses of the DAV: - owner of the calendar collection in which the resource is stored. - - To prevent spoofing of an existing scheduling object resource, - servers MUST verify that the "UID" iCalendar property value in a - new scheduling object resource does not match that of an existing - scheduling object resource with a different "ORGANIZER" property - value. - -15.2. Verifying Busy Time Information Requests - - When handling a POST request on a scheduling Outbox collection: - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 67] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Servers MUST verify that the principal associated with the - calendar user address specified in the "ORGANIZER" property of the - scheduling message data in the request contains a CALDAV:schedule- - outbox-URL property value that matches the scheduling Outbox - collection targeted by the request. - - Servers MUST verify that the currently authenticated user has the - CALDAV:schedule-send privilege, or a sub-privilege aggregated - under this privilege, on the scheduling Outbox collection targeted - by the request. - - Servers MUST only return valid freebusy information for recipients - when the CALDAV:schedule-deliver privilege, or a sub-privilege - aggregated under this privilege, is granted on the recipient's - scheduling Inbox collection for the principal associated with the - DAV:owner of the scheduling Outbox collection targeted by the - request. - -15.3. Privacy Issues - - As noted in Section 11.1, Attendees can use the Schedule-Reply - request header with the value set to "F" to prevent notification to - an Organizer that a scheduling object resource was deleted. This - allows Attendees to remove unwanted scheduling messages without any - response to the Organizer. - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 68] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -16. IANA Considerations - -16.1. Message Header Field Registrations - - The message header fields below should be added to the Permanent - Message Header Field Registry (see [RFC3864]). - -16.1.1. Schedule-Reply - - Header field name: Schedule-Reply - - Applicable protocol: http - - Status: standard - - Author/Change controller: IETF - - Specification document(s): this specification (Section 11.1) - - Related information: none - -16.1.2. Schedule-Tag - - Header field name: Schedule-Tag - - Applicable protocol: http - - Status: standard - - Author/Change controller: IETF - - Specification document(s): this specification (Section 11.2) - - Related information: none - -16.1.3. If-Schedule-Tag-Match - - Header field name: If-Schedule-Tag-Match - - Applicable protocol: http - - Status: standard - - Author/Change controller: IETF - - Specification document(s): this specification (Section 11.3) - - Related information: none - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 69] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -16.2. iCalendar Property Parameter Registrations - - The following iCalendar property parameters should be added to the - iCalendar Property Parameter Registry defined in Section 8.3.3 of - [RFC5545]. - - +---------------------+---------+-----------------------+ - | Parameter | Status | Reference | - +---------------------+---------+-----------------------+ - | SCHEDULE-AGENT | Current | RFCXXXX, Section 10.1 | - | | | | - | SCHEDULE-STATUS | Current | RFCXXXX, Section 10.3 | - | | | | - | SCHEDULE-FORCE-SEND | Current | RFCXXXX, Section 10.2 | - +---------------------+---------+-----------------------+ - -16.3. iCalendar REQUEST-STATUS Value Registrations - - The following iCalendar "REQUEST-STATUS" values should be added to - the iCalendar REQUEST-STATUS Value Registry defined in Section 7.3 of - [RFC5546]. - - +-------------+---------+-------------------------+ - | Status Code | Status | Reference | - +-------------+---------+-------------------------+ - | 1.0 | Current | RFC XXXX, Section 9.2.1 | - | | | | - | 1.1 | Current | RFC XXXX, Section 9.2.2 | - | | | | - | 1.2 | Current | RFC XXXX, Section 9.2.3 | - +-------------+---------+-------------------------+ - -16.4. Additional iCalendar Elements Registries - - This specification adds two new IANA registries for iCalendar - elements. Additional codes MAY be used, provided the process - described in Section 8.2.1 of [RFC5545] is used to register them. - -16.4.1. Schedule Agent Values Registry - - The following table has been used to initialize the schedule agent - values registry. - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 70] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - +----------------+---------+------------------------+ - | Schedule Agent | Status | Reference | - +----------------+---------+------------------------+ - | SERVER | Current | RFC XXXX, Section 10.1 | - | | | | - | CLIENT | Current | RFC XXXX, Section 10.1 | - | | | | - | NONE | Current | RFC XXXX, Section 10.1 | - +----------------+---------+------------------------+ - -16.4.2. Schedule Force Send Values Registry - - The following table has been used to initialize the schedule send - values registry. - - +---------------------+---------+------------------------+ - | Schedule Force Send | Status | Reference | - +---------------------+---------+------------------------+ - | REQUEST | Current | RFC XXXX, Section 10.2 | - | | | | - | REPLY | Current | RFC XXXX, Section 10.2 | - +---------------------+---------+------------------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 71] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -17. Acknowledgements - - The authors would like to thank the following individuals for - contributing their ideas and support for writing this specification: - Mike Douglass, Lisa Dusseault, Helge Hess, Arnaud Quillaud, Julian F. - Reschke, Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim - Whitehead. - - The authors would also like to thank the Calendaring and Scheduling - Consortium for advice with this specification, and for organizing - interoperability testing events to help refine it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 72] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -18. References - -18.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to - Indicate Requirement Levels", BCP 14, - RFC 2119, March 1997. - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, - H., Masinter, L., Leach, P., and T. Berners- - Lee, "Hypertext Transfer Protocol -- - HTTP/1.1", RFC 2616, June 1999. - - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, - May 2000. - - [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. - Whitehead, "Web Distributed Authoring and - Versioning (WebDAV) Access Control Protocol", - RFC 3744, May 2004. - - [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, - "Registration Procedures for Message Header - Fields", BCP 90, RFC 3864, September 2004. - - [RFC4791] Daboo, C., Desruisseaux, B., and L. - Dusseault, "Calendaring Extensions to WebDAV - (CalDAV)", RFC 4791, March 2007. - - [RFC4918] Dusseault, L., "HTTP Extensions for Web - Distributed Authoring and Versioning - (WebDAV)", RFC 4918, June 2007. - - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF - for Syntax Specifications: ABNF", STD 68, - RFC 5234, January 2008. - - [RFC5545] Desruisseaux, B., "Internet Calendaring and - Scheduling Core Object Specification - (iCalendar)", RFC 5545, September 2009. - - [RFC5546] Daboo, C., "iCalendar Transport-Independent - Interoperability Protocol (iTIP)", RFC 5546, - December 2009. - - [W3C.REC-xml-20081126] Paoli, J., Yergeau, F., Bray, T., Sperberg- - McQueen, C., and E. Maler, "Extensible Markup - Language (XML) 1.0 (Fifth Edition)", World - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 73] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - Wide Web Consortium Recommendation REC-xml- - 20081126, November 2008, - <http://www.w3.org/TR/2008/REC-xml-20081126>. - -18.2. Informative References - - [RFC3283] Mahoney, B., Babics, G., and A. Taler, "Guide - to Internet Calendaring", RFC 3283, - June 2002. - - [RFC6047] Melnikov, A., "iCalendar Message-Based - Interoperability Protocol (iMIP)", RFC 6047, - December 2010. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 74] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -Appendix A. Scheduling Privileges Summary - -A.1. Scheduling Inbox Privileges - - The following tables specify which scheduling privileges grant the - right to a calendar user to deliver a scheduling message to the - scheduling Inbox collection of another calendar user. The - appropriate behavior depends on the calendar component type as well - as the scheduling "METHOD" specified in the scheduling message. - - +--------------------------------+ - | METHOD for VEVENT and VTODO | - +-----------------------------+---------+-------+-----+--------+ - | Scheduling Inbox Privilege | REQUEST | REPLY | ADD | CANCEL | - +-----------------------------+---------+-------+-----+--------+ - | schedule-deliver | * | * | * | * | - | schedule-deliver-invite | * | | * | * | - | schedule-deliver-reply | | * | | | - | schedule-query-freebusy | | | | | - +-----------------------------+---------+-------+-----+--------+ - - - +----------------------+ - | METHOD for VFREEBUSY | - +-----------------------------+----------------------+ - | Scheduling Inbox Privilege | REQUEST | - +-----------------------------+----------------------+ - | schedule-deliver | * | - | schedule-deliver-invite | | - | schedule-deliver-reply | | - | schedule-query-freebusy | * | - +-----------------------------+----------------------+ - -A.2. Scheduling Outbox Privileges - - The following tables specify which scheduling privileges grant the - right to a Calendar User to perform busy time information requests - and to submit scheduling messages to other Calendar Users as the - result of a scheduling transaction. The appropriate behavior depends - on the calendar component type as well as the scheduling "METHOD" - specified in the scheduling message. - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 75] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - +--------------------------------+ - | METHOD for VEVENT and VTODO | - +-----------------------------+---------+-------+-----+--------+ - | Scheduling Outbox Privilege | REQUEST | REPLY | ADD | CANCEL | - +-----------------------------+---------+-------+-----+--------+ - | schedule-send | * | * | * | * | - | schedule-send-invite | * | | * | * | - | schedule-send-reply | | * | | | - | schedule-send-freebusy | | | | | - +-----------------------------+---------+-------+-----+--------+ - - - +----------------------+ - | METHOD for VFREEBUSY | - +-----------------------------+----------------------+ - | Scheduling Outbox Privilege | REQUEST | - +-----------------------------+----------------------+ - | schedule-send | * | - | schedule-send-invite | | - | schedule-send-reply | | - | schedule-send-freebusy | * | - +-----------------------------+----------------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 76] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -Appendix B. Example Scheduling Transactions - - This section describes some example scheduling transactions that give - a general idea of how scheduling is carried out between CalDAV - clients and servers from the perspective of meeting Organizers and - Attendees. - - In the following examples the requests and responses are incomplete - and are only for illustrative purposes. In particular, HTTP - authentication headers and behaviors are not shown, even though they - are required in normal operation. - -B.1. Example: Organizer Inviting Multiple Attendees - - In the following example, Cyrus invites Wilfredo, Bernard and Mike to - a single instance event by simply creating a new scheduling object - resource in one of his calendar collection by using the PUT method. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 77] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Request << - - PUT /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 - Host: cal.example.com - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - If-None-Match: * - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T185254Z - DTSTART:20090602T160000Z - DTEND:20090602T170000Z - TRANSP:OPAQUE - SUMMARY:Lunch - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT - =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@ - example.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex - ample.net - ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A - CTION;RSVP=TRUE:mailto:mike@example.org - END:VEVENT - END:VCALENDAR - - >> Response << - - HTTP/1.1 201 Created - Content-Length: 0 - Date: Tue, 02 Jun 2009 18:52:54 GMT - Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT - ETag: "d85561cfe74a4e785eb4639451b434fb" - Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" - - Once the event creation has been completed, Cyrus's client will - retrieve the event back from the server to get the schedule status of - each Attendee. In this example, the server reports that a scheduling - message was delivered to Wilfredo, a scheduling message is still - pending for Bernard, and the server was unable to deliver a - scheduling message to Mike. - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 78] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Request << - - GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 - Host: cal.example.com - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 18:52:58 GMT - Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT - ETag: "eb897deabc8939589da116714bc99265" - Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Server//EN - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T185300Z - DTSTART:20090602T160000Z - DTEND:20090602T170000Z - TRANSP:OPAQUE - SUMMARY:Lunch - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT - =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS= - 1.2:mailto:wilfredo@e - xample.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS= - 1.0:mailto:bernard@example.net - ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A - CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org - END:VEVENT - END:VCALENDAR - -B.2. Example: Attendee Receiving an Invitation - - In the following example, Wilfredo's client retrieves and deletes the - new scheduling message that appeared in his scheduling Inbox - collection after the server automatically processed it and created a - new scheduling object resource in his default calendar collection. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 79] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Request << - - GET /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1 - Host: cal.example.com - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 18:59:58 GMT - Last-Modified: Tue, 02 Jun 2009 18:59:58 GMT - ETag: "da116714bc9926c89395895eb897deab" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Server//EN - METHOD:REQUEST - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T185254Z - DTSTART:20090602T160000Z - DTEND:20090602T170000Z - TRANSP:OPAQUE - SUMMARY:Lunch - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT - =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@ - example.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex - ample.net - ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A - CTION;RSVP=TRUE:mailto:mike@example.org - END:VEVENT - END:VCALENDAR - - >> Request << - - DELETE /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1 - Host: cal.example.com - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 80] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Response << - - HTTP/1.1 204 No Content - Date: Tue, 02 Jun 2009 20:40:36 GMT - -B.3. Example: Attendee Replying to an Invitation - - In the following example, Wilfredo's accepts Cyrus's invitation and - sets a reminder on the event. - - >> Request << - - PUT /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1 - Host: cal.example.com - If-Schedule-Tag-Match: "e78f23ed-0188-4bab-938d-2aeb3324c7e8" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T185254Z - DTSTART:20090602T160000Z - DTEND:20090602T170000Z - TRANSP:OPAQUE - SUMMARY:Lunch - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT - =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam - ple.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex - ample.net - ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A - CTION;RSVP=TRUE:mailto:mike@example.org - BEGIN:VALARM - TRIGGER:-PT15M - ACTION:DISPLAY - DESCRIPTION:Reminder - END:VALARM - END:VEVENT - END:VCALENDAR - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 81] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Response << - - HTTP/1.1 200 OK - Content-Length: 0 - Date: Tue, 02 Jun 2009 18:57:54 GMT - Last-Modified: Tue, 02 Jun 2009 18:57:54 GMT - ETag: "eb4639451b434fbd85561cfe74a4e785" - Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41" - - Once the event modification has been completed, Wilfredo's client - will retrieve the event back from the server to get the schedule - status of the Organizer. - - >> Request << - - GET /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1 - Host: cal.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 82] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 19:03:03 GMT - Last-Modified: Tue, 02 Jun 2009 19:02:21 GMT - ETag: "5eb897deabda116714bc9926c8939589" - Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T190221Z - DTSTART:20090602T160000Z - DTEND:20090602T170000Z - TRANSP:OPAQUE - SUMMARY:Lunch - ORGANIZER;CN="Cyrus Daboo";SCHEDULE-STATUS=1.2:mailto:cyrus@ex - ample.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT - =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam - ple.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex - ample.net - ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A - CTION;RSVP=TRUE:mailto:mike@example.org - BEGIN:VALARM - TRIGGER:-PT15M - ACTION:DISPLAY - DESCRIPTION:Reminder - END:VALARM - END:VEVENT - END:VCALENDAR - -B.4. Example: Organizer Receiving a Reply to an Invitation - - On reception of Wilfredo's reply, Cyrus's server will automatically - update Cyrus's scheduling object resource, make Wilfredo's scheduling - message available in Cyrus's scheduling Inbox collection, and deliver - an updated scheduling message to Bernard to share Wilfredo's updated - participation status. In this example, Cyrus's client retrieves and - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 83] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - deletes this scheduling message in his scheduling Inbox collection. - - >> Request << - - GET /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1 - Host: cal.example.com - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 19:05:02 GMT - Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT - ETag: "9265eb897deabc8939589da116714bc9" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Server//EN - METHOD:REPLY - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T185754Z - DTSTART:20090602T160000Z - DTEND:20090602T170000Z - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";PARTSTAT=ACCEPTED:mailto:w - ilfredo@example.com - REQUEST-STATUS:2.0;Success - END:VEVENT - END:VCALENDAR - - >> Request << - - DELETE /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1 - Host: cal.example.com - - >> Response << - - HTTP/1.1 204 No Content - Date: Tue, 02 Jun 2009 19:05:05 GMT - - Cyrus's client then retrieves the event back from the server with - Wilfredo's updated participation status. - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 84] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Request << - - GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 - Host: cal.example.com - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 19:05:02 GMT - Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT - ETag: "eb897deabc8939589da116714bc99265" - Schedule-Tag: "132cab27-1fe3-67ab-de13-abd348d1dee3" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Server//EN - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T190420Z - DTSTART:20090602T160000Z - DTEND:20090602T170000Z - TRANSP:OPAQUE - SUMMARY:Lunch - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT - =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=2.0: - mailto:wilfredo@example.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1 - .0:mailto:bernard@example.net - ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A - CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org - END:VEVENT - END:VCALENDAR - -B.5. Example: Organizer Requesting Busy Time Information - - In this example, Cyrus requests the busy time information of - Wilfredo, Bernard and Mike. - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 85] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Request << - - POST /home/cyrus/calendars/outbox/ HTTP/1.1 - Host: cal.example.com - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - METHOD:REQUEST - BEGIN:VFREEBUSY - UID:4FD3AD926350 - DTSTAMP:20090602T190420Z - DTSTART:20090602T000000Z - DTEND:20090604T000000Z - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com - ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net - ATTENDEE;CN="Mike Douglass":mailto:mike@example.org - END:VFREEBUSY - END:VCALENDAR - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 20:07:34 GMT - Content-Type: application/xml; charset="utf-8" - Content-Length: xxxx - - <?xml version="1.0" encoding="utf-8" ?> - <C:schedule-response xmlns:D="DAV:" - xmlns:C="urn:ietf:params:xml:ns:caldav"> - <C:response> - <C:recipient> - <D:href>mailto:wilfredo@example.com</D:href> - </C:recipient> - <C:request-status>2.0;Success</C:request-status> - <C:calendar-data>BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Server//EN - METHOD:REPLY - BEGIN:VFREEBUSY - UID:4FD3AD926350 - DTSTAMP:20090602T200733Z - DTSTART:20090602T000000Z - DTEND:20090604T000000Z - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 86] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com - FREEBUSY;FBTYPE=BUSY:20090602T110000Z/20090602T120000Z - FREEBUSY;FBTYPE=BUSY:20090603T170000Z/20090603T180000Z - END:VFREEBUSY - END:VCALENDAR - </C:calendar-data> - </C:response> - <C:response> - <C:recipient> - <D:href>mailto:bernard@example.net</D:href> - </C:recipient> - <C:request-status>2.0;Success</C:request-status> - <C:calendar-data>BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Server//EN - METHOD:REPLY - BEGIN:VFREEBUSY - UID:4FD3AD926350 - DTSTAMP:20090602T200733Z - DTSTART:20090602T000000Z - DTEND:20090604T000000Z - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net - FREEBUSY;FBTYPE=BUSY:20090602T150000Z/20090602T160000Z - FREEBUSY;FBTYPE=BUSY:20090603T090000Z/20090603T100000Z - FREEBUSY;FBTYPE=BUSY:20090603T180000Z/20090603T190000Z - END:VFREEBUSY - END:VCALENDAR - </C:calendar-data> - </C:response> - <C:response> - <C:recipient> - <D:href>mailto:mike@example.org</D:href> - </C:recipient> - <C:request-status>3.7;Invalid calendar user</C:request-status> - </C:response> - </C:schedule-response> - -B.6. Example: User Attempting to Invite Attendee on behalf of Organizer - - In the following example, Cyrus attempts to create, on behalf of - Wilfredo, an event with Bernard specified as an Attendee. The - request fails since Wilfredo didn't grant Cyrus the right to invite - other Calendar Users on his behalf. - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 87] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Request << - - PUT /home/wilfredo/calendars/work/def456.ics HTTP/1.1 - Host: cal.example.com - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - If-None-Match: * - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - BEGIN:VEVENT - UID:3504F926D3AD - SEQUENCE:0 - DTSTAMP:20090602T190221Z - DTSTART:20090602T230000Z - DTEND:20090603T000000Z - TRANSP:OPAQUE - SUMMARY:Dinner - ORGANIZER;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com - ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT=A - CCEPTED:mailto:wilfredo@example.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=NE - EDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl - e.net - END:VEVENT - END:VCALENDAR - - >> Response << - - HTTP/1.1 403 Forbidden - Content-Type: application/xml; charset="utf-8" - Content-Length: xxxx - - <D:error xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> - <D:need-privileges> - <D:resource> - <D:href>/home/wilfredo/calendars/outbox/</D:href> - <D:privilege><C:schedule-send-invite/></D:privilege> - </D:resource> - </D:need-privileges> - </D:error> - -B.7. Example: Attendee Declining an Instance of a Recurring Event - - In the following example, Bernard declines the second recurrence - instance of a daily recurring event he's been invited to by Cyrus. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 88] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Request << - - PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1 - Host: cal.example.com - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - If-Schedule-Tag-Match: "7775FB30-7534-489E-A79A-0EA147B933EB" - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - BEGIN:VTIMEZONE - TZID:America/Montreal - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZNAME:EST - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZNAME:EDT - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T185254Z - DTSTART;TZID=America/Montreal:20090601T150000 - DTEND;TZID=America/Montreal:20090601T160000 - RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5 - TRANSP:OPAQUE - SUMMARY:Review Internet-Draft - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl - e.net - END:VEVENT - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090603T183823Z - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 89] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - RECURRENCE-ID;TZID=America/Montreal:20090602T150000 - DTSTART;TZID=America/Montreal:20090602T150000 - DTEND;TZID=America/Montreal:20090602T160000 - TRANSP:TRANSPARENT - SUMMARY:Review Internet-Draft - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl - e.net - END:VEVENT - END:VCALENDAR - - >> Response << - - HTTP/1.1 200 OK - Content-Length: 0 - Date: Tue, 02 Jun 2009 18:52:54 GMT - Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT - ETag: "d85561cfe74a4e785eb4639451b434fb" - Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" - - Bernard's participation status update will cause his server to - deliver a scheduling message to Cyrus. Cyrus's client will find the - following reply message from Bernard in Cyrus's scheduling Inbox - collection: - - >> Request << - - GET /home/cyrus/calendars/inbox/9263504FD3AD.ics HTTP/1.1 - Host: cal.example.com - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 90] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 18:52:58 GMT - Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT - ETag: "eb897deabc8939589da116714bc99265" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - METHOD:REPLY - BEGIN:VTIMEZONE - TZID:America/Montreal - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZNAME:EST - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZNAME:EDT - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090603T183823Z - RECURRENCE-ID;TZID=America/Montreal:20090602T150000 - DTSTART;TZID=America/Montreal:20090602T150000 - DTEND;TZID=America/Montreal:20090602T160000 - SUMMARY:Review Internet-Draft - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED: - mailto:bernard@example.net - REQUEST-STATUS:2.0;Success - END:VEVENT - END:VCALENDAR - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 91] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -B.8. Example: Attendee Removing an Instance of a Recurring Event - - In the following example, Bernard removes from his calendar the third - recurrence instance of a daily recurring event he's been invited to - by Cyrus. This is accomplished by the addition of an "EXDATE" - property to the scheduling object resource stored by Bernard. - - >> Request << - - PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1 - Host: cal.example.com - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - If-Schedule-Tag-Match: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - BEGIN:VTIMEZONE - TZID:America/Montreal - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZNAME:EST - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZNAME:EDT - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090602T185254Z - DTSTART;TZID=America/Montreal:20090601T150000 - DTEND;TZID=America/Montreal:20090601T160000 - RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5 - EXDATE;TZID=America/Montreal:20090603T150000 - TRANSP:OPAQUE - SUMMARY:Review Internet-Draft - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 92] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl - e.net - END:VEVENT - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090603T183823Z - RECURRENCE-ID;TZID=America/Montreal:20090602T150000 - DTSTART;TZID=America/Montreal:20090602T150000 - DTEND;TZID=America/Montreal:20090602T160000 - TRANSP:TRANSPARENT - SUMMARY:Review Internet-Draft - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: - mailto:cyrus@example.com - ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= - DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl - e.net - END:VEVENT - END:VCALENDAR - - Bernard's deletion of a recurrence instance will cause his server to - deliver a scheduling message to Cyrus. Cyrus's client will find the - following reply message from Bernard in Cyrus's scheduling Inbox - collection: - - >> Request << - - GET /home/cyrus/calendars/inbox/6504923FD3AD.ics HTTP/1.1 - Host: cal.example.com - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 93] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - >> Response << - - HTTP/1.1 200 OK - Date: Tue, 02 Jun 2009 18:52:58 GMT - Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT - ETag: "eb897deabc8939589da116714bc99265" - Content-Type: text/calendar; charset="utf-8" - Content-Length: xxxx - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//Example Corp.//CalDAV Client//EN - METHOD:REPLY - BEGIN:VTIMEZONE - TZID:America/Montreal - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZNAME:EST - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZNAME:EDT - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - UID:9263504FD3AD - SEQUENCE:0 - DTSTAMP:20090603T183823Z - RECURRENCE-ID;TZID=America/Montreal:20090603T150000 - DTSTART;TZID=America/Montreal:20090603T150000 - DTEND;TZID=America/Montreal:20090603T160000 - SUMMARY:Review Internet-Draft - ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com - ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED: - mailto:bernard@example.net - REQUEST-STATUS:2.0;Success - END:VEVENT - END:VCALENDAR - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 94] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -Appendix C. Changes (to be removed by RFC Editor prior to publication) - -C.1. Changes in -10 - - a. Updated to RFC 6047 reference. - - b. Various minor clarifications to behavior and terminology done. - - c. Clarified that Inbox/Outbox are the server's responsibility to - create. - - d. Changed MAY to SHOULD for server rejecting organizer PARTSTAT - changes of attendees. - - e. Allow COMPLETED as a valid attendee change. - - f. Allow SCHEDULE-STATUS as a valid attendee change on SCHEDULE- - AGENT=CLIENT attendee properties. - - g. COPY or MOVE on a calendar collection now declared to be - undefined. - - h. Changed pre-condition error codes from 409 to 403. - - i. Clarified that rules 5546 must be used when server processes - incoming scheduling messages. - - j. default-calendar-delete-allowed -> default-calendar-needed. - - k. Clarified that SCHEDULE-AGENT must be the same on all matching - properties. - - l. Added more text justifying the need for calendar-user-type - property. - -C.2. Changes in -09 - - a. Fixed some examples. - - b. Tweaked XML conventions. - - c. Removed description in SCHEDULE-STATUS example values. - - d. Tweaked 3.7 and 3.8 SCHEDULE-STATUS description to indicate it - applies to the Organizer as well as Attendee. - - e. Updated to RFC 5545 reference. - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 95] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - f. AD Review: clarified text about inbox resource deletion being - acknowledgment of change. - - g. AD Review: clarified description of freebusy Outbox POST. - - h. AD Review: registered new 1.xx request-status codes and added new - restriction on usage as per iTIP. - - i. AD Review: changes SHOULD NOT to MUST NOT for new property - parameters when clients send scheduling messages. - - j. AD Review: CALDAV:schedule-calendar-transp now preserved during - COPY. - - k. AD Review: changed CALDAV- to CALDAV: in acl descriptions. - - l. AD Review: fixed various minor typos. - - m. AD Review: Added text to new principal properties to indicate - that if they are not present, then the user is not enabled for - the various scheduling operations. - - n. AD Review: clarified use of CALDAV:calendar-data element in - CALDAV:response element. - - o. AD Review: made reference to 5545 IANA registry procedures for - the two new element registries. - - p. AD Review: Fixed description of B5. example. - - q. Fixed SCHEDULE-AGENT/SCHEDULE-STATUS behavior for Attendee - replies. - -C.3. Changes in -08 - - a. Added "Updates 4791". - - b. XML conventions changed to match that in CardDAV spec. - - c. Reworded child response behavior for Outbox. - - d. Reworded "octet size". - - e. If-Schedule-Match descriptions changed to remove implication that - it is purely a conditional operation. - - f. Schedule-Reply header descriptions generalized to resource - removal rather than just HTTP DELETE. - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 96] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - g. Fixed various examples. - -C.4. Changes in -07 - - a. Restructured document. - - b. Clarified that CALDAV:schedule-calendar-transp only applies to - calendar collection. - - c. Removed CALDAV:schedule-state property on scheduling messages in - the scheduling Inbox collection. - - d. Added conditional requests on scheduling object resources. - - e. Added section on handling of PARTSTAT. - - f. Added SCHEDULE-FORCE-SEND iCalendar property parameter. - - g. Added clarification on child resources in scheduling Outbox - collections. - - h. Clarified Attendee changes that server MUST allow, and removed - restrictions on changes that Attendee MUST NOT do. - - i. Added Example Scheduling Transactions appendix. - - j. Scheduling privileges are no longer required to be non-abstract. - - k. Removed handling of REFRESH requests. - - l. Removed handling of VJOURNAL components. - - m. Completed IANA Considerations section. - - n. Added references to RFC3283 and RFC5234. - - o. Updated references to iCalendar, iTIP and iMIP. - -C.5. Changes in -06 - - a. Removed distinction between scheduling calendar collections and - basic calendar collections - now just have calendar collections. - - b. Clients now "MAY" reload data rather than "SHOULD" reload data. - - c. Fixed <C:recipient> in examples. - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 97] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - - d. Removed CALDAV:attachments-allowed precondition on POST to Outbox - as that is no longer relevant. - - e. Added CALDAV:default-calendar-delete-allowed precondition for - DELETE. - - f. Relaxed MUST->MAY for Organizer setting PARTSTAT value. - - g. Tweaked restrictions on Create/Modify to emphasize that 4791 - restrictions also apply. - - h. Added comment that 'opaque' is the default when the CALDAV: - schedule-calendar-transp property is not present. - - i. Description of Schedule-Reply header changed to reflect that it - is only relevant for Attendees. - - j. Minor typos fixed. - -C.6. Changes in -05 - - This draft has changed substantially since the -04 version. The - primary reason for this change was implementation experience from a - number of vendors who implemented products based on the earlier - drafts. Experience showed that the client/server interaction was not - reliable in keeping scheduling messages synchronized between - organizer and attendees. In addition the latency in updates due to - clients being offline proved unacceptable to users. These issues led - to the redesign of this specification to support a server-based - processing model that eliminates all the problems seen previously. - Whilst this adds significant complexity to the server in that it - needs to be a full blown iTIP processing agent, it does remove a lot - of the same complexity from clients, opening up the possibility of - supporting complex scheduling behaviors even with "thin" clients. - - In the judgement of the authors, we consider this new specification - to be a substantial improvement over the old one and believe it - represents a stronger protocol that will lead to better - interoperability. - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 98] - -Internet-Draft CalDAV Scheduling Extensions September 2011 - - -Authors' Addresses - - Cyrus Daboo - Apple Inc. - 1 Infinite Loop - Cupertino, CA 95014 - USA - - EMail: cyrus@daboo.name - URI: http://www.apple.com/ - - - Bernard Desruisseaux - Oracle Corporation - 600 Blvd. de Maisonneuve West - Suite 1900 - Montreal, QC H3A 3J2 - CANADA - - EMail: bernard.desruisseaux@oracle.com - URI: http://www.oracle.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo & Desruisseaux Expires March 10, 2012 [Page 99] - |