3.  Scheduling Operations

   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.

3.1.  Identifying Scheduling Object Resources

   Calendar object resources on which the server performs scheduling
   operations 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 if 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 4.3).

3.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.

3.2.1.  Organizer Scheduling Object Resources

   An "Organizer" can create, modify, or remove a scheduling object
   resource, subject to access privileges, preconditions, and the
   restrictions defined in Section 4.1 of [RFC4791].  These operations
   are each described next, and how they are invoked via HTTP requests
   is described in Section 3.2.3.

   The "Organizer" of a calendar component can 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".

   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".

   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".

3.2.1.1.  Create

   When an "Organizer" creates a scheduling object resource, the server
   MUST inspect each "ATTENDEE" property to determine whether to send a
   scheduling message.  The table below indicates the appropriate iTIP
   method used by the server, taking into account any "SCHEDULE-AGENT"
   property parameter (see Section 7.1) specified on each "ATTENDEE"
   property.

                    +------------------+-------------+
                    | SCHEDULE-AGENT   | iTIP METHOD |
                    +------------------+-------------+
                    | SERVER (default) | REQUEST     |
                    |                  |             |
                    | CLIENT           | --          |
                    |                  |             |
                    | NONE             | --          |
                    +------------------+-------------+

   "SCHEDULE-STATUS" iCalendar property parameters are added or changed
   on "ATTENDEE" iCalendar properties in the scheduling object resource
   being created as described in Section 7.3, with the value set as
   described in Section 3.2.9.  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.

   The server MUST add a "SCHEDULE-STATUS" iCalendar property parameter
   (see Section 7.3) to the "ATTENDEE" iCalendar property in the
   scheduling object resource being created, and set its value as
   described in Section 3.2.9.  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.

   The server MUST return an error with the CALDAV:allowed-organizer-
   scheduling-object-change precondition code (Section 3.2.4.3) when the
   "Organizer" attempts to change the iCalendar data in a manner that is
   forbidden.

3.2.1.2.  Modify

   When an "Organizer" modifies a scheduling object resource, the server
   MUST inspect each "ATTENDEE" property in both the original and
   modified iCalendar data on a per-instance basis to determine whether
   to send a scheduling message.  The table below indicates the
   appropriate iTIP method used by the server, taking into account any
   "SCHEDULE-AGENT" property parameter (see Section 7.1) specified on
   each "ATTENDEE" property.  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 (Original) or is being removed (Modified).

   +---------------+-----------------------------------------------+
   |               |                   Modified                    |
   |               +-----------+-----------+-----------+-----------+
   |               | <Removed> | SERVER    | CLIENT    | NONE      |
   |               |           | (default) |           |           |
   +===+===========+===========+===========+===========+===========+
   |   | <Absent>  |  --       | REQUEST / | --        | --        |
   | O |           |           | ADD       |           |           |
   | r +-----------+-----------+-----------+-----------+-----------+
   | i | SERVER    |  CANCEL   | REQUEST   | CANCEL    | CANCEL    |
   | g | (default) |           |           |           |           |
   | i +-----------+-----------+-----------+-----------+-----------+
   | n | CLIENT    |  --       | REQUEST / | --        | --        |
   | a |           |           | ADD       |           |           |
   | l +-----------+-----------+-----------+-----------+-----------+
   |   | NONE      |  --       | REQUEST / | --        | --        |
   |   |           |           | ADD       |           |           |
   +---+-----------+-----------+-----------+-----------+-----------+

   "SCHEDULE-STATUS" iCalendar property parameters are added or changed
   on "ATTENDEE" iCalendar properties in the scheduling object resource
   being modified as described in Section 7.3, with the value set as
   described in Section 3.2.9.  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.

   The server MUST return an error with the CALDAV:allowed-organizer-
   scheduling-object-change precondition code (Section 3.2.4.3) when the
   "Organizer" attempts to change the iCalendar data in a manner that is
   forbidden.

3.2.1.3.  Remove

   When an "Organizer" removes a scheduling object resource, the server
   MUST inspect each "ATTENDEE" property to determine whether to send a
   scheduling message.  The table below indicates the appropriate iTIP
   method used by the server, taking into account any "SCHEDULE-AGENT"
   property parameter (see Section 7.1) specified on each "ATTENDEE"
   property.

                    +------------------+-------------+
                    | SCHEDULE-AGENT   | iTIP METHOD |
                    +------------------+-------------+
                    | SERVER (default) | CANCEL      |
                    |                  |             |
                    | CLIENT           | --          |
                    |                  |             |
                    | NONE             | --          |
                    +------------------+-------------+

3.2.2.  Attendee Scheduling Object Resources

   An "Attendee" can create, modify, or remove a scheduling object
   resource.  These operations are each described next, and how they are
   invoked via HTTP requests is described in Section 3.2.3.

3.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".

   Servers MUST allow "Attendees" to make the following iCalendar data
   changes, subject to other restrictions, such as access privileges and
   preconditions:

   1.   change their own "PARTSTAT" iCalendar property parameter value.

   2.   add, modify, or remove any "TRANSP" iCalendar properties.

   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 3.2.4.4) when the
   "Attendee" attempts to change the iCalendar data in a manner
   forbidden by the server.

3.2.2.2.  Create

   Typically, an "Attendee" does not create scheduling object resources,
   as scheduling messages delivered to him on the server are
   automatically processed by the server and placed on one of his
   calendars (see Section 4).  However, in some cases, a scheduling
   message can get delivered directly to the client (e.g., via email
   [RFC6047]), and the "Attendee" might wish to store that on the
   server.  In that case, the client creates a scheduling object
   resource in a 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.

   +----------------+--------------------------------------------------+
   | 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.                                        |
   +----------------+--------------------------------------------------+

   "SCHEDULE-STATUS" iCalendar property parameters are added or changed
   on "ORGANIZER" iCalendar properties in the scheduling object resource
   being created as described in Section 7.3, with the value set as
   described in Section 3.2.9.

3.2.2.3.  Modify

   When a scheduling object resource is modified by an "Attendee", the
   server's 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 update    |
   | (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
   "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.

   "SCHEDULE-STATUS" iCalendar property parameters are added or changed
   on "ORGANIZER" iCalendar properties in the scheduling object resource
   being modified as described in Section 7.3, with the value set as
   described in Section 3.2.9.  This will result in the updated 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.

3.2.2.4.  Remove

   When a scheduling object resource is removed by an "Attendee", the
   server's 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)      | taking into account any "Schedule-Reply" request |
   |                | header as per Section 8.1.                       |
   |                |                                                  |
   | 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.                                        |
   +----------------+--------------------------------------------------+

3.2.3.  HTTP Methods

   This section describes how the use of various HTTP [RFC2616] and
   WebDAV [RFC4918] methods on a scheduling object resource will cause a
   create, modify, or remove operation 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.

3.2.3.1.  PUT

   When the server receives a PUT method request, it MUST execute the
   following operations, provided all appropriate preconditions are met:

   +------------------------+--------------------------+---------------+
   | Existing Destination   | Resulting Destination    | Server        |
   | Resource               | Resource                 | Operation     |
   +------------------------+--------------------------+---------------+
   | None                   | Calendar object resource | None          |
   |                        |                          |               |
   | None                   | Scheduling object        | Create        |
   |                        | resource                 |               |
   |                        |                          |               |
   | Calendar object        | Calendar object resource | None          |
   | resource               |                          |               |
   |                        |                          |               |
   | Calendar object        | Scheduling object        | Create        |
   | resource               | resource                 |               |
   | Scheduling object      | Calendar object resource | Remove        |
   | resource               |                          |               |
   |                        |                          |               |
   | Scheduling object      | Scheduling object        | Modify        |
   | resource               | resource                 |               |
   +------------------------+--------------------------+---------------+

3.2.3.2.  DELETE

   When the server receives a DELETE method request targeted at a
   scheduling object resource, it MUST execute the Remove operation.

   When the server receives a DELETE method request targeted at a
   calendar collection, it MUST execute the Remove operation on all
   scheduling object resources contained in the calendar collection.

3.2.3.3.  COPY

   When the server receives a COPY method request, it MUST execute the
   following operations based on the source and destination collections
   in the request:

   +-----------------------+------------------------+------------------+
   | Source Collection     | Destination Collection | Server Operation |
   +-----------------------+------------------------+------------------+
   | Non-calendar          | Non-calendar           | None             |
   | collection            | collection             |                  |
   |                       |                        |                  |
   | Non-calendar          | Calendar collection    | (1)              |
   | collection            |                        |                  |
   |                       |                        |                  |
   | Calendar collection   | Non-calendar           | None             |
   |                       | collection             |                  |
   |                       |                        |                  |
   | Calendar collection   | Calendar collection    | (2)              |
   +-----------------------+------------------------+------------------+

   Note (1):  The rules in Section 3.2.3.1 are applied for the
              destination of the COPY request.

   Note (2):  The server MAY reject this as per Section 3.2.4.1;
              otherwise, None.

   The behavior of a COPY method request on a calendar collection is
   undefined.

3.2.3.4.  MOVE

   When the server receives a MOVE method request, it MUST execute the
   following operations based on the source and destination collections
   in the request:

   +-----------------------+------------------------+------------------+
   | Source Collection     | Destination Collection | Server Operation |
   +-----------------------+------------------------+------------------+
   | Non-calendar          | Non-calendar           | None             |
   | collection            | collection             |                  |
   |                       |                        |                  |
   | Non-calendar          | Calendar collection    | (1)              |
   | collection            |                        |                  |
   |                       |                        |                  |
   | Calendar collection   | Non-calendar           | (2)              |
   |                       | collection             |                  |
   |                       |                        |                  |
   | Calendar collection   | Calendar collection    | None             |
   +-----------------------+------------------------+------------------+

   Note (1):  The rules in Section 3.2.3.1 are applied for the
              destination of the MOVE request.

   Note (2):  The rules in Section 3.2.3.2 are applied for the source of
              the MOVE request.

   The behavior of a MOVE method request on a calendar collection is
   undefined.

3.2.4.  Additional Method Preconditions

   This specification defines method preconditions (see Section 16 of
   WebDAV [RFC4918]), in addition to those in [RFC4791], to provide
   machine-parseable information in error responses.

3.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>

3.2.4.2.  CALDAV:same-organizer-in-all-components Precondition

   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>

3.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" from 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 does not have the
      "SCHEDULE-AGENT" property parameter.  See Section 3.2.1.

   Definition:

     <!ELEMENT allowed-organizer-scheduling-object-change EMPTY>

3.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", subject to the allowed
      changes specified in Section 3.2.2.1.

   Definition:

     <!ELEMENT allowed-attendee-scheduling-object-change EMPTY>

3.2.5.  DTSTAMP and SEQUENCE Properties

   The server MUST ensure that a "DTSTAMP" iCalendar property is present
   and set the value to the UTC time that the scheduling message was
   generated (as required by iCalendar).

   The server MUST ensure that for each type of scheduling operation,
   the "SEQUENCE" iCalendar property value is updated as per iTIP
   [RFC5546].

3.2.6.  Restrict Recurrence Instances Sent to "Attendees"

   Servers MUST ensure that "Attendees" only get information about
   recurrence instances that explicitly include them as an "Attendee",
   when delivering scheduling messages for recurring calendar
   components.

   For example, if an "Attendee" is invited to only a single instance of
   a recurring event, the organizer scheduling object resource will
   contain an overridden instance in the form of a separate calendar
   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 organizer scheduling object
   resource will include an overridden instance with an "ATTENDEE" list
   that does not include the "Attendee" being excluded.  Any scheduling
   messages delivered to the "Attendee" will not specify the overridden
   instance but rather will include an "EXDATE" property in the "master"
   component that defines the recurrence set.

3.2.7.  Forcing the Server to Send a Scheduling Message

   The iCalendar property parameter "SCHEDULE-FORCE-SEND", defined in
   Section 7.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 his participation status without being
   forced to modify the event.

3.2.8.  "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.

   A reschedule 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.  Servers MUST reset the
   "PARTSTAT" property parameter value of all "ATTENDEE" properties,
   except the one that corresponds to the "Organizer", to "NEEDS-ACTION"
   for each calendar component change that causes any instance to be
   rescheduled.

   +-----------+-------------------------------------------------------+
   | Property  | Server Action                                         |
   +-----------+-------------------------------------------------------+
   | DTSTART,  | Any change to these properties results in "PARTSTAT"  |
   | DTEND,    | 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       |
   |           | results 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       |
   |           | results in "PARTSTAT" being reset to "NEEDS-ACTION"   |
   |           | on each affected component.                           |
   |           |                                                       |
   | EXDATE    | A change to or removal of this property that results  |
   |           | in the reinstatement of recurring instances results   |
   |           | 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 might be impacted
   by the change).

3.2.9.  Schedule Status Values

   When scheduling with an "Attendee", there are two types of status
   information that can be returned during the operation.  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 7.3).  The status code value for "delivery"
   status can be one of the following:

   +----------+--------------------------------------------------------+
   | Delivery | Description                                            |
   | Status   |                                                        |
   | Code     |                                                        |
   +----------+--------------------------------------------------------+
   | 1.0      | The scheduling message is pending.  That is, 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 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.                                            |
   |          |                                                        |
   | 5.2      | The scheduling message was not delivered because the   |
   |          | server was not able to find a way to deliver the       |
   |          | message.  This is likely a permanent failure, and the  |
   |          | originator ought 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 ought 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:

3.2.9.1.  Status Code 1.0

   Status Code:  1.0

   Status Description:  Pending.

   Status Exception Data:  None.

   Description:  Delivery of the iTIP message is pending.

3.2.9.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.

3.2.9.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.

3.2.10.  Avoiding Conflicts when Updating Scheduling Object Resources

   Scheduling object resources on the server might change frequently as
   "Attendees" change their participation status, triggering updates to
   the "Organizer", and refreshes of other "Attendees'" copies of the
   scheduling object resource.  This can lead to an "inconsequential"
   change to a calendar user's data -- one that does not directly impact
   the user's own participation status.  When this occurs, clients have
   to reload calendar data and reconcile with changes being made by
   calendar users.  To avoid the need for this, the server can instead
   merge calendar data changes from a client with changes made as a
   result of a scheduling operation carried out by some other calendar
   user.

   This specification introduces a new WebDAV resource property CALDAV:
   schedule-tag with a corresponding response 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 (one that simply updates the status
   information of "Attendees" due to a reply from another "Attendee").

   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.

   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
   destination resource.

   Clients SHOULD use the If-Schedule-Tag-Match header on requests that
   update scheduling object resources, instead of HTTP ETag-based
   precondition tests (e.g., If-Match).  Normal ETag-based precondition
   tests 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 automatically updated by the server with the
          "Attendee's" new participation status.

      2.  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).

   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 specifies 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
          would remain the same.

      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).

3.2.10.1.  PUT

   Clients MAY 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.

3.2.10.2.  DELETE, COPY, or MOVE

   Clients MAY 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
   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.