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

Applications calsched calsch caldav calendar calendaring scheduling webdav iCal iCalendar iTIP text/calendar HTTP This document defines extensions to the CalDAV calendar-access feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.

This document specifies an extension to the CalDAV calendar-access feature to enable scheduling of iCalendar-based calendar components between calendar users. This extension leverages the scheduling methods defined in the iCalendar Transport-independent Interoperability Protocol iTIP to permit calendar users to perform scheduling transactions such as schedule, reschedule, respond to scheduling request or cancel scheduled calendar components, as well as search for busy time information. iTIP outlines a model where calendar users exchange scheduling messages with one another. Often times, calendar user agents are made responsible for generating and sending scheduling messages as well as processing incoming scheduling messages. This approach yields a number of problems, including: The handling of incoming scheduling messages and the updates to calendars imposed by these messages only occurs when calendar user agents are active. For most updates to a calendar, calendar user agents need to address a separate scheduling message to the Organizer or the Attendees. Due to the update latency it is possible for calendars of different calendar users to reflect different, inaccurate states. This specification is using an alternative approach where the server is made responsible for sending most scheduling messages and processing most incoming scheduling messages. This approach frees the calendar user agents from the delivery and processing of most scheduling messages and ensures a better consistency of the data in the users' calendars on the server. The simple operation of creating, modifying or deleting a calendar object resource in a calendar is enough to trigger the CalDAV server to deliver appropriate scheduling messages to the calendar users. Discussion of this Internet-Draft is taking place on the mailing list <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

While the scheduling features described in this specification are based on iTIP, some of its more complex features have deliberately not been implemented, in order to keep this specification simple. In particular, the following iTIP features are not supported: Sending scheduling messages with the METHODs "PUBLISH", "COUNTER" and "DECLINE-COUNTER" Delegating an Event to another calendar user Changing the Organizer Forwarding to an uninvited calendar user The goal of this specification is to provide the essential scheduling features needed, and it is anticipated that future extensions will be developed to address the more complex features if the demand arises.

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.

Software with which the calendar user communicates with a calendar service or local calendar store to access calendar information. Same as . Same as . 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. A scheduling object resource owned by an Organizer. A scheduling object resource owned by an Attendee. Add, change or remove operations on a scheduling object resource for which the server will deliver scheduling messages to other users. Scheduling requests targeted at a scheduling Outbox collection. A calendar object resource that describes a scheduling transaction such as publish, schedule, reschedule, respond to scheduling requests, or cancel calendar components. A resource at which explicit scheduling requests are targeted. A collection in which a recipient's incoming scheduling messages are delivered.

Need to discuss in a limited fashion how group calendar user addresses might be handled. Need a mechanism to allow clients to be able to do "weak" If-Match updates to calendar data without the "strong" ETag behavior.

In order for a server to support the scheduling extensions defined in this specification it MUST support all of the CalDAV calendar-access feature. A server that supports the features described in this document MUST include "calendar-auto-schedule" as a field in the DAV response header from an OPTIONS request on any resource that supports any scheduling actions, properties, privileges or methods.

>> Request <<

>> Response <<

In this example, the OPTIONS response indicates that the server supports both the "calendar-access" and "calendar-auto-schedule" features and that resource "/lisa/calendar/outbox/" supports the properties, reports, methods, and privileges defined in this specification.

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 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 "freebusy" lookup. In the second phase, the Organizer sends out invitations to each Attendee using the time determined from the freebusy lookup - or a suitable guess as to an appropriate time based on other factors if freebusy 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. 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. The user "expectation" as to how a calendaring and scheduling system should respond in each of these two phases is somewhat different. In the case of a freebusy lookup, users expect to get back results immediately so that they can then move on to the invitation phase as quickly as possible. In the case of invitations, it is expected that each Attendee will reply with their participation status in their own time, so delays in receiving replies are anticipated. Thus calendaring and scheduling systems should treat these two operational phases in different ways to accommodate the user expectations, and this specification does that. The scenario above covers the case of scheduling events ("VEVENT" components) between calendar users, and doing freebusy 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 freebusy lookups will be discussed as these are the more common operations. In this specification there are two primary modes of carrying out a scheduling transaction. For an "automatic scheduling transaction", calendar data created, modified or removed from calendar collections cause scheduling operations to occur. For an "explicit scheduling request", scheduling operations are triggered by an HTTP POST request to a special resource. iTIP freebusy lookups and iTIP "METHOD:REFRESH" operations are done via explicit scheduling requests. All other scheduling operations defined in iTIP, except for "METHOD:COUNTER" and "METHOD:DECLINECOUNTER" which are not supported, are done via automatic scheduling transactions.

This specification introduces new collection resource types that are used for managing resources specific to scheduling, in addition to regular calendar object resources.

A scheduling Outbox collection is used as the target for initiating the processing of manual scheduling messages. Currently the only defined use for this is for "VFREEBUSY" "REQUEST" iTIP messages to request a synchronous freebusy lookup for a number of calendar users. 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:

]]>

New WebDAV ACL 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. A scheduling Outbox collection MUST NOT be a child (at any depth) of a calendar collection resource. A scheduling Outbox collection MAY have the following WebDAV properties defined (as per calendar collections in ): CALDAV:supported-calendar-component-set - when present this indicates the allowed calendar component types for scheduling messages submitted to the scheduling Outbox collection with the POST method. CALDAV:supported-calendar-data - when present this indicates the allowed media types for scheduling messages submitted to the scheduling Outbox collection with the POST method. CALDAV:max-resource-size - when present this indicates the maximum size of a resource in octets that the server is willing to accept for scheduling messages submitted to the scheduling Outbox collection with the POST method. CALDAV:min-date-time - when present this indicates the earliest date and time (in UTC) that the server is willing to accept for any DATE or DATE-TIME value in scheduling messages submitted to the scheduling Outbox collection with the POST method. CALDAV:max-date-time - when present this indicates the latest date and time (in UTC) that the server is willing to accept for any DATE or DATE-TIME value in scheduling messages submitted to the scheduling Outbox collection with the POST method. CALDAV:max-instances - when present this indicates the maximum number of recurrence instances in scheduling messages submitted to the scheduling Outbox collection with the POST method. CALDAV:max-attendees-per-instance - when present this indicates the maximum number of ATTENDEE properties in any instance of scheduling messages submitted to the scheduling Outbox collection with the POST method.

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 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 CalDAV calendar-access feature, there are no restrictions on the nature of the resources stored (e.g., there is no need to verify that the "UID"s 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. This also implies that a scheduling Inbox collection cannot contain any types of WebDAV collection resources. New WebDAV ACL privileges can be set on the scheduling Inbox collection to control who the user associated with the scheduling Inbox collection will accept scheduling messages from. See for more details. A scheduling Inbox collection MUST NOT be a child (at any depth) of a calendar collection resource. A scheduling Inbox collection MAY have the following WebDAV properties defined (as per calendar collections in ): CALDAV:calendar-timezone - when present this contains a time zone that the server can use when calendar date-time operations are carried out, for example when a time-range CALDAV:calendar-query REPORT is targeted at a scheduling Inbox collection. CALDAV:supported-calendar-component-set - when present this indicates the allowed calendar component types for scheduling messages delivered to the scheduling Inbox collection. CALDAV:supported-calendar-data - when present this indicates the allowed media types for scheduling messages delivered to the scheduling Inbox collection. CALDAV:max-resource-size - when present this indicates the maximum size of a resource in octets that the server is willing to accept for scheduling messages delivered to the scheduling Inbox collection. CALDAV:min-date-time - when present this indicates the earliest date and time (in UTC) that the server is willing to accept for any DATE or DATE-TIME value in scheduling messages delivered to the scheduling Inbox collection. CALDAV:max-date-time - when present this indicates the latest date and time (in UTC) that the server is willing to accept for any DATE or DATE-TIME value in scheduling messages delivered to the scheduling Inbox collection. CALDAV:max-instances - when present this indicates the maximum number of recurrence instances in scheduling messages delivered to the scheduling Inbox collection. CALDAV:max-attendees-per-instance - when present this indicates the maximum number of ATTENDEE properties in any instance of scheduling messages delivered to the scheduling Inbox collection.

When a calendar object resource is created, modified or removed from a calendar collection that supports the operations defined in this specification (either via a PUT, DELETE, COPY or MOVE HTTP request), the server examines the calendar data and checks to see whether the data represents a scheduling object resource. If it does, the server will take care of automatically sending and processing scheduling messages to the appropriate recipients. Several types of scheduling operation can occur in this case, equivalent to iTIP "REQUEST", "REPLY", "CANCEL" and "ADD" operations. When a scheduling transaction is processed by the server, it will attempt to deliver a scheduling message to each recipient.

The server will only perform automatic scheduling transactions on creations, modifications, and deletions of valid 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 that at least one of the "ATTENDEE" iCalendar property values match one of the calendar user addresses of the owner of the calendar collection. The creation of attendee scheduling object resources will typically be done by the server in cases where a default calendar collection is defined (see . In cases where no default calendar collection is defined, the server MAY prevent calendar user agents from forging attendee scheduling object resources by forbidding their creation or imposing restrictions on their creation. For instance, a server MAY require the presence of a scheduling message, received from the "ORGANIZER" with the same "UID" property value, in the scheduling Inbox collection of the owner of the calendar collection.

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.

An Organizer can create, modify or remove a scheduling object resource by issuing HTTP requests with an appropriate method. The create, modify and remove behaviors for the server are each described next, and the way these are invoked via HTTP requests is described in .

When a scheduling object resource is created by the Organizer, the server will inspect each "ATTENDEE" property to determine which ones have the "SCHEDULE-AGENT" iCalendar property parameter. For each Attendee the server will determine whether to attempt to deliver a scheduling message into the Attendee's scheduling Inbox collection, based on the table below:

The attempt to deliver the scheduling message will either succeed or fail. In all cases, the server MUST add a "SCHEDULE-STATUS" iCalendar property parameter to the "ATTENDEE" iCalendar property in the scheduling object resource being created, and set its value as described in . This will result in the created calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server as soon as it is stored in order to update to the new server generated state information. Servers MUST NOT set the "SCHEDULE-STATUS" property on any "ATTENDEE" properties for Attendees that were not sent a scheduling message. Restrictions: The server MAY reject any attempt to set the "PARTSTAT" iCalendar property parameter value of the "ATTENDEE" iCalendar property of other users in the calendar object resource to a value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value is not present or set to the value "SERVER". To maintain consistency for organizers and attendees hosted on the server itself, a server will typically choose to enforce the requirement that only an Attendee can change their own "PARTSTAT" to a value other than "NEEDS-ACTION". The server MUST reject any attempt to create a duplicate scheduling object resource in any of the calendar collections owned by the Organizer. A duplicate scheduling object resource is one with the same "UID" as an existing scheduling object resource. The server MUST take into account scheduling privileges when handling the creation of a scheduling object resource as described in . Restrictions from MUST also be enforced.

When a scheduling object resource is modified by the Organizer, the server will inspect each "ATTENDEE" property in the new calendar data to determine which ones have the "SCHEDULE-AGENT" iCalendar property parameter. It will then need to compare this with the "ATTENDEE" properties in the existing calendar object resource that is being modified. For each Attendee in the old and new calendar data on a per-instance basis, and taking into account the addition or removal of Attendees, the server will determine whether to deliver a scheduling message to the Attendee. The following table determines whether the server needs to deliver a scheduling message, and if so which iTIP scheduling method to use. The values "SERVER", "CLIENT" and "NONE" in the top and left titles of the table refer to the "SCHEDULE-AGENT" parameter value of the "ATTENDEE" property, and the values "<Absent>" and "<Removed>" are used to cover the cases where the "ATTENDEE" property is not present (Old) or is being removed (New).

| SERVER | CLIENT | NONE | | | | (default) | | | +===+===========+===========+===========+===========+===========+ | | | -- | REQUEST / | -- | -- | | | | | ADD | | | | +-----------+-----------+-----------+-----------+-----------+ | | SERVER | CANCEL | REQUEST | CANCEL | CANCEL | | O | (default) | | | | | | l +-----------+-----------+-----------+-----------+-----------+ | d | CLIENT | -- | REQUEST / | -- | -- | | | | | ADD | | | | +-----------+-----------+-----------+-----------+-----------+ | | NONE | -- | REQUEST / | -- | -- | | | | | ADD | | | +---+-----------+-----------+-----------+-----------+-----------+ ]]>

The attempt to deliver the scheduling message will either succeed or fail. In all cases, the server MUST add a "SCHEDULE-STATUS" iCalendar property parameter to the "ATTENDEE" iCalendar property in the scheduling object resource being modified, and set its value as described in . This will result in the created calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server as soon as it is stored in order to update to the new server generated state information. Restrictions: The server MAY reject any attempt to set the "PARTSTAT" iCalendar property parameter value of the "ATTENDEE" iCalendar property of other users in the calendar object resource to a value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value is not present or set to the value "SERVER". To maintain consistency for organizers and attendees hosted on the server itself, a server will typically choose to enforce the requirement that only an Attendee can change their own "PARTSTAT" to a value other than "NEEDS-ACTION". The server MUST take into account scheduling privileges when handling the modification of a scheduling object resources as described in Section . Restrictions from MUST also be enforced.

When a scheduling object resource is removed by the Organizer, the server will inspect each "ATTENDEE" property in the scheduling object resource being removed to determine which ones have the "SCHEDULE-AGENT" iCalendar property parameter. For each Attendee the server will determine whether to attempt to deliver a scheduling message into the Attendee's scheduling Inbox collection, based on the table below:

The attempt to deliver the scheduling message will either succeed or fail. Restrictions: The server MUST take into account scheduling privileges when handling the removal of a scheduling object resource as described in .

An Attendee can create, modify or remove a scheduling object resource by issuing HTTP requests with an appropriate method. The create, modify and remove behaviors for the server are each described next, and the way these are invoked via HTTP requests is described in .

Attendees are allowed to make some changes to a scheduling object resource, though the key scheduling properties such as start, end, location, summary etc are typically under the control of the Organizer of the event. The server MUST allow attendees to: change their own "PARTSTAT" iCalendar property parameter value. add or remove "X-" iCalendar property parameters on their own "ATTENDEE" properties. add, modify or remove any "TRANSP" iCalendar properties. add, modify or remove any "X-" iCalendar properties in any component. add, modify or remove any "VALARM" iCalendar components. modify the "PRODID" iCalendar property within the top-level "VCALENDAR" component. add, modify or remove "CALSCALE" or "X-" iCalendar properties within the top-level "VCALENDAR" component. create new components to represent overridden recurrence instances, provided the only changes to the recurrence instance follow the rules above.

A scheduling object resource is created by an Attendee when the client creates a scheduling object resource corresponding to an unprocessed scheduling message currently in that Attendee's scheduling Inbox collection. The Attendee is allowed to make changes as noted above. If the Attendee changes one or more "PARTSTAT" iCalendar property values on any component, or adds an overridden component with a changed "PARTSTAT" property, then the server MUST deliver an iTIP "REPLY" scheduling message to the Organizer to indicate the new participation status of the Attendee. The attempt to deliver the scheduling message will either succeed or fail. In all cases, the server MUST add a "SCHEDULE-STATUS" iCalendar property parameter to the "ORGANIZER" iCalendar property in the scheduling object resource being created, and set its value as described in . This will result in the created calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server as soon as it is stored in order to update to the new server generated state information.

Behavior is as per the Create action above.

When a scheduling object resource is removed by the Attendee, one of two possibilities exist: If the HTTP request contains a request header "Schedule-Reply" set to the value "T" or there is no "Schedule-Reply" request header, then the server MUST attempt to deliver a scheduling message to the Organizer indicating that the Attendee has a "PARTSTAT" iCalendar property parameter value set to "DECLINED". i.e., the Attendee has chosen not to attend any instances. If the server is unable to deliver the scheduling message, the remove action MUST fail, and an appropriate "SCHEDULE-STATUS" iCalendar property parameter set on the "ORGANIZER" property in the scheduling object resource stored by the server. If the HTTP request contains a request header "Schedule-Reply" set to the value "F", the server MUST NOT attempt to deliver a scheduling message. The resource is simply removed. This provides the client a way to silently remove unwanted scheduling attempts.

This section describes how use of various HTTP Methods on a scheduling object resource will cause a create, modify or remove action on that resource as described above.

When a PUT method request is received, the server will execute the following actions, provided all appropriate pre-conditions are met: Existing Destination Resource Resulting Destination Resource Server Action None Calendar object resource None (1) None Scheduling object resource Create (2) Calendar object resource Calendar object resource None Calendar object resource Scheduling object resource Create (1) Scheduling object resource Calendar object resource Remove Scheduling object resource Scheduling object resource Modify Note 1. The server MUST verify that no scheduling object resource exists in any other of the owner's calendar collections with the same UID as the resource being created. Note 2. The server MUST verify that no calendar object resource exists in any other of the owner's calendar collections with the same UID as the resource being created.

When a COPY method request is received, the server will execute the following actions based on the source and destination collections in the request: Source Collection Destination Collection Server Action Non-calendar collection Non-calendar collection None Non-calendar collection Calendar collection (1) Calendar collection Non-calendar collection None Calendar collection Calendar collection (2) Note 1. The same rules as used for PUT above are applied for the destination of the COPY request. Note 2. If the resource being copied is a scheduling object resource the server MUST generate an error as scheduling object resources cannot be duplicated. If the resource being copied is not a scheduling object resource no server action occurs.

When a MOVE method request is received, the server will execute the following actions based on the source and destination collections in the request: Source Collection Destination Collection Server Action Non-calendar collection Non-calendar collection None Non-calendar collection Calendar collection (1) Calendar collection Non-calendar collection (2) Calendar collection Calendar collection (3) Note 1. The same rules as used for PUT above are applied for the destination of the MOVE request. Note 2. The same rules as used for DELETE below are applied for the source of the MOVE request. Note 3. If the destination resource does not exist the server action is None. If the source and destination resources are not scheduling object resources then the server action is None. In all other cases the server MUST generate an error as scheduling object resources cannot be duplicated or overwritten by different scheduling object resources.

When a DELETE method is targeted at a scheduling object resource the server will execute the Remove action. When a DELETE method is targeted at a calendar collection the server will execute the Remove action on all scheduling object resources contained in the calendar collection.

Scheduling operations can cause the delivery of a scheduling message into an Organizer's or Attendee's scheduling Inbox collection. In the former case the scheduling messages are replies or refresh requests from Attendees, in the latter case the scheduling messages are requests, cancellations or additions from the Organizer. In some cases the server will automatically process the scheduling message, in other cases the scheduling message will be left for the client to process. In each case, the scheduling message in the scheduling Inbox collection is used as an indicator to the client that a scheduling operation has taken place.

For a scheduling message reply sent by an Attendee, the server first locates the corresponding scheduling object resource belonging to the Organizer. The server MUST then update the "PARTSTAT" iCalendar 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 sets 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). At the same time, the server MUST add the CALDAV:schedule-state WebDAV property with the value CALDAV:schedule-processed (see ) to the scheduling message in the Inbox scheduling collection. The server MUST send scheduling messages to all the other Attendees indicating the change in participation status of the Attendee replying, subject to the recurrence requirements of .

TODO: write something here.

For a scheduling message sent by the 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.

When a scheduling message containing new calendar components is detected, two possibilities exist, depending on whether a "default" calendar is set for the Attendee: if no valid default calendar is set, the server leaves the scheduling message in the scheduling Inbox collection, but it MUST add the CALDAV:schedule-state WebDAV property with the value CALDAV:schedule-unprocessed (see ) to the scheduling message. It is then up to the client to explicitly process the scheduling message and remove it from the scheduling Inbox collection once it has done so. if a valid default calendar is set, the server MUST process the scheduling message and create an appropriate scheduling object resource in the default calendar set for the Attendee. At the same time it MUST add the CALDAV:schedule-state WebDAV property with the value CALDAV:schedule-processed (see ) to the scheduling message.

When an update to scheduling message is detected, the server MUST update the matching scheduling object resource belonging to the Attendee to reflect the changes proposed in the scheduling message. At the same time it MUST add the CALDAV:schedule-state WebDAV property with the value CALDAV:schedule-processed (see ) to the scheduling message.

When a client detects a scheduling message in the scheduling Inbox collection it needs to look at the CALDAV:schedule-state WebDAV property on the resource and act accordingly: if CALDAV:schedule-state is set to CALDAV:schedule-unprocessed, then it is the client's responsibility to process the scheduling message and remove it from the scheduling Inbox collection once it has done so. if CALDAV:schedule-state is set to CALDAV:schedule-processed, then the server has already processed the scheduling message, but has left it in the scheduling Inbox collection to serve as a notification to the client that a change has been made to the corresponding scheduling object resource. It is then the client's responsibility to remove the scheduling object resource from the scheduling Inbox collection once it has made note of the fact that a change has occurred.

An explicit scheduling request sends a scheduling message via an HTTP POST request targeted at a scheduling Outbox collection. Full details can be found in .

When delivering scheduling messages for recurring calendar components to Attendees, servers MUST ensure that Attendees only get information about recurrence instances that explicitly include them as an Attendee. For example, if an Attendee is invited to a single recurrence instance of a recurring event, and no others, the scheduling object resource contained in the Organizer's calendar collection will contain an overridden instance in the form of a separate calendar component. That separate calendar component will include the "ATTENDEE" property referencing the "one-off" Attendee. That Attendee will not be listed in any other calendar components in the scheduling object resource. The scheduling message that will be delivered to the Attendee will only contain information about this overridden instance. As another example, an Attendee could be excluded from one instance of a recurring event. In that case the scheduling object resource contained in the calendar collection of the Organizer will include an overridden instance with an "ATTENDEE" list that does not include the Attendee being excluded. The scheduling message that will be delivered to the Attendee will not specify the overridden instance but rather include an "EXDATE" property in the master recurring component defining the recurrence set. This requirement is needed to ensure that Attendees only have access to calendar data for items they have been explicitly invited to.

When a recurring scheduling message is sent to an Attendee, that Attendee may wish to reply with different participation status on one or more recurrence instances. In order to do that it will need to add an overridden iCalendar component for the instances with different participation status, and send that as a reply back to the Organizer. The Organizer will then need to incorporate any new overridden instances into the matching scheduling object resource to ensure that the Attendee's participation status is accurately recorded for all recurrence instances.

A calendar user may have multiple calendars representing different "spheres of activity". However, scheduling requests are targeted at calendar users and not a specific calendar of a calendar user. Often it is not appropriate to automatically deliver a scheduling message to a particular calendar because that scheduling message refers to an event for a different "sphere of activity". By storing all incoming scheduling requests in a separate special collection, clients can process the requests in that collection and choose which calendar ("sphere of activity") the request belongs to and make its own arrangements to place the relevant calendar object in that calendar. This specification defines the concept of a "default" calendar collection. If a valid default calendar collection is specified, then servers are required to automatically process new scheduling messages and create the appropriate scheduling object resource in the default calendar collection. If there is no valid default calendar, then the server does not automatically process new scheduling messages, and instead leaves it up to the client to process the scheduling message and create the appropriate scheduling object resource in a calendar collection chosen by the calendar user. Servers MAY prevent deletion of the default calendar. In order to manage this behavior, a new CALDAV:schedule-default-calendar-URL WebDAV property is defined for use on scheduling Inbox collections. This property is used to define the default calendar collection, if one is required. See .

Whenever the server generates a scheduling message for delivery to a recipient, it MUST ensure that a "DTSTAMP" iCalendar property is present and MUST set the value to the UTC time that the scheduling message was generated (as required by iCalendar). iTIP places certain requirements on how the "SEQUENCE" iCalendar property value in scheduling messages changes. The server MUST ensure that for each type of scheduling operation, the "SEQUENCE" iCalendar property value is appropriately updated. If the client does not update the "SEQUENCE" iCalendar property itself when that is required, the server MUST update the property and change any scheduling object resource accordingly.

When scheduling with an Attendee there are two types of status information that can be returned during the transaction. The first status information is a "delivery" status that indicates whether the scheduling message from the Organizer to the Attendee was delivered or not, or what the current status of delivery is. The second status information is a "reply" status corresponding to the Attendee's own "REQUEST-STATUS" information from the scheduling message reply that is sent back to the Organizer. Similarly, when an Attendee sends a reply back to the Organizer, there will be "delivery" status information for the scheduling message sent to the Organizer. However, there is no "REQUEST-STATUS" sent back by the Organizer, so there is no equivalent of the "reply" status as per scheduling messages to Attendees. The "delivery" status information on an "ORGANIZER" or "ATTENDEE" iCalendar property is conveyed in the "SCHEDULE-STATUS" property parameter value (). The status code value for "delivery" status can be one of the following: Delivery Status Code Description 1.0 The scheduling message is pending. i.e. the server is still in the process of sending the message. The status code value can be expected to change once the server has completed its sending and delivery attempts.     1.1 The scheduling message has been successfully sent. However, the server does not have explicit information about whether the scheduling message was successfully delivered to the recipient. This state can occur with "store and forward" style scheduling protocols such as iMIP (iTIP using email).     1.2 The scheduling message has been successfully delivered.     3.7 The scheduling message was not delivered because the server did not recognize the calendar user address of the recipient as being a supported URI.     3.8 The scheduling message was not delivered because access privileges do not allow it.     5.1 The scheduling message was not delivered because the server could not complete delivery of the message. This is likely due to a temporary failure, and the originator can try to send the message again at a later time.     5.2 The scheduling message was not delivered because the server was not able to find a suitable way to deliver the message. This is likely a permanent failure, and the originator should not try to send the message again, at least without verifying/correcting the calendar user address of the recipient.     5.3 The scheduling message was not delivered and was rejected because scheduling with that recipient is not allowed. This is likely a permanent failure, and the originator should not try to send the message again. The status code for "reply" status can be any of the valid iTIP "REQUEST-STATUS" values.

TODO: e.g. how to deal with failed cancels.

The Organizer of a scheduled event may also be an Attendee of that event. In such cases the server MUST NOT send a scheduling message to the Attendee that matches the Organizer.

This section describes additions to iCalendar to support CalDAV scheduling.

SCHEDULE-AGENT Indicates what agent is expected to handle scheduling for the corresponding Attendee. This property parameter is defined by the following notation:

This property parameter MAY be present on any "ATTENDEE" iCalendar property. In the absence of this parameter, the value "SERVER" MUST be used for the default behavior. The value determines whether or not an automatic scheduling transaction on a server will cause a scheduling message to be sent to the corresponding calendar user identified by the "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 messages as part of an automatic scheduling transaction. When the value "CLIENT" is specified, that indicates that the client is handling scheduling messages with the calendar user itself. When "NONE" is specified, no scheduling messages are being sent to the calendar user. Servers MUST NOT include this parameter in any scheduling messages sent as the result of an automatic scheduling transaction. Clients SHOULD NOT include this parameter in any scheduling messages that they themselves send.

SCHEDULE-STATUS Indicates the status code returned from processing of the most recent scheduling message sent to the corresponding Attendee, or received from the corresponding Organizer. This property parameter is defined by the following notation:

This property parameter may be present on any "ATTENDEE" or "ORGANIZER" iCalendar property. Servers MUST add this parameter to any "ATTENDEE" properties corresponding to calendar users who were sent a scheduling message via an automatic scheduling transaction. Clients SHOULD NOT change or remove this parameter if it was provided by the server. In the case where the client is handling the scheduling, the client MAY add, change or remove this parameter to indicate the last scheduling message status it received. Servers MUST add this parameter to any "ORGANIZER" properties corresponding to calendar users who were sent a scheduling message reply by an Attendee via an automatic scheduling transaction. Clients SHOULD NOT change or remove this parameter if it was provided by the server. In the case where the client is handling the scheduling the client MAY add, change or remove this parameter to indicate the last scheduling message status it received. Servers MUST NOT include this parameter in any scheduling messages sent as the result of an automatic scheduling transaction. Clients SHOULD NOT include this parameter in any scheduling messages that they themselves send. Suitable values for this property parameter are described in .

The CalDAV scheduling extension defines the following new WebDAV request headers for use with CalDAV.

When an Attendee executes an HTTP DELETE request on a scheduling object resource, and the Schedule-Reply header is not present, or present and set to the value "T", the server MUST send an appropriate iTIP "REPLY" scheduling message with the Attendee's "PARTSTAT" iCalendar property parameter value set to "DECLINED" as part of its normal automatic scheduling transaction processing. When the Schedule-Reply header is set to the value "F", the server MUST NOT send an iTIP scheduling message as part of its normal automatic scheduling transaction processing. The Schedule-Reply request header is used by a client to indicate to a server whether or not an automatic scheduling transaction should occur when an Attendee deletes a scheduling object resource. In particular it controls whether an iTIP "REPLY" message is sent to the Organizer as a result of the deletion. There are situations in which unsolicited scheduling messages need to be silently deleted (or ignored) for security or privacy reasons. The new header allows the scheduling message to be suppressed if such a need arises. All scheduling object resources MUST support the Schedule-Reply header.

The CalDAV scheduling extension defines the following new WebDAV properties for use with CalDAV.

schedule-calendar-transp urn:ietf:params:xml:ns:caldav Determines whether the calendar object resources in a calendar collection will affect the owner's freebusy. This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of ). This property value SHOULD be kept during a MOVE operation, but is normally re-initialized when a resource is created with a COPY. It should not be set in a COPY. This property SHOULD be defined on all calendar object resources. If present, it contains one of two XML elements that indicate whether the calendar object resources should contribute to the owner's freebusy or not. When the 'opaque' element is used, all calendar object resources MUST contribute to freebusy, assuming access privileges and other iCalendar properties allow it to. When the 'transparent' XML element is used, all calendar object resources MUST NOT contribute to freebusy. If this property is not present on a calendar collection, then the default value of 'opaque' MUST be assumed.

]]>

]]>

schedule-default-calendar-URL urn:ietf:params:xml:ns:caldav Specifies a default calendar for an attendee that will automatically have new scheduling messages deposited into it when they arrive. This property MAY be protected in the case where a server supports only a single calendar collection, or does not support changing the default calendar, or does not support a default calendar. This property is only defined on a scheduling Inbox collection which cannot be moved or copied. 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.

]]>

/calendars/users/cdaboo/calendar/ ]]>

schedule-state urn:ietf:params:xml:ns:caldav Indicates whether a scheduling message in a scheduling Inbox collection has been processed as part of an automatic scheduling transaction. This property MUST be protected as only the server can carry out automatic processing of scheduling messages. This property is only defined on a scheduling message in a scheduling Inbox collection. If a scheduling message is copied or moved into a scheduling Inbox collection, this property MUST NOT be set. This property MAY be defined on a scheduling resource in a scheduling Inbox collection. If present, it contains one of two XML elements. When the CALDAV:schedule-unprocessed XML element is used, it indicates that the scheduling message has not been automatically processed by the server, and thus needs action on the part of the client. When the CALDAV:schedule-processed XML element is used, it indicates that automatic processing of the scheduling message has taken place, so no scheduling operations are needed by the client.

]]>

]]>

This specification requires additional Preconditions for the PUT, COPY and MOVE methods. The preconditions are: (CALDAV:unique-scheduling-object-resource): Only one scheduling object resource with a particular iCalendar property "UID" value MUST exist in the system for each Organizer and each Attendee. (CALDAV:same-organizer-in-all-components): All the calendar components in a scheduling object resource MUST contain the same "ORGANIZER" property value if the "ORGANIZER" property is present.

This specification requires additional Preconditions for the PUT method. The preconditions are: (CALDAV:allowed-organizer-scheduling-object-change): The following restrictions exist for the "PARTSTAT" property value in scheduling object resources created or modified by an Organizer: when creating a scheduling object resource the Organizer MAY NOT set the "PARTSTAT" iCalendar parameter value to anything other than "NEEDS-ACTION" if the corresponding "ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar parameter with its value set to "SERVER", or no "SCHEDULE-AGENT" parameter is present. when modifying a scheduling object resource the Organizer MAY NOT change the "PARTSTAT" iCalendar parameter value to anything other than "NEEDS-ACTION" if the corresponding "ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar parameter with its value set to "SERVER", or no "SCHEDULE-AGENT" parameter is present. (CALDAV:allowed-attendee-scheduling-object-change): When creating or modifying a scheduling object resource the Attendee can only make the following changes: any iCalendar parameter on any "ATTENDEE" property whose value corresponds to the calendar user address of the Attendee add, change or remove a "TRANSP" property in any component add, change or remove a "COMMENT" property in any component add, change or remove a "PERCENT-COMPLETE" property in any component change the "PRODID" property in the top-level "VCALENDAR" component add, change or remove the "CALSCALE" property in the top-level "VCALENDAR" component add, change or remove any "VALARM" components create overridden recurring instances with only changes as detailed above The Attendee MUST NOT make any other type of change.

This specification require an additional Preconditions for the PUT method. The preconditions are: (CALDAV:default-calendar-delete-allowed): The server MAY allow deletion of the default calendar collection.

This specification requires an additional Precondition for the property response elements in PROPPATCH method response. The precondition is: (CALDAV:valid-schedule-default-calendar-URL): When the server allows the client to change the CALDAV:schedule-default-calendar-URL property on a scheduling Inbox collection, the URL specified in any DAV:href element MUST reference a calendar collection owned by the owner of the scheduling Inbox collection.

The POST method submits a scheduling or freebusy 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 freebusy 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. Only specific types of scheduling message are allowed in a POST request on a scheduling Outbox collection: iTIP METHOD COMPONENT PUBLISH None REQUEST VFREEBUSY REPLY None ADD None CANCEL None REFRESH Any except VTIMEZONE, VFREEBUSY COUNTER None DECLINECOUNTER None Servers SHOULD reject any scheduling message that is not allowed. However, for backwards compatibility with earlier versions of this specification, servers MAY return a valid schedule response result indicating success for the iTIP operation being executed. 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 freebusy 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-allowed): The currently authenticated user MUST be granted the CALDAV:schedule-deliver 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: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; Postconditions: None

When an iTIP REFRESH scheduling message is executed, the server delivers the scheduling message to the calendar user specified by the "ORGANIZER" property value in the scheduling object resource that was submitted to the scheduling Outbox collection with the POST method.

A POST request may deliver a scheduling message to one or more calendar user recipients. 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 freebusy request, the CALDAV:response elements can also contain CALDAV:calendar-data elements which contain freebusy information (e.g., an iCalendar VFREEBUSY component) indicating the busy state of the corresponding recipient, assuming that the freebusy 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 collection being targeted by the POST request.

>> Request <<

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

In this example, the client requests the server to deliver a "REFRESH" scheduling message to the Organizer of the meeting mailto:lisa@example.com. The response indicates that delivery to the relevant scheduling Inbox collection of the Organizer was accomplished successfully.

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

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

CalDAV servers MUST support and adhere to the requirements of WebDAV ACL. Furthermore, CalDAV servers that advertise support for the "calendar-auto-schedule" feature MUST also support the scheduling privileges defined in this section. All the scheduling privileges MUST be non-abstract and MUST appear in the DAV:supported-privilege-set property of scheduling Outbox and Inbox collections on which they are defined. The tables specified in clarifies which scheduling methods (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling privilege defined in this section.

This section defines new WebDAV ACL privileges that are for use on scheduling Inbox collections. These privileges determine whether a calendar user is allowed to have scheduling messages delivered to the calendar user who "owns" the scheduling Inbox collection. This allows calendar users to choose which other calendar users can schedule with them. The privileges defined in this section are ignored if applied to a resource other than a scheduling Inbox collection.

CALDAV:schedule-deliver is an aggregate privilege that contains all the scheduling privileges that control the processing and delivery of incoming scheduling messages, that is, CALDAV:schedule-deliver-invite and CALDAV:schedule-deliver-reply, as well as freebusy requests targeted at the owner of the scheduling Inbox collection, that is, CALDAV:schedule-query-freebusy. ]]>

The CALDAV:schedule-deliver-invite privilege controls the processing and delivery of scheduling messages coming from an Organizer. ]]>

The CALDAV:schedule-deliver-reply privilege controls the processing and delivery of scheduling messages coming from an Attendee. ]]>

The CALDAV:schedule-query-freebusy privilege controls freebusy requests targeted at the owner of the scheduling Inbox collection. ]]>

This section defines new WebDAV ACL privileges that are defined for use on scheduling Outbox collections. These privileges determine which calendar users are allowed to send scheduling messages on behalf of the calendar user who "owns" the scheduling Outbox collection. This allows calendar users to choose other calendar users who can act on their behalf to schedule with other calendar users (e.g. assistants working on behalf of their boss). The privileges defined in this section are ignored if applied to a resource other than a scheduling Outbox collection.

CALDAV:schedule-send is an aggregate privilege that contains all the scheduling privileges that control the use of methods that will cause scheduling messages to be delivered to other users, that is, CALDAV-schedule-send-invite and CALDAV-schedule-send-reply, as well as freebusy requests to be targeted at other users, that is, CALDAV-schedule-send-freebusy. ]]>

The CALDAV:schedule-send-invite privilege controls the sending of scheduling messages by Organizers. Users granted the DAV:bind privilege on a calendar collection, or DAV:write privilege on scheduling object resources, will also need the CALDAV:schedule-send-invite privilege granted on the scheduling Outbox collection of the owner of the calendar collection or scheduling object resource in order to be allowed to create, modify or delete scheduling object resources in a way that will trigger the CalDAV server to deliver organizer scheduling messages to other calendar users. ]]>

The CALDAV:schedule-send-invite privilege controls the sending of scheduling messages by Attendees. Users granted the DAV:bind privilege on a calendar collection, or DAV:write privilege on scheduling object resources, will also need the CALDAV:schedule-send-reply privilege granted on the scheduling Outbox collection of the owner of the calendar collection or scheduling object resource in order to be allowed to create, modify or delete scheduling object resources in a way that will trigger the CalDAV server to deliver attendee scheduling messages to other calendar users. ]]>

The CALDAV:schedule-send-freebusy privilege controls the use of the POST method to submit scheduling messages that specify the scheduling method "REQUEST" with a "VFREEBUSY" calendar component. ]]>

Server implementations MUST aggregate the scheduling privileges as follows: DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule-deliver; CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite, CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy; CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver-invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query-freebusy. The following diagram illustrates how scheduling privileges are aggregated according to the above requirements.

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 calendar user addresses in iCalendar data to principal resources and their associated scheduling Inbox and Outbox collections. In the event that a user has no well defined identifier for their calendar user address, the URI of their principal resource can be used.

]]>

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

calendar-user-type urn:ietf:params:xml:ns:caldav Identifies the calendar user type 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 OPTIONAL. 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 used to indicate the type of calendar user associated with the principal resource. Its value is the same as the iCalendar "CUTYPE" property parameter that can be used on "ATTENDEE" properties.

]]>

INDIVIDUAL< /C:calendar-user-type> ]]>

This specification extends the CALDAV:calendar-query and CALDAV:calendar-multiget reports to return results for calendar object resources in scheduling Inbox 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 collection or of a child resource within a scheduling Inbox collection. A report run on a regular collection that includes a scheduling Inbox collection as a child resource at any depth MUST NOT examine or return any calendar object resources from within any 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) 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.

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 an implicit scheduling operation: Servers MUST verify that the currently authenticated user has the CALDAV:schedule-deliver privilege or a suitable sub-privilege on the scheduling Outbox collection of the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated. Servers MUST verify that the principal associated with the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated contains a CALDAV:schedule-outbox-URL property value. Servers MUST only deliver scheduling messages to recipients when the principal associated with the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated has the CALDAV:schedule privilege or a suitable sub-privilege on the scheduling Inbox collections for recipient. To prevent impersonation of calendar users, the server MUST verify that the "ORGANIZER" property in an organizer scheduling object resource matches one of the calendar user addresses of the DAV:owner of the calendar collection in which the resource is stored. To prevent spoofing of an existing scheduling object resource, servers MUST verify that the "UID" iCalendar property value in a new scheduling object resource does not match that of an existing scheduling object resource with a different "ORGANIZER" property value. When handling a POST request on a scheduling Outbox collection: Servers MUST verify that the currently authenticated user has the CALDAV:schedule-deliver 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 those recipients to whom a scheduling message is being delivered.

This specification registers one new header for use with HTTP as per .

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

This specification registers two new iCalendar property parameters as defined in XXX.

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

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

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 in the scheduling message and the scheduling "METHOD" in use.

The following tables specify which scheduling privileges grant the right to a calendar user to submit a scheduling message to another calendar user, either as the result of an explicit scheduling request or an automatic scheduling transaction. The appropriate behavior depends on the calendar component type in the scheduling message and the scheduling "METHOD" in use.

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