CalDAV Scheduling Extensions to WebDAV

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 the Organizer.

Attendee scheduling object resource:

A scheduling object resource owned by an Attendee.

Scheduling operation:

Add, change or remove operations on a scheduling object resource for which the server will deliver scheduling messages to other calendar users.

Scheduling message:

A calendar object that describes a scheduling operation 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.

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].¶

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) can be added anywhere, except when explicitly stated otherwise,
4. extension attributes (attributes not already defined as valid for this element) can 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 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 needs to be taken not to confuse the two sets of names.¶

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>

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 and apply to scheduling messages submitted to the scheduling Outbox collection with the POST method: ¶

• CALDAV:supported-calendar-component-set
• CALDAV:supported-calendar-data
• CALDAV:max-resource-size
• CALDAV:min-date-time
• CALDAV:max-date-time
• CALDAV:max-attendees-per-instance

The use of child resources in a scheduling Outbox collection is reserved for future revisions or extensions of this specification.¶

The following WebDAV property is defined on principal resources and used to locate the corresponding Outbox collection for the associated principal.¶

A scheduling Inbox collection contains copies of incoming scheduling messages. These can 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]. 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).¶

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 and apply to scheduling messages delivered to the collection: ¶

• CALDAV:supported-calendar-component-set
• CALDAV:supported-calendar-data
• CALDAV:max-resource-size
• CALDAV:min-date-time
• CALDAV:max-date-time
• CALDAV:max-instances
• CALDAV:max-attendees-per-instance
• CALDAV:calendar-timezone

The following WebDAV property is defined on principal resources and used to locate the corresponding Inbox collection for the associated principal.¶

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

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

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

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

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 processes the scheduling message and creates a new scheduling object resource as per Section 4.3.¶

In the case of an update, the server processes the scheduling message and updates 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.¶

For a scheduling message reply sent by an Attendee, the server first locates the corresponding scheduling object resource belonging to the Organizer. If the corresponding scheduling object resource cannot be found, the server SHOULD ignore the scheduling message.¶

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 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 3.2.6.¶

The scheduling message MUST only appear in the Organizer's scheduling Inbox collection once all automatic processing has been done.¶

The server processes 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 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 9.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 server 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.¶

The list below summarizes the most common status codes used for this method. However, clients need to be prepared to handle other 2/3/4/5xx series status codes as well.¶

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

The following are existing preconditions that are reused for the POST method on an Outbox collection. ¶

• DAV:need-privileges [RFC3744]
• CALDAV:supported-calendar-data [RFC4791]
• CALDAV:valid-calendar-data [RFC4791]
• CALDAV:max-resource-size [RFC4791]

The following are new method preconditions for the POST method on an Outbox collection.¶

This section defines new WebDAV ACL [RFC3744] 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.¶

This section defines new WebDAV ACL [RFC3744] 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 (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.¶

Server implementations MUST aggregate the scheduling privileges as follows: ¶

• DAV:all contains CALDAV:schedule-send and CALDAV:schedule-deliver;
• CALDAV:schedule-send contains CALDAV:schedule-send-invite, CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy;
• CALDAV:schedule-deliver contains 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]

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
  ;
  ; If the parameter is not present its value defaults to SERVER.
  ; "x-name" and "iana-token" are defined in Section 3.1 of
  ; [RFC5545].

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 a scheduling operation 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 a scheduling operation. 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 a scheduling operation.

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.

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

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-token" is defined in Section 3.1 of [RFC5545]. Its value
  ; MUST be an IANA registered iCalendar "METHOD" property value.

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 a scheduling operation.

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 an iana-token value they do not recognize.

Example:

  ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:cyrus@example.com
  ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard@example.com

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 only add or change this property parameter on any "ATTENDEE" properties corresponding to calendar users who were sent a scheduling message via a scheduling operation. 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 add this parameter to any "ORGANIZER" properties corresponding to calendar users who were sent a scheduling message reply by an Attendee via a scheduling operation. 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 a scheduling operation.

Clients MUST NOT include this parameter in any scheduling messages that they themselves send.

Values for this property parameter are described in Section 3.2.9.

Example:

  ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com
  ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com

  Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")

Example:

  Schedule-Reply: F

When an Attendee removes a scheduling object resource as per Section 3.2.2.4, and the Schedule-Reply header is not present, or present and set to the value "T" (true), 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 scheduling operation processing.¶

When the Schedule-Reply header is set to the value "F" (false), the server MUST NOT send a scheduling message as part of its normal scheduling operation processing.¶

The Schedule-Reply request header is used by a client to indicate to a server whether or not a scheduling operation ought to 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.¶

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 3.2.10.¶

All scheduling object resources MUST support the Schedule-Tag header.¶

Example:

  Schedule-Tag: "12ab34-cd56ef"

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

Example:

  If-Schedule-Tag-Match: "12ab34-cd56ef"

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 busy time information.

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 ought to contribute to the owner's busy time. When the CALDAV:opaque element is used, all calendar object resources in the corresponding calendar collection MUST contribute to busy time, 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 busy time.

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

Example:

  <C:schedule-calendar-transp
       xmlns:C="urn:ietf:params:xml:ns:caldav">
    <C:opaque/>
  </C:schedule-calendar-transp>

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

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>

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 value is determined by the server and MAY be different from the value on source resource.

Description:

The CALDAV:schedule-tag property MUST be defined on all scheduling object resources. This property is described in Section 3.2.10.

Definition:

  <!ELEMENT schedule-tag (#PCDATA)>

Example:

  <C:schedule-tag xmlns:C="urn:ietf:params:xml:ns:caldav"
  >"12345-67890"</C:schedule-tag>

Name:

schedule-response

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

Contains the set of responses for a POST method request.

Description:

See Section 5.

Definition:

  <!ELEMENT schedule-response (response*)>

Name:

response

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

Contains a single response for a POST method request.

Description:

See Section 5.

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

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.

Description:

See Section 5.

Definition:

  <!ELEMENT recipient (DAV:href)>

Name:

request-status

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

The iTIP "REQUEST-STATUS" property value for this response.

Description:

See Section 5.

Definition:

  <!ELEMENT request-status (#PCDATA)>

Servers MUST ensure that clients cannot consume excessive server resources by carrying out "large" scheduling operations. In particular, servers SHOULD enforce CALDAV:max-resource-size, CALDAV:max-instances and CALDAV:max-attendees-per-instance pre-conditions as applicable for scheduling Inbox and Outbox collections.¶

1. 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.
2. 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 of the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated.
3. Servers MUST only deliver scheduling messages to 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 calendar collection in which a scheduling object resource is being manipulated.
4. 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.
5. 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.

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

This specification only defines how calendar users on the same server are able to schedule with each other - unauthenticated users have no way to carry out scheduling operations. Access control privileges (as per Section 6) can control which of those users can schedule with others. Calendar users not wishing to expose their calendar information to other users can do so by denying privileges to specific users, or all users, for all scheduling operations, or perhaps only freebusy.¶

Attendees can also use the Schedule-Reply request header (Section 8.1) 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.¶

Servers MUST NOT expose any private iCalendar data, or WebDAV resource state information (URLs, WebDAV properties, etc) for one calendar user to another via scheduling messages or error responses to scheduling operations. In particular, as per Section 8.1 of [RFC4918], authorization errors MUST take preference over other errors.¶

Section 6.1 of iTIP [RFC5546] defines a set of potential threats in a scheduling system, and in Section 6.2 defines recommendations on how those can be addressed in protocols using iTIP. This specification addresses the iTIP threats in the following manner: ¶

Spoofing the Organizer

Addressed by item 4 in Section 11.2.

Spoofing the Attendee

Addressed by item 2 in Section 11.2 and Section 3.2.2.1.

Unauthorized Replacement of the Organizer

Addressed by item 5 in Section 11.2.

Eavesdropping and Data Integrity

Addressed by requiring TLS.

Flooding a Calendar

Addressed by requirements in Section 11.1

Unauthorized REFRESH Requests

This specification does not support the REFRESH method.

The message header fields below are to be added to the Permanent Message Header Field Registry (see [RFC3864]).¶

The following iCalendar property parameters are to be added to the iCalendar Property Parameter Registry defined in Section 8.3.3 of [RFC5545].¶

The following iCalendar "REQUEST-STATUS" values are to be added to the iCalendar REQUEST-STATUS Value Registry defined in Section 7.3 of [RFC5546].¶

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

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

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 operation. The appropriate behavior depends on the calendar component type as well as the scheduling "METHOD" specified in the scheduling message.¶

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 collections by using the PUT method.¶

>> 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, as well as record the Schedule-Tag value for future use. 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.¶

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

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

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

>> Response <<

HTTP/1.1 204 No Content
Date: Tue, 02 Jun 2009 20:40:36 GMT 

In the following example, Wilfredo accepts Cyrus's invitation and sets an alarm reminder on the event. It uses the If-Schedule-Tag-Match precondition behavior to ensure it does not overwrite any significant changes from the organizer that might have occurred after it retrieved the initial resource data.¶

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

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

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

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

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

In this example, Cyrus requests the busy time information of Wilfredo, Bernard and Mike.¶

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

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

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

<?xml version="1.0" encoding="utf-8" ?>
<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>

In the following example, Bernard declines the second recurrence instance of a daily recurring event he's been invited to by Cyrus.¶

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

>> Request <<

GET /home/cyrus/calendars/inbox/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"
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

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

>> Request <<

GET /home/cyrus/calendars/inbox/6504923FD3AD.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"
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

1. AppDir: More reworking of various sections for clarity.
2. AppDir: Removed terminology items defined in other specs.
3. AppDir: Now updates 5546.
4. AppDir: MAY instead of can in 3.2.10.1/2.
5. Fixed inconsistent whitespace in examples.
6. IESG: added x-name and iana-token references in ABNF.
7. IESG: clarified that allowed attendee changes are in addition to other pre-conditions.
8. IESG: added privacy statement to address potential "leakage" of private data via scheduling messages or error responses.
9. IESG: scrubbed through some RFC2119 language to avoid unnecessary use and repetition.

1. Major editorial changes to remove "cruft" that built up over time, to reduce repetitive statements, and to improve clarity.
2. SecDir: Added "Preventing Denial of Service Attacks" security sub-section.
3. SecDir: Added reference to RFC6125 and clarified how clients and server authenticate each other.
4. SecDir: Added "Mitigation of iTIP Threats" security sub-section.
5. SecDir: Added new text to privacy sub-section.
6. Fixed some XML examples.

1. Updated to RFC 6047 reference.
2. Various minor clarifications to behavior and terminology done.
3. Clarified that Inbox/Outbox are the server's responsibility to create.
4. Changed MAY to SHOULD for server rejecting organizer PARTSTAT changes of attendees.
5. Allow COMPLETED as a valid attendee change.
6. Allow SCHEDULE-STATUS as a valid attendee change on SCHEDULE-AGENT=CLIENT attendee properties.
7. COPY or MOVE on a calendar collection now declared to be undefined.
8. Changed precondition error codes from 409 to 403.
9. Clarified that rules 5546 must be used when server processes incoming scheduling messages.
10. default-calendar-delete-allowed -> default-calendar-needed.
11. Clarified that SCHEDULE-AGENT must be the same on all matching properties.
12. Added more text justifying the need for calendar-user-type property.

1. Fixed some examples.
2. Tweaked XML conventions.
3. Removed description in SCHEDULE-STATUS example values.
4. Tweaked 3.7 and 3.8 SCHEDULE-STATUS description to indicate it applies to the Organizer as well as Attendee.
5. Updated to RFC 5545 reference.
6. AD Review: clarified text about inbox resource deletion being acknowledgment of change.
7. AD Review: clarified description of freebusy Outbox POST.
8. AD Review: registered new 1.xx request-status codes and added new restriction on usage as per iTIP.
9. AD Review: changes SHOULD NOT to MUST NOT for new property parameters when clients send scheduling messages.
10. AD Review: CALDAV:schedule-calendar-transp now preserved during COPY.
11. AD Review: changed CALDAV- to CALDAV: in acl descriptions.
12. AD Review: fixed various minor typos.
13. 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.
14. AD Review: clarified use of CALDAV:calendar-data element in CALDAV:response element.
15. AD Review: made reference to 5545 IANA registry procedures for the two new element registries.
16. AD Review: Fixed description of B5. example.
17. Fixed SCHEDULE-AGENT/SCHEDULE-STATUS behavior for Attendee replies.

1. Added "Updates 4791".
2. XML conventions changed to match that in CardDAV spec.
3. Reworded child response behavior for Outbox.
4. Reworded "octet size".
5. If-Schedule-Match descriptions changed to remove implication that it is purely a conditional operation.
6. Schedule-Reply header descriptions generalized to resource removal rather than just HTTP DELETE.
7. Fixed various examples.

1. Restructured document.
2. Clarified that CALDAV:schedule-calendar-transp only applies to calendar collection.
3. Removed CALDAV:schedule-state property on scheduling messages in the scheduling Inbox collection.
4. Added conditional requests on scheduling object resources.
5. Added section on handling of PARTSTAT.
6. Added SCHEDULE-FORCE-SEND iCalendar property parameter.
7. Added clarification on child resources in scheduling Outbox collections.
8. Clarified Attendee changes that server MUST allow, and removed restrictions on changes that Attendee MUST NOT do.
9. Added Example Scheduling Transactions appendix.
10. Scheduling privileges are no longer required to be non-abstract.
11. Removed handling of REFRESH requests.
12. Removed handling of VJOURNAL components.
13. Completed IANA Considerations section.
14. Added references to RFC3283 and RFC5234.
15. Updated references to iCalendar, iTIP and iMIP.

1. Removed distinction between scheduling calendar collections and basic calendar collections - now just have calendar collections.
2. Clients now "MAY" reload data rather than "SHOULD" reload data.
3. Fixed <C:recipient> in examples.
4. Removed CALDAV:attachments-allowed precondition on POST to Outbox as that is no longer relevant.
5. Added CALDAV:default-calendar-delete-allowed precondition for DELETE.
6. Relaxed MUST->MAY for Organizer setting PARTSTAT value.
7. Tweaked restrictions on Create/Modify to emphasize that 4791 restrictions also apply.
8. Added comment that 'opaque' is the default when the CALDAV:schedule-calendar-transp property is not present.
9. Description of Schedule-Reply header changed to reflect that it is only relevant for Attendees.
10. Minor typos fixed.

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