]> Apple Inc.

1 Infinite Loop Cupertino CA 95014 USA cyrus@daboo.name http://www.apple.com/

Oracle Corporation

600 Blvd. de Maisonneuve West Suite 1900 Montreal QC H3A 3J2 CANADA bernard.desruisseaux@oracle.com http://www.oracle.com/

CommerceNet

169 University Ave. Palo Alto CA 94301 USA ldusseault@commerce.net http://commerce.net/

Applications calsched calsch caldav calendar calendaring scheduling webdav iCal iCalendar iTIP text/calendar HTTP This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport-Independent Interoperability Protocol (iTIP). This document defines the "calendar-schedule" feature of CalDAV.

This document specifies a set of headers, properties and privileges that define the CalDAV scheduling extensions to the WebDAV protocol. This document also provides the transport specific information necessary to convey iCalendar Transport-independent Interoperability Protocol iTIP messages over WebDAV which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components, as well as search for busy time information. Discussion of this Internet-Draft is taking place on the mailing list <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations), described in Section 3.2 of . The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML elements defined in this specification, or in other Standards Track IETF RFCs written to extend CalDAV. It MUST NOT be used for proprietary extensions. Note that the XML declarations used in this document are incomplete, in that they do not include namespace information. Thus, the reader MUST NOT use these declarations as the only way to create valid CalDAV properties or to validate CalDAV XML element types. Some of the declarations refer to XML elements defined by WebDAV which use the "DAV:" namespace. Wherever such elements appear, they are explicitly given the "DAV:" prefix to help avoid confusion. Additionally, some of the elements used here are defined in CalDAV. Also note that some CalDAV XML element names are identical to WebDAV XML element names, though their namespace differs. Care MUST be taken not to confuse the two sets of names.

The augmented BNF used by this document to describe protocol elements is described in Section 2.1 of . Because this augmented BNF uses the basic production rules provided in Section 2.2 of , those rules apply to this document as well. 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 . 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 string "DAV:" and "CALDAV:" will be prefixed to the element types respectively.

A message that describes a transaction such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel calendar components. A message that describes a transaction such as publish unsolicited busy time information, request busy time information, or respond to a busy time request. A scheduling message that uses an scheduling method set to one of PUBLISH, REQUEST, ADD, CANCEL or DECLINE-COUNTER. A scheduling message that uses an scheduling method set to one of REPLY, REFRESH or COUNTER. Software with which the calendar user communicates with a calendar service or local calendar store to access calendar information.

This section lists what functionality is required of a CalDAV scheduling server. To advertise support for this specification a server: MUST support iCalendar as a media type for the calendar object resource format; MUST support iTIP . MUST support WebDAV Class 1, 2, and 3; MUST support WebDAV ACL with the additional privileges defined in of this document; MUST support transport over TLS as defined in (note that has been obsoleted by ); MUST support ETags ; MUST support the CALDAV:schedule-inbox and CALDAV:schedule-outbox collection resource types. MUST support the POST method with the Recipient and Originator request headers targeted at a CALDAV:schedule-outbox collection resource type. A CalDAV scheduling server MAY also support the CalDAV calendar-access feature , and that adds the following requirements: MUST support the CALDAV:calendar-query and CALDAV:multiget REPORTs on CALDAV:schedule-inbox and CALDAV:schedule-outbox collection resource types.

If the server supports the calendar scheduling features described in this document it MUST include "calendar-schedule" as a field in the DAV response header from an OPTIONS request on any resource that supports any scheduling properties, privileges or methods.

>> Request <<

>> Response <<

In this example, the OPTIONS response indicates that the server supports both the calendar-access and calendar-schedule features and that /lisa/calendar/outbox/ can be specified as a Request-URI to the POST method.

The process of scheduling a meeting between different parties often involves a series of steps with different "actors" playing particular roles during the whole process. Typically there is a meeting "Organizer" whose role is to setup a meeting between one or more meeting "Attendees", and this is done by sending out invitations and handling responses from each Attendee. This process can typically be broken down into two phases. In the first phase the Organizer tries to determine a time for the meeting that ought to be the most acceptable to each Attendee. This involves finding out when each Attendee is available during the period of time in which the meeting needs to occur (or simply finding a suitable time for all attendees to come together for the meeting), and determining when the most appropriate time is for which each Attendee is free. This process is called a "free-busy" lookup. In the second phase the Organizer sends out invitations to each Attendee using the time determined from the free-busy lookup - or a suitable guess as to an appropriate time based on other factors if free-busy lookup is not feasible. There then follows a process of negotiation between Organizer and Attendees regarding the invitation. Some Attendees may choose to attend at the original time provided by the Organizer, others may decline to attend at that time, but suggest another time, others may decline to attend at any time. The Organizer needs to process each of the replies from the Attendees and take appropriate action to confirm the meeting, reschedule it or perhaps cancel it depending on those replies. The user "expectation" as to how a calendaring and scheduling system should respond in each of these two phases is somewhat different. In the case of a free-busy lookup, users expect to get back results immediately so that they can then move on to the invitation phase as quickly as possible. In the case of invitations, its expected that each Attendee will reply in their own time, so delays in receiving replies are anticipated. Thus calendaring and scheduling systems should treat these two operational phases in different ways to accommodate the user expectations, and this specification does that. The scenario above covers the case of scheduling events (VEVENT components) between calendar users, and doing free-busy lookups (VFREEBUSY components). However, iCalendar also allows for sending VTODO and VJOURNAL components as described in iTIP. Since this specification is based on iTIP, VTODO and VJOURNAL components can also be used. For the majority of the following discussion, scheduling of events and free-busy lookups will be discussed as these are the more common operations, however implementations MUST be able to handle all the types of iCalendar components specified for scheduling in iTIP.

This specification introduces two new collection resource types that are used for managing incoming and outgoing scheduling messages separate from other calendar object resources. A calendar user may have multiple calendars representing different spheres of activity, but scheduling requests are targeted at calendar user addresses, and there is no formal way to have those indicate which sphere of activity they might apply to. By storing all incoming scheduling requests in a separate collection, clients can process the requests in that collection and choose what calendar the request belongs to and make its own arrangements to place the relevant calendar object in that calendar to "book" it. The scheduling "Outbox" collection is used for sending scheduling messages via a POST request targeted at the collection and containing the scheduling message in the body of the request. Servers MAY save scheduling messages targeted at the scheduling Outbox collection as resources in the collection, and these can then be used to track the history of scheduling messages. The scheduling "Inbox" collection is used to receive scheduling messages, which are stored as calendar object resources in the collection. The server deposits scheduling messages into the scheduling Inbox collection as the result of a scheduling request that targets the calendar user associated with the scheduling Inbox collection. Scheduling messages could be delivered as the result of a POST request targeted at a scheduling Outbox collection (as described above) or as the result of some external process (not defined here). New WebDAV ACL privileges on each of these new collections can be used to separately control who is able to send scheduling messages on behalf of a user (when applied to a scheduling Outbox collection), or who a user will accept scheduling messages from (when applied to an scheduling Inbox collection). Note that calendar object resources stored in the new scheduling collections MUST obey the restrictions for (iTIP) calendar objects. The restrictions for calendar object resources stored in regular calendar collections defined in calendar-access do not apply, irrespective of whether the calendar-access feature is available or not.

The iCalendar Transport-independent Interoperability Protocol (iTIP) outlines a model for scheduling and free-busy message exchanges to perform scheduling transactions. This specification makes use of scheduling messages to handle scheduling transactions on the server by having such messages passed between different users on the server depending on their role in the scheduling process. To that end each scheduling message is modeled as a calendar object resource which contains the iCalendar object that conforms to the iTIP requirements for the type of transaction being requested. This specification defines the POST method, acting on an Organizer's scheduling Outbox collection, to trigger schedule processing by the server. This can take one of two forms: for free-busy messages the POST request returns immediately with free busy results; for scheduling messages, a copy of the scheduling message specified in the request body is deposited into each recipient's scheduling Inbox collection. The server may support delivery of scheduling messages to other CalDAV servers if the client specifies a remote calendar user address for any recipient, but the server is not bound to support or complete remote delivery operations even if it advertises support for the "calendar-schedule" feature. Note that remote delivery mechanisms are not defined in this specification. This specification does not define a server-to-server or server-to-client protocol to deliver remote scheduling messages. Implementations may do this in a proprietary way, with iMIP, or with iTIP bindings as yet unspecified. After the delivery is completed, CalDAV clients will see the scheduling message the next time they synchronize or query a scheduling Inbox collection. To reply to a scheduling REQUEST, the client uses the POST method to send another scheduling message (this time a REPLY) back to the Organizer. If the user has decided to accept the REQUEST, the client can create a suitable calendar object resource in the appropriate calendar collection for the recipient. The step of putting the calendar object resource in the calendar is left up to the client, so that the client can make appropriate choices about where to put the calendar object resource, and with what alarms, etc. However, the server MAY be configured to automatically accept or reject invitations, and if the server auto-accepts invitations then the server is responsible for creating calendar object resources in a calendar collection specified by the user, or via some other configuration option.

The CalDAV scheduling extension defines the following new resource types for use with CalDAV.

A scheduling Outbox collection is used as the target for initiating the processing of outgoing scheduling messages. These may be requests initiated by or on behalf of the calendar user associated with the scheduling Outbox collection, or responses to requests received by the calendar user associated with the scheduling Outbox collection. 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:

]]>

Example:

]]>

Every non-collection resource in the scheduling Outbox collection MUST be a valid calendar object resource that defines a scheduling message (i.e. an iCalendar object that follows the iTIP semantic). When a client targets the POST method at a scheduling Outbox collection, the server MAY create a copy of the scheduling message in that scheduling Outbox collection, unless the request contains a free-busy message, in which case the server MUST NOT store a copy of the free-busy message. Copies that are created serve as a record of outgoing scheduling messages. The server MAY auto-delete calendar object resources in the scheduling Outbox collection (e.g., after a period of time or to keep within a quota). New access control privileges can be used on the scheduling Outbox collection to control who is allowed to send scheduling messages on behalf of the calendar user associated with the scheduling Outbox collection. See for more details. When the server also supports the calendar-access feature, a scheduling Outbox collection MUST not be a child (at any depth) of a calendar collection resource.

A scheduling Inbox collection contains incoming scheduling messages. These may be requests sent by an Organizer, or replies sent by an Attendee in response to a request. 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:

]]>

Example:

]]>

Every non-collection resource in the scheduling Inbox collection MUST be a valid calendar object resource that defines a scheduling message (i.e. an iCalendar object that follows the iTIP semantic). Note, that unlike calendar collections defined by the calendar-access feature, there are no restrictions on the nature of the resources stored (e.g., there is no need to verify that the UIDs of each resource are unique) beyond the restrictions of iTIP itself. The removal of the UID restriction, in particular, is needed because multiple scheduling messages may be sent for one particular calendar component, and each of those will have the same UID property in the calendar object resource. New access control privileges can be set on the scheduling Inbox collection to control who is allowed to send scheduling messages to the calendar user associated with the scheduling Inbox collection. See for more details. When the server also supports the calendar-access feature, a scheduling Inbox collection MUST not be a child (at any depth) of a calendar collection resource.

This section describes new WebDAV properties on scheduling Inbox collection resources.

calendar-free-busy-set urn:ietf:params:xml:ns:caldav Identify the calendars that contribute to the free-busy information for the calendar user associated with the scheduling Inbox collection. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of ). Support for this property is REQUIRED. This property is required to allow a POST request to automatically determine the free busy information for each specified Recipient for immediate return in the response. A server with a fixed set of calendars per user can make this property protected. A server that allows users to create their own calendars SHOULD allow users to change their own property value.

]]>

/calendars/bernard/work/ /calendars/bernard/home/ /public/holidays/CA/ ]]>

This specification requires an additional Precondition for the PROPPATCH method. The precondition is: (CALDAV:valid-free-busy-set): One or more resources referenced in a CALDAV:calendar-free-busy-set property being stored on a scheduling Inbox collection is invalid. For example, a DAV:href element references a collection that is not a calendar collection. Note that server's MUST accept unmapped URIs (i.e. ones where a DAV:href refers to a non-existent resource) in the CALDAV:calendar-free-busy-set property and MUST ignore those when determining the free-busy information. This ensures that clients can add and remove calendar collections without affecting the validity of the CALDAV:calendar-free-busy-set property, and without requiring a specific order in which the client should carry out calendar create/delete operations and changes to the CALDAV:calendar-free-busy-set property.

This section describes new WebDAV properties for calendar object resources stored in scheduling Inbox or Outbox collections.

originator urn:ietf:params:xml:ns:caldav Indicates the Originator of the scheduling message contained in a scheduling Inbox or Outbox collection. This property MUST be protected and SHOULD NOT be returned by ). The CALDAV:originator property MUST be defined on calendar object resources stored in a scheduling Inbox or Outbox collection. Typically this will be as the result of a POST request on a scheduling Outbox collection. In that case, the value of the property MUST be the value of the Originator request header in the POST request.

DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445]) ]]>

mailto:bernard@example.com ]]>

recipient urn:ietf:params:xml:ns:caldav On a calendar object resource contained in a scheduling Outbox collection, this indicates the list of Recipients to whom the scheduling message was sent. On a calendar object resource in a scheduling Inbox collection, this indicates the recipient calendar user address that caused the scheduling message to be delivered into the scheduling Inbox collection. This property MUST be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of ). The CALDAV:recipient property MUST be defined on calendar object resources stored in a scheduling Outbox or Inbox collection. Typically this will be as the result of a POST request. In that case, for calendar object resources in a scheduling Outbox collection, the value of the property MUST be a list of calendar user addresses formed from all the addresses in any Recipient request headers in the POST request that caused the resource to be created in the collection. For calendar object resources in a scheduling Inbox collection, the value of the property MUST be the calendar user address from the Recipient request header in the POST request that caused the resource to be created in the collection. Typically this calendar user address will be one of those listed in the CALDAV:calendar-user-address-set (see ) property for the principal that owns the scheduling Inbox collection. However, it could, for example, be a calendar user address of a group that includes the calendar user associated with the scheduling Inbox collection.

DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445]) ]]>

mailto:cyrus@example.com mailto:lisa@example.com ]]>

The POST method submits a scheduling or free-busy message to one or more recipients by targeting the request at the URI of a scheduling Outbox collection. The request body of a POST method MUST contain a scheduling message or free-busy message (e.g., an iCalendar object that follows the iTIP semantic). The resource identified by the Request-URI MUST be a resource collection of type CALDAV:schedule-outbox. A submitted scheduling message will be delivered to the calendar user addresses specified in the Recipient request header. A submitted free-busy message will be immediately executed and a free-busy response returned. Preconditions: (CALDAV:supported-collection): The Request-URI MUST identify the location of a scheduling Outbox collection; (CALDAV:supported-calendar-data): The resource submitted in the POST request MUST be a supported media type (i.e. text/calendar) for scheduling or free-busy messages; (CALDAV:valid-calendar-data): The resource submitted in the POST request MUST be valid data for the media type being specified (i.e. valid iCalendar object); (CALDAV:valid-scheduling-message): The resource submitted in the POST request MUST obey all restrictions specified for the POST request (e.g., the scheduling message follows the restrictions of iTIP); (CALDAV:originator-specified): The POST request MUST include a valid Originator request header specifying a single calendar user address of the currently authenticated user; (CALDAV:originator-allowed): The calendar user identified by the Originator request header in the POST request MUST be granted the CALDAV:schedule privilege or a suitable sub-privilege on the scheduling Outbox collection being targeted by the request; (CALDAV:organizer-allowed): The calendar user identified by the ORGANIZER property in the POST request's scheduling message MUST be the calendar user (or one of the calendar users) associated with the scheduling Outbox collection being targeted by the request when the scheduling message is an outgoing scheduling message; (CALDAV:recipient-specified): The POST request MUST include one or more valid Recipient request headers specifying the calendar user address of users to whom the scheduling message will be delivered. (CALDAV:originator-reply): The calendar user identified by the Originator request header in the POST request MUST have previously received the scheduling message that is being replied to when the scheduling message is an incoming scheduling message; (CALDAV:max-resource-size): The resource submitted in the POST request MUST have an octet size less than or equal to the value of the CALDAV:max-resource-size property value on the scheduling Outbox collection targeted by the request; (CALDAV:attachments-allowed): The resource submitted in the POST request MUST NOT contain any inline ATTACH properties; Postconditions: None

Every POST request MUST include a single Originator request header that specifies the calendar user address of the originator of a given scheduling message. The value specified in this request header MUST be a calendar user address specified in the CALDAV:calendar-user-address-set property defined on the principal resource of the currently authenticated user. Also, the currently authenticated user MUST have the CALDAV:schedule privilege or a suitable sub-privilege granted on the targeted scheduling Outbox collection. In the case of an outgoing scheduling message the value of the Originator request header will typically match that of the ORGANIZER property in the scheduling message, or be one of the calendar user addresses of the calendar user associated with the scheduling Outbox collection being targeted. In the case of an incoming scheduling message the value of the Originator request header will typically match that of one of the ATTENDEE properties in the scheduling message, or be one of the calendar user addresses of the calendar user associated with the scheduling Outbox collection being targeted. However, in both of the above cases, another user may be acting on behalf of the actual calendar user to send scheduling messages. To allow for this a new privilege has been defined to allow the calendar user associated with a scheduling Outbox collection to grant to other users the right to execute POST requests on that scheduling Outbox collection. The value of the Originator request header is kept in the CALDAV:originator property on any resources saved as a result of the schedule request. This includes the copy of the scheduling message saved in the scheduling Outbox collection (if saved by the server), and scheduling messages delivered to any scheduling Inbox collection.

iTIP requires that every scheduling message contains an ORGANIZER property identifying the calendar user address of the Organizer of the calendar object. To prevent 'spoofing' (forgeries) of outgoing scheduling messages, CalDAV servers MUST verify that the calendar user address identified by the ORGANIZER property in the outgoing scheduling message data corresponds to the principal owning the scheduling Outbox collection targeted by the POST request. This MUST be done during the processing of the POST request. Note that this check is not required for incoming scheduling messages.

Every POST request MUST include one or more Recipient request headers. The value of this header is a list of one or more calendar user addresses and corresponds to the set of calendar users who will have the scheduling message delivered to them. The calendar user associated with of the scheduling Outbox collection being targeted by the POST method MUST have the CALDAV:schedule privilege or a suitable sub-privilege granted on the scheduling Inbox collection of each recipient. In the case of outgoing scheduling messages, typically the list of recipients would correspond to any ATTENDEE property values listed in the scheduling message data. However, there are cases when an ATTENDEE property valie is not listed as a Recipient, or when a Recipient is not one of the ATTENDEE property values. For example, if the Organizer of an event wishes to attend the event themselves, they must do that by including ATTENDEE property with their calendar user address as the value, as the Organizer of an event does not implicitly attend. However, the Organizer does not need to receive an invitation as they know their own participation status, so there is no need to be listed as a Recipient of the scheduling message. Alternatively, a client may have determined participation status of some Attendee's out-of-band and has no need to send another request via CalDAV. In some cases it is handy to be able to send information about a meeting to someone who is not an Attendee. In that case, there would be a Recipient in the request without a corresponding ATTENDEE property in the scheduling message data. Note that the recipient of a CalDAV scheduling message has no knowledge of who the other recipients are - they only get to see the ATTENDEE property information listed in the scheduling message data. So listing a calendar user as a Recipient and not in an ATTENDEE property is the equivalent of a 'Bcc' (blind-carbon-copy) operation in email. In the case of incoming scheduling messages, there would be one Recipient corresponding to the ORGANIZER property value listed in the scheduling message.

A POST request may deliver a scheduling message to one or more calendar users specified in the Recipient request header. Since the behavior of each recipient may vary, it is useful to get response status information for each recipient in the overall POST response. This specification defines a new XML response to convey multiple recipient status. A response to a POST method that indicates status for one or more recipients MUST be a CALDAV:schedule-response XML element. This MUST contain one or more CALDAV:response elements for each recipient, with each of those containing elements that indicate which recipient they correspond to, the scheduling status of the request for that recipient, any error codes and an optional description. See . In the case of a free-busy request, the CALDAV:response elements can also contain CALDAV:calendar-data elements which contain free busy information (e.g., an iCalendar VFREEBUSY component) indicating the busy state of the corresponding recipient, assuming that the free-busy request for that recipient succeeded.

The following are examples of response codes one would expect to be used for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a response. 200 (OK) - The command succeeded. 201 (Created) - The command succeeded and a new resource was created in the scheduling Outbox collection. 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. 507 (Insufficient Storage) - The server did not have sufficient space to record the scheduling message in a scheduling outbox being targeted by the POST request.

>> Request <<

>> Response << mailto:bernard@example.com 2.0;Success Delivered to recipient scheduling inbox mailto:cyrus@example.com 2.0;Success Delivered to recipient scheduling inbox ]]>

In this example, the client requests the server to deliver a meeting invitation (scheduling REQUEST) to the calendar users mailto:bernard@example.com and mailto:cyrus@example.com. The response indicates that delivery to the relevant scheduling Inbox collections of each recipient was accomplished successfully. Note that the Originator and Organizer calendar user addresses were both set to mailto:lisa@example.com. In order to indicate that she is also attending the meeting, mailto:lisa@example.com also included an ATTENDEE property in the iCalendar data corresponding to her calendar user address, however she did not include a Recipient request header for that calendar user address since she already has here own copy of the meeting stored in a calendar collection.

>> Request <<

>> Response << mailto:bernard@example.com 2.0;Success BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN METHOD:REPLY BEGIN:VFREEBUSY DTSTAMP:20040901T200200Z ORGANIZER:mailto:lisa@example.com DTSTART:20040902T000000Z DTEND:20040903T000000Z UID:34222-232@example.com ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@ example.com FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 20040902T090000Z,20040902T170000Z/20040903T000000Z END:VFREEBUSY END:VCALENDAR mailto:cyrus@example.com 2.0;Success BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN METHOD:REPLY BEGIN:VFREEBUSY DTSTAMP:20040901T200200Z ORGANIZER:mailto:lisa@example.com DTSTART:20040902T000000Z DTEND:20040903T000000Z UID:34222-232@example.com ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 20040902T090000Z,20040902T170000Z/20040903T000000Z FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z END:VFREEBUSY END:VCALENDAR ]]>

In this example, the client requests the server to determine the busy information of the calendar users mailto:bernard@example.com and mailto:cyrus@example.com, over the time range specified by the scheduling message sent in the request. The response includes VFREEBUSY components for each of those calendar users with their busy time indicated.

>> Request <<

>> Response << mailto:bernard@example.com 2.0;Success Delivered to recipient scheduling inbox mailto:cyrus@example.com 2.0;Success Delivered to recipient scheduling inbox ]]>

In this example, the client requests the server to deliver a task assignment (scheduling REQUEST) to the calendar users mailto:bernard@example.com and mailto:cyrus@example.com. The response indicates that delivery to the relevant scheduling Inbox collections of each recipient was accomplished successfully.

Incoming scheduling messages will be stored in a scheduling Inbox collection. As per , CalDAV calendar-access reports work on scheduling collections, so the client can use those to get partial information on scheduling messages in the scheduling inbox.

>> Request <<

>> Response <<

Scheduling messages are delivered into a recipient's scheduling Inbox collection. To process these messages a calendar user agent client needs to follow a sequence of steps to ensure good interoperability with other clients that may also be monitoring or processing the scheduling Inbox collection. Processing a scheduling message in a scheduling Inbox collection requires the client to read the message, determine the nature of the scheduling operation, make appropriate adjustments to the recipients actual calendars, and then, if required, send a response. In order to ensure that only one client at a time is processing scheduling messages in a scheduling Inbox collection, clients SHOULD use the WebDAV locking feature to lock the entire scheduling Inbox collection for the duration of its processing step. Once a collection is locked, other clients attempting to obtain their own lock will fail as the WebDAV server will return a protocol error at that point. When a scheduling message has been processed by a client it MUST delete that message from the scheduling Inbox collection before removing the WebDAV lock on the scheduling Inbox collection. This ensures that other clients will not in the future attempt to process the scheduling message again. describes some sample workflows of scheduling message processing.

This specification defines additional property parameters to allow the Organizer and the Attendees to register state information about incoming scheduling messages to allow them to handle messages that arrive in an unexpected order, as per Section 2.1.5 in .

RECEIVED-SEQUENCE To specify the value of the SEQUENCE iCalendar property that was specified in the most recent scheduling message received by the Organizer. This iCalendar property parameter is defined by the following notation:

received-sequenceparam = "RECEIVED-SEQUENCE" "=" integer

This iCalendar parameter can be specified on the ATTENDEE iCalendar property to specify the value of the SEQUENCE iCalendar property that was specified in the most recent scheduling message received from the corresponding Attendee. The following is an example of this parameter on the ATTENDEE property:

ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2; RECEIVED-DTSTAMP=20070214T123456Z:mailto:cyrus@example.com

RECEIVED-DTSTAMP To specify the value of the DTSTAMP iCalendar property that was specified in the most recent scheduling message received by the Organizer or an Attendee. This iCalendar property parameter is defined by the following notation:

received-dtstampparam = "RECEIVED-DTSTAMP" "=" date-time

This iCalendar parameter can be specified on the ATTENDEE and ORGANIZER iCalendar properties. When specified on the ATTENDEE iCalendar property this parameter specifies the value of the DTSTAMP iCalendar property that was specified in the most recent reply scheduling message received from the corresponding Attendee. When specified on the ORGANIZER iCalendar property this parameter specifies the value of the DTSTAMP iCalendar property that was specified in the most recent scheduling message received from the Organizer. This parameter MUST be specified as a DATE-TIME value in UTC. The following are examples of this parameter on the ATTENDEE and ORGANIZER iCalendar properties:

ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2; RECEIVED-DTSTAMP=20070214T123456Z:mailto:cyrus@example.com ORGANIZER;CN="Bernard Desruisseaux";RECEIVED-DTSTAMP=20070214T11 4523Z:mailto:bernard@example.com

The Originator request header value is a URI which specifies the calendar user address of the originator of the scheduling message. Note that the absoluteURI production is defined in RFC3986.

The Recipient request header value is a URI which specifies the calendar user address of the recipients to which the POST method should deliver the submitted scheduling message. Note that the absoluteURI production is defined in RFC3986

Server implementations that advertise support for the "calendar-schedule" feature of CalDAV MUST support WebDAV ACL as well as the scheduling privileges defined in this section. The tables specified in clarifies which scheduling methods (e.g., REQUEST, REPLY, etc.) are controlled by each scheduling privilege defined in this section.

The CALDAV:schedule-post privilege controls the use of the POST method to submit scheduling messages for any type of calendar components on the resource. It is ignored for resources that are not scheduling Outbox collections. ]]>

The CALDAV:schedule-post-vevent privilege controls the use of the POST method to submit scheduling messages for VEVENT calendar components on the resource. It is ignored for resources that are not scheduling Outbox collections. ]]>

The CALDAV:schedule-post-vtodo privilege controls the use of the POST method to submit scheduling messages for VTODO calendar components on the resource. It is ignored for resources that are not scheduling Outbox collections. ]]>

The CALDAV:schedule-post-vjournal privilege controls the use of the POST method to submit scheduling messages for VJOURNAL calendar components on the resource. It is ignored for resources that are not scheduling Outbox collections. ]]>

The CALDAV:schedule-post-vfreebusy privilege controls the use of the POST method to submit scheduling messages for VFREEBUSY calendar components on the resource. It is ignored for resources that are not scheduling Outbox collections. ]]>

The CALDAV:schedule-deliver privilege controls the delivery of a scheduling message containing any type of calendar components coming from an Organizer. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message coming from an Organizer when the Originator is granted this privilege (or an appropriate sub-privilege) on the scheduling Inbox collection of the Recipient. ]]>

The CALDAV:schedule-deliver-vevent privilege controls the delivery of a scheduling message containing VEVENT calendar components coming from an Organizer. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message for VEVENT calendar components coming from an Organizer when the Originator is granted this privilege on the scheduling Inbox collection of the Recipient. ]]>

The CALDAV:schedule-deliver-vtodo privilege controls the delivery of a scheduling message containing VTODO calendar components coming from an Organizer. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message for VTODO calendar components coming from an Organizer when the Originator is granted this privilege on the scheduling Inbox collection of the Recipient. ]]>

The CALDAV:schedule-deliver-vjournal privilege controls the delivery of a scheduling message containing VJOURNAL calendar components coming from an Organizer. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message for VJOURNAL calendar components coming from an Organizer when the Originator is granted this privilege on the scheduling Inbox collection of the Recipient. ]]>

The CALDAV:schedule-deliver-vfreebusy privilege controls the delivery of a scheduling message containing VFREEBUSY calendar components coming from an Organizer. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message for VFREEBUSY calendar components coming from an Organizer when the Originator is granted this privilege on the scheduling Inbox collection of the Recipient. Only the delivery of VFREEBUSY calendar components that specify the PUBLISH scheduling method is allowed in scheduling Inbox collections. The use of VFREEBUSY calendar components that specify the REQUEST scheduling method is controlled by the DAV:read and CALDAV:read-free-busy privileges. ]]>

The CALDAV:schedule-respond privilege controls the delivery of a scheduling message containing any type of calendar components coming from an Attendee. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message coming from an Attendee when the Originator is granted this privilege (or an appropriate sub-privilege) on the scheduling Inbox collection of the Recipient. ]]>

The CALDAV:schedule-respond-vevent privilege controls the delivery of a scheduling message containing VEVENT calendar components coming from an Attendee. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message for VEVENT calendar components coming from an Attendee when the Originator is granted this privilege on the scheduling Inbox collection of the Recipient. ]]>

The CALDAV:schedule-respond-vtodo privilege controls the delivery of a scheduling message containing VTODO calendar components coming from an Attendee. It is ignored for resources that are not scheduling Inbox collections. Server implementations MUST only deliver a scheduling message for VTODO calendar components coming from an Attendee when the Originator is granted this privilege on the scheduling Inbox collection of the Recipient. ]]>

CALDAV:schedule is an aggregate privilege that contains the entire set of scheduling privileges that can be applied to the resource. It is ignored for resources that are not scheduling Outbox or Inbox collections. ]]>

Server implementations MUST aggregate the scheduling privileges as follows: DAV:bind MUST contain CALDAV:schedule. CALDAV:schedule MUST contain CALDAV:schedule-post, CALDAV:schedule-deliver, and CALDAV:schedule-respond. CALDAV:schedule-post MUST contain CALDAV:schedule-post-vevent, CALDAV:schedule-post-vtodo, CALDAV:schedule-post-vjournal, and CALDAV:schedule-post-vfreebusy. CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver-vevent, CALDAV:schedule-deliver-vtodo, CALDAV:schedule-deliver-vjournal, and CALDAV:schedule-deliver-vfreebusy. CALDAV:schedule-respond MUST contain CALDAV:schedule-respond-vevent, and CALDAV:schedule-respond-vtodo. All the scheduling privileges MUST be non-abstract and MUST appear in the DAV:supported-privilege-set property of scheduling Outbox and 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.

schedule-inbox-URL urn:ietf:params:xml:ns:caldav Identify the URL of the scheduling Inbox collection owned by the associated principal resource. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of ). This property is needed for a client to determine where the scheduling Inbox collection of the current user is located so that processing of scheduling messages can occur.

]]>

schedule-outbox-URL urn:ietf:params:xml:ns:caldav Identify the URL of the scheduling Outbox collection owned by the associated principal resource. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of ). This property is needed for a client to determine where the scheduling Outbox collection of the current user is located so that sending of scheduling messages can occur.

]]>

calendar-user-address-set urn:ietf:params:xml:ns:caldav Identify the calendar addresses of the associated principal resource. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of ). Support for this property is REQUIRED. This property SHOULD be searchable using the DAV:principal-property-search REPORT. The DAV:principal-search-property-set REPORT SHOULD identify this property as such. This property is needed to map Originator and Recipient values in a POST request to principal resources and their associated scheduling Inbox and Outbox collections. In the event that a user has no well defined identifier for their calendar user address, the URI of their principal resource can be used.

]]>

mailto:bernard@example.com mailto:bernard.desruisseaux@example.com ]]>

In this example, the client requests the CALDAV:calendar-home-set of the principal resources whose CALDAV:calendar-user-address-set property contains the substring "mailto:bernard@example.com". In addition, the client requests the DAV:displayname of each principal to also be returned for the matching principals. The response shows that only one principal resource meets the search specification, "mailto:bernard@example.com".

>> Request << mailto:bernard@example.com ]]>

>> Response << /users/bernard /home/bernard/ Bernard Desruisseaux HTTP/1.1 200 OK ]]>

In this example, the client requests the CALDAV:schedule-inbox-URL and CALDAV:schedule-outbox-URL of the currently authenticated user. TODO: principal-match report

When the calendar-access feature is supported in addition to calendar-schedule, this specification extends the CALDAV:calendar-query and CALDAV:calendar-multiget reports to return results for calendar object resources in scheduling Inbox and Outbox collections when the report directly targets such a collection. i.e. the Request-URI for a REPORT MUST be the URI of the scheduling Inbox or Outbox collection or of a child resource within a scheduling Inbox or Outbox collection. A report run on a regular collection that includes a scheduling Inbox or Outbox collection as a child resource at any depth MUST NOT examine or return any calendar object resources from within any scheduling Inbox or Outbox collections. Note that the CALDAV:free-busy-query report is NOT supported on scheduling Inbox or Outbox collections when the calendar-access feature is also present.

schedule-response urn:ietf:params:xml:ns:caldav Contains the set of responses for a POST method request. See .

]]>

response urn:ietf:params:xml:ns:caldav Contains a single response for a POST method request. See .

]]>

recipient urn:ietf:params:xml:ns:caldav The calendar user address (recipient header value) that the enclosing response for a POST method request is for. See .

]]>

request-status urn:ietf:params:xml:ns:caldav The iTIP REQUEST-STATUS property value for this response. See .

]]>

The process of scheduling involves the sending and receiving of scheduling messages. As a result, the security problems related to messaging in general are relevant here. In particular the authenticity of the scheduling messages needs to be verified absolutely. Servers and clients MUST use an HTTP connection protected with TLS as defined in for all scheduling transactions.

When handling a POST request on a scheduling Outbox collection: Servers MUST verify that the principal associated with the calendar user address specified in the Originator request header in the request matches the currently authenticated user. Servers MUST verify that the currently authenticated user has the CALDAV:schedule privilege or a suitable sub-privilege on the scheduling Outbox collection targeted by the request. Servers MUST verify that the principal associated with the calendar user address specified in the ORGANIZER property of the scheduling message data in the request contains a CALDAV:schedule-outbox-URL property value that matches the scheduling Outbox collection targeted by the request. Servers MUST verify that the principal associated with the calendar user address specified in the ORGANIZER property of the scheduling message data in the request has the CALDAV:schedule privilege or a suitable sub-privilege on all of the scheduling Inbox collections for the principals associated with all of the calendar user addresses specified in any Recipient request headers in the request. The CALDAV:calendar-free-busy-set property on principal resources SHOULD only be accessible when that principal is authenticated (i.e., the property SHOULD be hidden from other principals).

This specification registers two new headers for use with HTTP as per .

Header field name: Originator Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none

Header field name: Recipient Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification Related information: none

The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Mike Douglass, Julian F. Reschke, Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim Whitehead. The authors would also like to thank the Calendaring and Scheduling Consortium for advice with this specification, and for organizing interoperability testing events to help refine it.

&rfc2119; &rfc2246; &rfc2445; &rfc2446; &rfc2616; &rfc2818; &rfc3744; &rfc3986; &rfc4346; &rfc4791; &rfc4918; &W3C.REC-xml-20060816; &rfc2447; &rfc3864;

The following tables specify which scheduling privileges can grant the right to a user to have a scheduling message of a specific calendar component type with a specific scheduling method be delivered in the scheduling Inbox of another user.

The following tables specify which scheduling privileges can grant the right to a user to submit, with the POST request method, a scheduling message of a specific calendar component type with a specific scheduling method on a scheduling Outbox collection.

This section describes some example scheduling workflows that give a general idea of how scheduling is carried out between CalDAV clients and servers from the perspective of meeting organizers and attendees.

Bernard creates a new event with Lisa, Cyrus and himself as attendees and decides to send Lisa and Cyrus an invitation to this event. Bernard's CUA creates a new event in a calendar collection and submits a scheduling request message through Bernard's scheduling Outbox collection to cause the server to deliver the event invitation to Lisa and Cyrus. Lisa and Cyrus will receive the scheduling request message in their scheduling Inbox collection.

Cyrus' CUA polls his scheduling Inbox collection for new scheduling messages. When the new scheduling request message from Bernard is found, the CUA alerts Cyrus. When Cyrus is ready to process the new scheduling request message, Cyrus' CUA locks the scheduling Inbox collection and retrieves the new scheduling request message. The CUA then searches Cyrus' calendar collections to find an event with the same UID property value as the one specified in the scheduling request message. Here, no event is found since the scheduling request message is for a new event. Cyrus is presented with the new scheduling request message and decides to accept the event invitation and to reply to Bernard. Cyrus' CUA creates a new event in a calendar collection for the event invitation that was received. The created event specifies Cyrus' updated PARTSTAT parameter on his ATTENDEE property, as well as the RECEIVED-DTSTAMP parameter on the ORGANIZER property. Cyrus' CUA submits a scheduling reply message through Cyrus' scheduling Outbox collection to cause the server to deliver the reply to Bernard. Cyrus' CUA deletes the scheduling request message contained in Cyrus' scheduling Inbox collection and unlocks the collection.

Bernard's CUA polls his scheduling Inbox collection to retrieve the list of scheduling messages currently contained in the collection. When the new scheduling reply message is found, Bernard's CUA locks the scheduling Inbox collection and retrieves the new scheduling reply message. The CUA will then search Bernard's calendar collections to find an event with the same UID property value as the one specified in the scheduling reply message. The original event created by Bernard will be found. Bernard's CUA updates the PARTSTAT, RECEIVED-DTSTAMP, and RECEIVED-SEQUENCE parameters of Cyrus' ATTENDEE property in the original event that was found. Bernard's CUA deletes the scheduling reply message contained in the Bernard's scheduling Inbox collection and unlocks the collection.

Bernard reschedules the event with Lisa and Cyrus and decides to send an updated event invitation to Lisa and Cyrus. Bernard's CUA updates the event in the calendar collection and submits a new scheduling request message through Bernard's scheduling Outbox collection to cause the server to deliver the event invitation to Lisa and Cyrus. Lisa and Cyrus will receive the scheduling request message in their scheduling Inbox collection.

Lisa's CUA polls her scheduling Inbox collection for new scheduling messages. When the new scheduling request message from Bernard is found, Lisa's CUA locks the scheduling Inbox collection and retrieves the new scheduling request message. The CUA will then search Lisa's calendar collections to find an event with the same UID property value as the one specified in the scheduling request message. The event previously created in Lisa's calendar collection will be found. Lisa's CUA automatically updates the event with the new information provided in the new scheduling request message and also updates the PARTSTAT parameter of Lisa's ATTENDEE property to NEEDS-ACTION, as well as the value of the RECEIVED-DTSTAMP parameter on the ORGANIZER property to match the value of the DTSTAMP property specified in the received scheduling request message. Lisa's CUA deletes the scheduling request messages contained in Lisa's scheduling Inbox collection and unlocks the collection. At some later point, Lisa decides to accept the updated event. Lisa's CUA updates the PARTSTAT parameter on her ATTENDEE property for the event stored in her calendar collection. Lisa's CUA submits a scheduling reply message through Lisa's scheduling Outbox collection to cause the server to deliver the reply to Bernard.

Updated to rfc3986 reference. Added Appendix with example workflow. Change calendar-home-URL to calendar-home-set. Updated to RFC 4791 reference. Updated to RFC 4918 reference. Changed title. Added text to explain that VTODO and VJOURNAL are also valid scheduling components in CalDAV. Changed order of Inbox and Outbox definition in section 5. Added CALDAV:valid-free-busy-set pre-condition. Re-worked descriptions of originator, recipient request headers to distinguish between iTIP outgoing and incoming modes. Removed 502 status code description for POST. Modified 507 status code description for POST to apply to Outbox storage only. Added example of task assignment. Use application/xml instead of text/xml. Inbox and Outbox cannot be contained within a calendar collection. Added an appendix summarizing scheduling privileges. Added registration for the new HTTP headers. Redefined the set of scheduling privileges. Minor terminology/formatting tweaks.

Added free-busy example. Better abstract. Requiring DAV level 2 for locking of Inbox. Do not require servers to actually save Outbox requests. Removed CALDAV:schedule-state Property. Clients now must remove inbox items after processing them, using locking etc to prevent race conditions. Switched back to 2518 reference from 2518bis. Updated to more recent XML reference. Revised required features section to better match caldav-access.

Split schedule privilege into three sub-privileges. Made support for caldav-access optional. Changed SCHEDULE method to POST.

Updated to latest references including 2518bis. Added principal property CALDAV:calendar-user-address-set. Major changes to schedule method, including addition of preconditions. New principal properties added. Text related to alternative ways of doing scheduling (some speculative) removed. Added Security Considerations text. Added IANA consideration text.