add sabre (1.8.x) via composer in the !@#$ place it wants to be

1 files changed, 5544 insertions, 0 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
new file mode 100644
index 000000000..bcb2520f0
--- /dev/null
+++ b/vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt
@@ -0,0 +1,5544 @@
+
+
+
+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]
+