Network Working Group C. Daboo
Internet-Draft Apple
Intended status: Standards Track B. Desruisseaux
Expires: May 21, 2008 Oracle
L. Dusseault
CommerceNet
November 18, 2007
CalDAV Scheduling Extensions to WebDAV
draft-desruisseaux-caldav-sched-04
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Daboo, et al. Expires May 21, 2008 [Page 1]
Internet-Draft CalDAV Schedule November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Required Scheduling features . . . . . . . . . . . . . . . . . 5
3. CalDAV Scheduling Support Discovery . . . . . . . . . . . . . 6
3.1. Example: Using OPTIONS for the Discovery of Support
for CalDAV . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Scheduling Collections . . . . . . . . . . . . . . . . . . 8
4.2. Scheduling Transactions . . . . . . . . . . . . . . . . . 9
5. New Resource Types and Properties . . . . . . . . . . . . . . 10
5.1. Scheduling Outbox Collection . . . . . . . . . . . . . . . 10
5.2. Scheduling Inbox Collection . . . . . . . . . . . . . . . 11
5.3. Scheduling Inbox Collection Properties . . . . . . . . . . 11
5.3.1. CALDAV:calendar-free-busy-set Property . . . . . . . . 12
5.3.2. Additional Precondition for PROPPATCH . . . . . . . . 12
5.4. Calendar Object Resource Properties . . . . . . . . . . . 13
5.4.1. CALDAV:originator Property . . . . . . . . . . . . . . 13
5.4.2. CALDAV:recipient Property . . . . . . . . . . . . . . 13
6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Originator request header . . . . . . . . . . . . . . 16
6.1.2. ORGANIZER Property . . . . . . . . . . . . . . . . . . 17
6.1.3. Recipient request header . . . . . . . . . . . . . . . 17
6.1.4. Response to a POST request . . . . . . . . . . . . . . 18
6.1.5. Status Codes for use with the POST method . . . . . . 18
6.1.6. Example - Simple meeting invitation . . . . . . . . . 20
6.1.7. Example - Free-Busy lookup . . . . . . . . . . . . . . 22
6.1.8. Example - Simple task assignment . . . . . . . . . . . 24
6.2. Retrieving incoming scheduling messages . . . . . . . . . 25
6.2.1. Example - Retrieve incoming scheduling message . . . . 25
6.3. Acting on incoming scheduling messages . . . . . . . . . . 26
7. Additional iCalendar Property Parameters . . . . . . . . . . . 27
7.1. Received Sequence . . . . . . . . . . . . . . . . . . . . 27
7.2. Received Date/Time Stamp . . . . . . . . . . . . . . . . . 28
8. HTTP Request Headers for CalDAV . . . . . . . . . . . . . . . 28
8.1. Originator Request Header . . . . . . . . . . . . . . . . 28
8.2. Recipient Request Header . . . . . . . . . . . . . . . . . 28
9. Scheduling Access Control . . . . . . . . . . . . . . . . . . 29
9.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 29
9.1.1. CALDAV:schedule-post Privilege . . . . . . . . . . . . 29
9.1.2. CALDAV:schedule-post-vevent Privilege . . . . . . . . 29
9.1.3. CALDAV:schedule-post-vtodo Privilege . . . . . . . . . 29
9.1.4. CALDAV:schedule-post-vjournal Privilege . . . . . . . 29
9.1.5. CALDAV:schedule-post-vfreebusy Privilege . . . . . . . 30
Daboo, et al. Expires May 21, 2008 [Page 2]
Internet-Draft CalDAV Schedule November 2007
9.1.6. CALDAV:schedule-deliver Privilege . . . . . . . . . . 30
9.1.7. CALDAV:schedule-deliver-vevent Privilege . . . . . . . 30
9.1.8. CALDAV:schedule-deliver-vtodo Privilege . . . . . . . 30
9.1.9. CALDAV:schedule-deliver-vjournal Privilege . . . . . . 31
9.1.10. CALDAV:schedule-deliver-vfreebusy Privilege . . . . . 31
9.1.11. CALDAV:schedule-respond Privilege . . . . . . . . . . 31
9.1.12. CALDAV:schedule-respond-vevent Privilege . . . . . . . 32
9.1.13. CALDAV:schedule-respond-vtodo Privilege . . . . . . . 32
9.1.14. CALDAV:schedule Privilege . . . . . . . . . . . . . . 32
9.1.15. Aggregation of Scheduling Privileges . . . . . . . . . 32
9.2. Additional Principal Properties . . . . . . . . . . . . . 33
9.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 33
9.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 34
9.2.3. CALDAV:calendar-user-address-set Property . . . . . . 34
9.2.4. Example: Searching for calendars belonging to a
user based on a calendar user address . . . . . . . . 35
9.2.5. Example: Finding the scheduling Inbox and Outbox
Collection belonging to the currently
authenticated user . . . . . . . . . . . . . . . . . . 36
10. Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. XML Element Definitions . . . . . . . . . . . . . . . . . . . 37
11.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 37
11.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 37
11.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 37
11.4. CALDAV:request-status XML Element . . . . . . . . . . . . 38
12. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12.1. Verifying scheduling requests . . . . . . . . . . . . . . 38
13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 39
13.1. Originator Header Registration . . . . . . . . . . . . . . 39
13.2. Recipient Header Registration . . . . . . . . . . . . . . 39
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. Normative References . . . . . . . . . . . . . . . . . . . 40
15.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 41
A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 41
A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 44
Appendix B. Example Scheduling Workflow . . . . . . . . . . . . . 45
B.1. Inviting Attendees to an Event . . . . . . . . . . . . . . 46
B.2. Receiving and Replying to an Event Invitation . . . . . . 46
B.3. Receiving a Reply to an Event Invitation . . . . . . . . . 46
B.4. Rescheduling an existing event . . . . . . . . . . . . . . 47
B.5. Receiving an Updated Event Invitation . . . . . . . . . . 47
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 48
C.1. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 48
C.2. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 49
C.3. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 49
C.4. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 49
Daboo, et al. Expires May 21, 2008 [Page 3]
Internet-Draft CalDAV Schedule November 2007
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",
Daboo, et al. Expires May 21, 2008 [Page 4]
Internet-Draft CalDAV Schedule November 2007
"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:
o MUST support iCalendar [RFC2445] as a media type for the calendar
object resource format;
o MUST support iTIP [RFC2446].
o MUST support WebDAV Class 1, 2, and 3 [RFC4918];
o MUST support WebDAV ACL [RFC3744] with the additional privileges
defined in Section 9.1 of this document;
o MUST support transport over TLS [RFC2246] as defined in [RFC2818]
(note that [RFC2246] has been obsoleted by [RFC4346]);
Daboo, et al. Expires May 21, 2008 [Page 5]
Internet-Draft CalDAV Schedule November 2007
o MUST support ETags [RFC2616];
o MUST support the CALDAV:schedule-inbox and CALDAV:schedule-outbox
collection resource types.
o MUST support the POST method with the Recipient and Originator
request headers targeted at a CALDAV:schedule-outbox collection
resource type.
A CalDAV scheduling server MAY also support the CalDAV calendar-
access feature [RFC4791], and that adds the following requirements:
MUST support the CALDAV:calendar-query and CALDAV:multiget REPORTs
on CALDAV:schedule-inbox and CALDAV:schedule-outbox collection
resource types.
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
Daboo, et al. Expires May 21, 2008 [Page 6]
Internet-Draft CalDAV Schedule November 2007
"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.
Daboo, et al. Expires May 21, 2008 [Page 7]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 8]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 9]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 10]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 11]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 12]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 13]
Internet-Draft CalDAV Schedule November 2007
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>
Daboo, et al. Expires May 21, 2008 [Page 14]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 15]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 16]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 17]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 18]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 19]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 20]
Internet-Draft CalDAV Schedule November 2007
>> 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.
Daboo, et al. Expires May 21, 2008 [Page 21]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 22]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 23]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 24]
Internet-Draft CalDAV Schedule November 2007
>> 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
Daboo, et al. Expires May 21, 2008 [Page 25]
Internet-Draft CalDAV Schedule November 2007
>> 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
Daboo, et al. Expires May 21, 2008 [Page 26]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 27]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 28]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 29]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 30]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 31]
Internet-Draft CalDAV Schedule November 2007
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:
Daboo, et al. Expires May 21, 2008 [Page 32]
Internet-Draft CalDAV Schedule November 2007
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)>
Daboo, et al. Expires May 21, 2008 [Page 33]
Internet-Draft CalDAV Schedule November 2007
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*)>
Daboo, et al. Expires May 21, 2008 [Page 34]
Internet-Draft CalDAV Schedule November 2007
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>
Daboo, et al. Expires May 21, 2008 [Page 35]
Internet-Draft CalDAV Schedule November 2007
>> 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.
Daboo, et al. Expires May 21, 2008 [Page 36]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 37]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 38]
Internet-Draft CalDAV Schedule November 2007
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
Daboo, et al. Expires May 21, 2008 [Page 39]
Internet-Draft CalDAV Schedule November 2007
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. and 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):
Daboo, et al. Expires May 21, 2008 [Page 40]
Internet-Draft CalDAV Schedule November 2007
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] Bray, T., Paoli, J., Sperberg-McQueen, C.,
Yergeau, F., and E. Maler, "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.
Daboo, et al. Expires May 21, 2008 [Page 41]
Internet-Draft CalDAV Schedule November 2007
+---------------------------------+
| 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 || | | * | | | * | * | |
+--------------------------------++---+---+---+---+---+---+---+-----+
Daboo, et al. Expires May 21, 2008 [Page 42]
Internet-Draft CalDAV Schedule November 2007
+-----------------------+
| 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 |
+--------------------------------++-------+-------+-------+
Daboo, et al. Expires May 21, 2008 [Page 43]
Internet-Draft CalDAV Schedule November 2007
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 || | | | | | | | |
+--------------------------------++---+---+---+---+---+---+---+-----+
Daboo, et al. Expires May 21, 2008 [Page 44]
Internet-Draft CalDAV Schedule November 2007
+-----------------------+
| 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.
Daboo, et al. Expires May 21, 2008 [Page 45]
Internet-Draft CalDAV Schedule November 2007
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,
Daboo, et al. Expires May 21, 2008 [Page 46]
Internet-Draft CalDAV Schedule November 2007
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.
Daboo, et al. Expires May 21, 2008 [Page 47]
Internet-Draft CalDAV Schedule November 2007
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
a. Updated to rfc3986 reference.
b. Added Appendix with example workflow.
c. Change calendar-home-URL to calendar-home-set.
d. Updated to RFC 4791 reference.
e. Updated to RFC 4918 reference.
f. Changed title.
g. Added text to explain that VTODO and VJOURNAL are also valid
scheduling components in CalDAV.
h. Changed order of Inbox and Outbox definition in section 5.
i. Added CALDAV:valid-free-busy-set pre-condition.
j. Re-worked descriptions of originator, recipient request headers
to distinguish between iTIP outgoing and incoming modes.
k. Removed 502 status code description for POST.
l. Modified 507 status code description for POST to apply to Outbox
storage only.
m. Added example of task assignment.
n. Use application/xml instead of text/xml.
o. Inbox and Outbox cannot be contained within a calendar
collection.
Daboo, et al. Expires May 21, 2008 [Page 48]
Internet-Draft CalDAV Schedule November 2007
p. Added an appendix summarizing scheduling privileges.
q. Added registration for the new HTTP headers.
r. Redefined the set of scheduling privileges.
s. Minor terminology/formatting tweaks.
C.2. Changes in -03
a. Added free-busy example.
b. Better abstract.
c. Requiring DAV level 2 for locking of Inbox.
d. Do not require servers to actually save Outbox requests.
e. Removed CALDAV:schedule-state Property. Clients now must remove
inbox items after processing them, using locking etc to prevent
race conditions.
f. Switched back to 2518 reference from 2518bis.
g. Updated to more recent XML reference.
h. Revised required features section to better match caldav-access.
C.3. Changes in -02
a. Split schedule privilege into three sub-privileges.
b. Made support for caldav-access optional.
c. Changed SCHEDULE method to POST.
C.4. Changes in -01
a. Updated to latest references including 2518bis.
b. Added principal property CALDAV:calendar-user-address-set.
c. Major changes to schedule method, including addition of
preconditions.
d. New principal properties added.
Daboo, et al. Expires May 21, 2008 [Page 49]
Internet-Draft CalDAV Schedule November 2007
e. Text related to alternative ways of doing scheduling (some
speculative) removed.
f. Added Security Considerations text.
g. 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/
Daboo, et al. Expires May 21, 2008 [Page 50]
Internet-Draft CalDAV Schedule November 2007
Full Copyright Statement
Copyright (C) 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Daboo, et al. Expires May 21, 2008 [Page 51]
