Network Working GroupC. Daboo
Internet-DraftApple
Intended status: Standards TrackB. Desruisseaux
Expires: May 21, 2008Oracle
L. Dusseault
CommerceNet
November 18, 2007

CalDAV Scheduling Extensions to WebDAV

Status of This Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 21, 2008.

Abstract

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.


1. Introduction

This document specifies a set of headers, properties and privileges that define the CalDAV [RFC4791] scheduling extensions to the WebDAV [RFC4918] protocol. This document also provides the transport specific information necessary to convey iCalendar [RFC2445] Transport-independent Interoperability Protocol iTIP [RFC2446] 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>.

1.1. XML Namespaces

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 [W3C.REC-xml-20060816].

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 [RFC4791].

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.

1.2. Notational Conventions

The augmented BNF used by this document to describe protocol elements is described in Section 2.1 of [RFC2616]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], 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 [RFC2119].

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.

1.3. Terminology

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

2. Required Scheduling features

This section lists what functionality is required of a CalDAV scheduling server. To advertise support for this specification a server:

A CalDAV scheduling server MAY also support the CalDAV calendar-access feature [RFC4791], and that adds the following requirements:

3. CalDAV Scheduling Support Discovery

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.

3.1. Example: Using OPTIONS for the Discovery of Support for CalDAV

>> Request <<

OPTIONS /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
        

>> Response <<

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule
Content-Length: 0
        

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.

4. Scheduling Process

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 [RFC2445] also allows for sending VTODO and VJOURNAL components as described in iTIP [RFC2446]. 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.

4.1. Scheduling Collections

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 [RFC3744] 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) [RFC2446] 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.

4.2. Scheduling Transactions

The iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC2446] 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 [RFC2447], 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.

5. New Resource Types and Properties

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

5.1. Scheduling Outbox Collection

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:

   <!ELEMENT schedule-outbox EMPTY>
          

Example:

   <resourcetype xmlns="DAV:">
     <collection/>
     <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
   </resourcetype>
          

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

5.2. Scheduling Inbox Collection

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:

   <!ELEMENT schedule-inbox EMPTY>
          

Example:

   <resourcetype xmlns="DAV:">
     <collection/>
     <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
   </resourcetype>
          

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

5.3. Scheduling Inbox Collection Properties

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

5.3.1. CALDAV:calendar-free-busy-set Property

Name:
calendar-free-busy-set
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the calendars that contribute to the free-busy information for the calendar user associated with the scheduling Inbox collection.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]). Support for this property is REQUIRED.
Description:
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.
Definition:
   <!ELEMENT calendar-free-busy-set (DAV:href*) >
                
Example:
   <C:calendar-free-busy-set xmlns:D="DAV:"
                         xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:href>/calendars/bernard/work/</D:href>
     <D:href>/calendars/bernard/home/</D:href>
     <D:href>/public/holidays/CA/</D:href>
   </C:calendar-free-busy-set>
                

5.3.2. Additional Precondition for PROPPATCH

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.

5.4. Calendar Object Resource Properties

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

5.4.1. CALDAV:originator Property

Name:
originator
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Indicates the Originator of the scheduling message contained in a scheduling Inbox or Outbox collection.
Conformance:
This property MUST be protected and SHOULD NOT be returned by [RFC4918]).
Description:
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.
Definition:
   <!ELEMENT originator (DAV:href)>
   DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])
                
Example:
   <C:originator xmlns:D="DAV:"
                 xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:href>mailto:bernard@example.com</D:href>
   </C:originator>
                

5.4.2. CALDAV:recipient Property

Name:
recipient
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
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.
Conformance:
This property MUST be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]).
Description:
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 Section 9.2.3) 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.
Definition:
   <!ELEMENT recipient (DAV:href+)>
   DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])
Example:
   <C:recipient xmlns:D="DAV:"
                xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:href>mailto:cyrus@example.com</D:href>
     <D:href>mailto:lisa@example.com</D:href>
   </C:recipient>
                

6. Scheduling

6.1. POST Method

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 (Section 5.1).

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 [RFC4791] 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

6.1.1. Originator request header

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.

6.1.2. ORGANIZER Property

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.

6.1.3. Recipient request header

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.

6.1.4. Response to a POST request

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

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.

6.1.5. Status Codes for use with the POST method

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.

6.1.6. Example - Simple meeting invitation

>> Request <<

POST /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
Originator: mailto:lisa@example.com
Recipient: mailto:bernard@example.com
Recipient: mailto:cyrus@example.com
Content-Type: text/calendar
Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REQUEST
BEGIN:VEVENT
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
DTSTART:20040902T130000Z
DTEND:20040902T140000Z
SUMMARY:Design meeting
UID:34222-232@example.com
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
 IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.c
 om
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
 uisseaux:mailto:bernard@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
 mailto:cyrus@example.com
END:VEVENT
END:VCALENDAR

          

>> Response <<

HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:schedule-response xmlns:D="DAV:"
             xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:response>
  <C:recipient>mailto:bernard@example.com</C:recipient>
  <C:request-status>2.0;Success</C:request-status>
  <D:responsedescription>Delivered to recipient
  scheduling inbox</D:responsedescription>
</C:response>
<C:response>
  <C:recipient>mailto:cyrus@example.com</C:recipient>
  <C:request-status>2.0;Success</C:request-status>
  <D:responsedescription>Delivered to recipient
  scheduling inbox</D:responsedescription>
</C:response>
</C:schedule-response>

          

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.

6.1.7. Example - Free-Busy lookup

>> Request <<

POST /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
Originator: mailto:lisa@example.com
Recipient: mailto:bernard@example.com
Recipient: mailto:cyrus@example.com
Content-Type: text/calendar
Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REQUEST
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
ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com
END:VFREEBUSY
END:VCALENDAR

          

>> Response <<

HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:schedule-response xmlns:D="DAV:"
             xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:response>
  <C:recipient>mailto:bernard@example.com</C:recipient>
  <C:request-status>2.0;Success</C:request-status>
  <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REPLY
BEGIN:VFREEBUSY
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
</C:calendar-data>
</C:response>
<C:response>
  <C:recipient>mailto:cyrus@example.com</C:recipient>
  <C:request-status>2.0;Success</C:request-status>
  <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REPLY
BEGIN:VFREEBUSY
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
</C:calendar-data>
</C:response>
</C:schedule-response>

          

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.

6.1.8. Example - Simple task assignment

>> Request <<

POST /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
Originator: mailto:lisa@example.com
Recipient: mailto:bernard@example.com
Recipient: mailto:cyrus@example.com
Content-Type: text/calendar
Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REQUEST
BEGIN:VTODO
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
DUE:20070505
SUMMARY:Finish CalDAV schedule spec
UID:34222-456@example.com
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
 IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.c
 om
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
 uisseaux:mailto:bernard@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
 Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
 mailto:cyrus@example.com
END:VEVENT
END:VCALENDAR

          

>> Response <<

HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:schedule-response xmlns:D="DAV:"
             xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:response>
  <C:recipient>mailto:bernard@example.com</C:recipient>
  <C:request-status>2.0;Success</C:request-status>
  <D:responsedescription>Delivered to recipient
  scheduling inbox</D:responsedescription>
</C:response>
<C:response>
  <C:recipient>mailto:cyrus@example.com</C:recipient>
  <C:request-status>2.0;Success</C:request-status>
  <D:responsedescription>Delivered to recipient
  scheduling inbox</D:responsedescription>
</C:response>
</C:schedule-response>

          

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.

6.2. Retrieving incoming scheduling messages

Incoming scheduling messages will be stored in a scheduling Inbox collection. As per Section 10, 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.

6.2.1. Example - Retrieve incoming scheduling message

>> Request <<

GET /bernard/calendar/inbox/mtg456.ics HTTP/1.1
Host: cal.example.com

          

>> Response <<

HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 17:05:23 GMT
Content-Type: text/calendar
Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REQUEST
BEGIN:VEVENT
DTSTAMP:20040901T200200Z
CATEGORIES:APPOINTMENT
ORGANIZER:mailto:lisa@example.com
DTSTART:20040902T130000Z
DTEND:20040902T140000Z
SUMMARY:CalDAV draft review
UID:34222-232@example.com
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
 IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
 ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:
 mailto:bernard@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
 ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:mailto:cyr
 us@example.com
END:VEVENT
END:VCALENDAR

          

6.3. Acting on incoming scheduling messages

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.

Appendix B describes some sample workflows of scheduling message processing.

7. Additional iCalendar Property Parameters

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 [RFC2446].

7.1. Received Sequence

Parameter Name:
RECEIVED-SEQUENCE
Purpose:
To specify the value of the SEQUENCE iCalendar property that was specified in the most recent scheduling message received by the Organizer.
Format Definition:
This iCalendar property parameter is defined by the following notation:
     received-sequenceparam = "RECEIVED-SEQUENCE" "=" integer
Description:
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.
Example:
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

7.2. Received Date/Time Stamp

Parameter Name:
RECEIVED-DTSTAMP
Purpose:
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.
Format Definition:
This iCalendar property parameter is defined by the following notation:
     received-dtstampparam = "RECEIVED-DTSTAMP" "=" date-time
Description:
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.
Example:
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

8. HTTP Request Headers for CalDAV

8.1. Originator Request Header

   Originator = "Originator" ":" absoluteURI
  
        

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 [RFC3986].

8.2. Recipient Request Header

   Recipient = "Recipient" ":" 1#absoluteURI
        

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 [RFC3986]

9. Scheduling Access Control

9.1. Scheduling Privileges

Server implementations that advertise support for the "calendar-schedule" feature of CalDAV MUST support WebDAV ACL [RFC3744] as well as the scheduling privileges defined in this section.

The tables specified in Appendix A clarifies which scheduling methods (e.g., REQUEST, REPLY, etc.) are controlled by each scheduling privilege defined in this section.

9.1.1. CALDAV:schedule-post Privilege

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.

<!ELEMENT schedule-post EMPTY >

9.1.2. CALDAV:schedule-post-vevent Privilege

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.

<!ELEMENT schedule-post-vevent EMPTY >

9.1.3. CALDAV:schedule-post-vtodo Privilege

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.

<!ELEMENT schedule-post-vtodo EMPTY >

9.1.4. CALDAV:schedule-post-vjournal Privilege

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.

<!ELEMENT schedule-post-vjournal EMPTY >

9.1.5. CALDAV:schedule-post-vfreebusy Privilege

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.

<!ELEMENT schedule-post-vfreebusy EMPTY >

9.1.6. CALDAV:schedule-deliver Privilege

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.

<!ELEMENT schedule-deliver EMPTY >

9.1.7. CALDAV:schedule-deliver-vevent Privilege

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.

<!ELEMENT schedule-deliver-vevent EMPTY >

9.1.8. CALDAV:schedule-deliver-vtodo Privilege

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.

<!ELEMENT schedule-deliver-vtodo EMPTY >

9.1.9. CALDAV:schedule-deliver-vjournal Privilege

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.

<!ELEMENT schedule-deliver-vjournal EMPTY >

9.1.10. CALDAV:schedule-deliver-vfreebusy Privilege

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.

<!ELEMENT schedule-deliver-vfreebusy EMPTY >

9.1.11. CALDAV:schedule-respond Privilege

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.

<!ELEMENT schedule-respond EMPTY >

9.1.12. CALDAV:schedule-respond-vevent Privilege

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.

<!ELEMENT schedule-deliver-vevent EMPTY >

9.1.13. CALDAV:schedule-respond-vtodo Privilege

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.

<!ELEMENT schedule-deliver-vtodo EMPTY >

9.1.14. CALDAV:schedule Privilege

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.

<!ELEMENT schedule EMPTY >

9.1.15. Aggregation of Scheduling Privileges

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.

9.2. Additional Principal Properties

This section defines new properties for WebDAV principal resources as defined in RFC3744 [RFC3744]. These properties are likely to be protected but the server MAY allow them to be written by appropriate users.

9.2.1. CALDAV:schedule-inbox-URL Property

Name:
schedule-inbox-URL
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the URL of the scheduling Inbox collection owned by the associated principal resource.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]).
Description:
This property is needed for a client to determine where the scheduling Inbox collection of the current user is located so that processing of scheduling messages can occur.
Definition:
   <!ELEMENT schedule-inbox-URL (DAV:href)>
                

9.2.2. CALDAV:schedule-outbox-URL Property

Name:
schedule-outbox-URL
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the URL of the scheduling Outbox collection owned by the associated principal resource.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]).
Description:
This property is needed for a client to determine where the scheduling Outbox collection of the current user is located so that sending of scheduling messages can occur.
Definition:
   <!ELEMENT schedule-outbox-URL DAV:href>
                

9.2.3. CALDAV:calendar-user-address-set Property

Name:
calendar-user-address-set
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the calendar addresses of the associated principal resource.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]). 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.
Description:
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.
Definition:
   <!ELEMENT calendar-user-address-set (DAV:href*)>
Example:
   <C:calendar-user-address-set xmlns:D="DAV:"
                         xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:href>mailto:bernard@example.com</D:href>
     <D:href>mailto:bernard.desruisseaux@example.com</D:href>
   </C:calendar-user-address-set>

9.2.4. Example: Searching for calendars belonging to a user based on a calendar user address

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

REPORT /users/ HTTP/1.1
Host: cal.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
Depth: 0

<?xml version="1.0" encoding="utf-8" ?>
<D:principal-property-search xmlns:D="DAV:"
            xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:property-search>
    <D:prop>
      <C:calendar-user-address-set/>
    </D:prop>
    <D:match>mailto:bernard@example.com</D:match>
  </D:property-search>
  <D:prop>
    <C:calendar-home-set/>
    <D:displayname/>
  </D:prop>
</D:principal-property-search>

>> Response <<

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
         xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>/users/bernard</D:href>
    <D:propstat>
      <D:prop>
        <C:calendar-home-set>
          <D:href>/home/bernard/</D:href>
        </C:calendar-home-set>
        <D:displayname>Bernard Desruisseaux</D:displayname>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>
            

9.2.5. Example: Finding the scheduling Inbox and Outbox Collection belonging to the currently authenticated user

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

10. Reports

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.

11. XML Element Definitions

11.1. CALDAV:schedule-response XML Element

Name:
schedule-response
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Contains the set of responses for a POST method request.
Description:
See Section 6.1.4.
Definition:
    <!ELEMENT schedule-response (response*)>

11.2. CALDAV:response XML Element

Name:
response
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Contains a single response for a POST method request.
Description:
See Section 6.1.4.
Definition:
<!ELEMENT response (recipient,
                    request-status,
                    calendar-data?,
                    DAV:error?,
                    DAV:responsedescription?)>

11.3. CALDAV:recipient XML Element

Name:
recipient
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
The calendar user address (recipient header value) that the enclosing response for a POST method request is for.
Description:
See Section 6.1.4.
Definition:
                
    <!ELEMENT recipient (DAV:href)>
            
              

11.4. CALDAV:request-status XML Element

Name:
request-status
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
The iTIP REQUEST-STATUS property value for this response.
Description:
See Section 6.1.4.
Definition:
                
    <!ELEMENT request-status (#PCDATA)>
            
              

12. Security Considerations

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

12.1. Verifying scheduling requests

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

13. IANA Consideration

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

13.1. Originator Header Registration

Header field name: Originator

Applicable protocol: http

Status: standard

Author/Change controller: IETF

Specification document(s): this specification

Related information: none

13.2. Recipient Header Registration

Header field name: Recipient

Applicable protocol: http

Status: standard

Author/Change controller: IETF

Specification document(s): this specification

Related information: none

14. Acknowledgements

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.

15. References

15.1. Normative References

[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2246]
Dierks, T. and C. Allen, “The TLS Protocol Version 1.0”, RFC 2246, January 1999.
[RFC2445]
Dawson, F., Stenerson, D., “Internet Calendaring and Scheduling Core Object Specification (iCalendar)”, RFC 2445, November 1998.
[RFC2446]
Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, “iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries”, RFC 2446, November 1998.
[RFC2616]
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.
[RFC2818]
Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.
[RFC3744]
Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, “Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol”, RFC 3744, May 2004.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.
[RFC4346]
Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC 4346, April 2006.
[RFC4791]
Daboo, C., Desruisseaux, B., and L. Dusseault, “Calendaring Extensions to WebDAV (CalDAV)”, RFC 4791, March 2007.
[RFC4918]
Dusseault, L., “HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)”, RFC 4918, June 2007.
[W3C.REC-xml-20060816]
Maler, E., Paoli, J., Yergeau, F., Sperberg-McQueen, C., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition)”, World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.

15.2. Informative References

[RFC2447]
Dawson, F., Mansour, S., and S. Silverberg, “iCalendar Message-Based Interoperability Protocol (iMIP)”, RFC 2447, November 1998.
[RFC3864]
Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.

Appendix A. Scheduling Privileges Summary

A.1. Scheduling Inbox Privileges

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.

                                  +---------------------------------+
                                  |   Scheduling METHOD for VEVENT  |
                                  +---+---+---+---+---+---+---+-----+
                                  | P | R | R | A | C | R | C | D C |
                                  | U | E | E | D | A | E | O | E O |
                                  | B | Q | P | D | N | F | U | C U |
                                  | L | U | L |   | C | R | N | L N |
                                  | I | E | Y |   | E | E | T | I T |
+--------------------------------+| S | S |   |   | L | S | E | N E |
| Scheduling Inbox Privilege     || H | T |   |   |   | H | R | E R |
+================================++===+===+===+===+===+===+===+=====+
| schedule                       || * | * | * | * | * | * | * |  *  |
|   schedule-deliver             || * | * |   | * | * |   |   |  *  |
|     schedule-deliver-vevent    || * | * |   | * | * |   |   |  *  |
|     schedule-deliver-vtodo     ||   |   |   |   |   |   |   |     |
|     schedule-deliver-vjournal  ||   |   |   |   |   |   |   |     |
|     schedule-deliver-vfreebusy ||   |   |   |   |   |   |   |     |
|   schedule-respond             ||   |   | * |   |   | * | * |     |
|     schedule-respond-vevent    ||   |   | * |   |   | * | * |     |
|     schedule-respond-vtodo     ||   |   |   |   |   |   |   |     |
+--------------------------------++---+---+---+---+---+---+---+-----+
                                  +---------------------------------+
                                  |   Scheduling METHOD for VTODO   |
                                  +---+---+---+---+---+---+---+-----+
                                  | P | R | R | A | C | R | C | D C |
                                  | U | E | E | D | A | E | O | E O |
                                  | B | Q | P | D | N | F | U | C U |
                                  | L | U | L |   | C | R | N | L N |
                                  | I | E | Y |   | E | E | T | I T |
+--------------------------------+| S | S |   |   | L | S | E | N E |
| Scheduling Inbox Privilege     || H | T |   |   |   | H | R | E R |
+================================++===+===+===+===+===+===+===+=====+
| schedule                       || * | * | * | * | * | * | * |  *  |
|   schedule-deliver             || * | * |   | * | * |   |   |  *  |
|     schedule-deliver-vevent    ||   |   |   |   |   |   |   |     |
|     schedule-deliver-vtodo     || * | * |   | * | * |   |   |  *  |
|     schedule-deliver-vjournal  ||   |   |   |   |   |   |   |     |
|     schedule-deliver-vfreebusy ||   |   |   |   |   |   |   |     |
|   schedule-respond             ||   |   | * |   |   | * | * |     |
|     schedule-respond-vevent    ||   |   |   |   |   |   |   |     |
|     schedule-respond-vtodo     ||   |   | * |   |   | * | * |     |
+--------------------------------++---+---+---+---+---+---+---+-----+
                                  +-----------------------+
                                  | Scheduling METHOD for |
                                  |        VJOURNAL       |
                                  +-------+-------+-------+
                                  |   P   |   A   |   C   | 
                                  |   U   |   D   |   A   | 
                                  |   B   |   D   |   N   | 
                                  |   L   |       |   C   | 
                                  |   I   |       |   E   | 
+--------------------------------+|   S   |       |   L   | 
| Scheduling Inbox Privilege     ||   H   |       |       | 
+================================++=======+=======+=======+
| schedule                       ||   *   |   *   |   *   | 
|  schedule-deliver              ||   *   |   *   |   *   | 
|    schedule-deliver-vevent     ||       |       |       | 
|    schedule-deliver-vtodo      ||       |       |       | 
|    schedule-deliver-vjournal   ||   *   |   *   |   *   | 
|    schedule-deliver-vfreebusy  ||       |       |       | 
|  schedule-respond              ||       |       |       | 
|    schedule-respond-vevent     ||       |       |       | 
|    schedule-respond-vtodo      ||       |       |       | 
+--------------------------------++-------+-------+-------+
                                  +-----------------------+
                                  | Scheduling METHOD for |
                                  |       VFREEBUSY       |
                                  +-------+-------+-------+
                                  |   P   |   R   |   R   | 
                                  |   U   |   E   |   E   | 
                                  |   B   |   Q   |   P   | 
                                  |   L   |   U   |   L   | 
                                  |   I   |   E   |   Y   | 
+--------------------------------+|   S   |   S   |       | 
| Scheduling Inbox Privilege     ||   H   |   T   |       | 
+================================++=======+=======+=======+
| schedule                       ||   *   |   *   | xxxxx |
|  schedule-deliver              ||   *   |       | xxxxx |
|    schedule-deliver-vevent     ||       |       | xxxxx |
|    schedule-deliver-vtodo      ||       |       | xxxxx |
|    schedule-deliver-vjournal   ||       |       | xxxxx |
|    schedule-deliver-vfreebusy  ||   *   |       | xxxxx |
|  schedule-respond              ||       |       | xxxxx |
|    schedule-respond-vevent     ||       |       | xxxxx |
|    schedule-respond-vtodo      ||       |       | xxxxx |
+--------------------------------++-------+-------+-------+

A.2. Scheduling Outbox Privileges

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.

                                  +---------------------------------+
                                  |   Scheduling METHOD for VEVENT  |
                                  +---+---+---+---+---+---+---+-----+
                                  | P | R | R | A | C | R | C | D C |
                                  | U | E | E | D | A | E | O | E O |
                                  | B | Q | P | D | N | F | U | C U |
                                  | L | U | L |   | C | R | N | L N |
                                  | I | E | Y |   | E | E | T | I T |
+--------------------------------+| S | S |   |   | L | S | E | N E |
| Scheduling Outbox Privilege    || H | T |   |   |   | H | R | E R |
+================================++===+===+===+===+===+===+===+=====+
| schedule                       || * | * | * | * | * | * | * |  *  |
|   schedule-post                || * | * | * | * | * | * | * |  *  |
|     schedule-post-vevent       || * | * | * | * | * | * | * |  *  |
|     schedule-post-vtodo        ||   |   |   |   |   |   |   |     |
|     schedule-post-vjournal     ||   |   |   |   |   |   |   |     |
|     schedule-post-vfreebusy    ||   |   |   |   |   |   |   |     |
+--------------------------------++---+---+---+---+---+---+---+-----+
                                  +---------------------------------+
                                  |   Scheduling METHOD for VTODO   |
                                  +---+---+---+---+---+---+---+-----+
                                  | P | R | R | A | C | R | C | D C |
                                  | U | E | E | D | A | E | O | E O |
                                  | B | Q | P | D | N | F | U | C U |
                                  | L | U | L |   | C | R | N | L N |
                                  | I | E | Y |   | E | E | T | I T |
+--------------------------------+| S | S |   |   | L | S | E | N E |
| Scheduling Outbox Privilege    || H | T |   |   |   | H | R | E R |
+================================++===+===+===+===+===+===+===+=====+
| schedule                       || * | * | * | * | * | * | * |  *  |
|   schedule-post                || * | * | * | * | * | * | * |  *  |
|     schedule-post-vevent       ||   |   |   |   |   |   |   |     |
|     schedule-post-vtodo        || * | * | * | * | * | * | * |  *  |
|     schedule-post-vjournal     ||   |   |   |   |   |   |   |     |
|     schedule-post-vfreebusy    ||   |   |   |   |   |   |   |     |
+--------------------------------++---+---+---+---+---+---+---+-----+

                                  +-----------------------+
                                  | Scheduling METHOD for |
                                  |        VJOURNAL       |
                                  +-------+-------+-------+
                                  |   P   |   A   |   C   | 
                                  |   U   |   D   |   A   | 
                                  |   B   |   D   |   N   | 
                                  |   L   |       |   C   | 
                                  |   I   |       |   E   | 
+--------------------------------+|   S   |       |   L   | 
| Scheduling Outbox Privilege    ||   H   |       |       | 
+================================++=======+=======+=======+
| schedule                       ||   *   |   *   |   *   | 
|  schedule-post                 ||   *   |   *   |   *   | 
|    schedule-post-vevent        ||       |       |       | 
|    schedule-post-vtodo         ||       |       |       | 
|    schedule-post-vjournal      ||   *   |   *   |   *   | 
|    schedule-post-vfreebusy     ||       |       |       | 
+--------------------------------++-------+-------+-------+
                                  +-----------------------+
                                  | Scheduling METHOD for |
                                  |       VFREEBUSY       |
                                  +-------+-------+-------+
                                  |   P   |   R   |   R   | 
                                  |   U   |   E   |   E   | 
                                  |   B   |   Q   |   P   | 
                                  |   L   |   U   |   L   | 
                                  |   I   |   E   |   Y   | 
+--------------------------------+|   S   |   S   |       | 
| Scheduling Outbox Privilege    ||   H   |   T   |       | 
+================================++=======+=======+=======+
| schedule                       ||   *   |   *   | xxxxx |
|  schedule-post                 ||   *   |   *   | xxxxx |
|    schedule-post-vevent        ||       |       | xxxxx |
|    schedule-post-vtodo         ||       |       | xxxxx |
|    schedule-post-vjournal      ||       |       | xxxxx |
|    schedule-post-vfreebusy     ||   *   |   *   | xxxxx |
+--------------------------------++-------+-------+-------+

Appendix B. Example Scheduling Workflow

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.

B.1. Inviting Attendees to an Event

  1. Bernard creates a new event with Lisa, Cyrus and himself as attendees and decides to send Lisa and Cyrus an invitation to this event.
  2. 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.
  3. Lisa and Cyrus will receive the scheduling request message in their scheduling Inbox collection.

B.2. Receiving and Replying to an Event Invitation

  1. 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.
  2. 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.
  3. Cyrus is presented with the new scheduling request message and decides to accept the event invitation and to reply to Bernard.
  4. 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.
  5. Cyrus' CUA submits a scheduling reply message through Cyrus' scheduling Outbox collection to cause the server to deliver the reply to Bernard.
  6. Cyrus' CUA deletes the scheduling request message contained in Cyrus' scheduling Inbox collection and unlocks the collection.

B.3. Receiving a Reply to an Event Invitation

  1. 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.
  2. Bernard's CUA updates the PARTSTAT, RECEIVED-DTSTAMP, and RECEIVED-SEQUENCE parameters of Cyrus' ATTENDEE property in the original event that was found.
  3. Bernard's CUA deletes the scheduling reply message contained in the Bernard's scheduling Inbox collection and unlocks the collection.

B.4. Rescheduling an existing event

  1. Bernard reschedules the event with Lisa and Cyrus and decides to send an updated event invitation to Lisa and Cyrus.
  2. 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.
  3. Lisa and Cyrus will receive the scheduling request message in their scheduling Inbox collection.

B.5. Receiving an Updated Event Invitation

  1. Lisa's CUA polls her scheduling Inbox collection for new scheduling messages.
  2. 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.
  3. 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.
  4. Lisa's CUA deletes the scheduling request messages contained in Lisa's scheduling Inbox collection and unlocks the collection.
  5. 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.
  6. Lisa's CUA submits a scheduling reply message through Lisa's scheduling Outbox collection to cause the server to deliver the reply to Bernard.

Appendix C. Changes

C.1. Changes in -04

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

C.2. Changes in -03

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

C.3. Changes in -02

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

C.4. Changes in -01

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

Authors' Addresses

Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: cyrus@daboo.name
URI: http://www.apple.com/
Bernard Desruisseaux
Oracle Corporation
600 Blvd. de Maisonneuve West
Suite 1900
Montreal, QC H3A 3J2
CANADA
Email: bernard.desruisseaux@oracle.com
URI: http://www.oracle.com/
Lisa Dusseault
CommerceNet
169 University Ave.
Palo Alto, CA 94301
USA
Email: ldusseault@commerce.net
URI: http://commerce.net/

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.