Network Working Group C. Daboo
Internet-Draft
Expires: December 27, 2006 B. Desruisseaux
Oracle
L. Dusseault
OSAF
June 25, 2006
Scheduling Extensions to CalDAV
draft-desruisseaux-caldav-sched-02
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 December 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a set of methods, headers and resource types
that define the scheduling extension to the CalDAV protocol. CalDAV
itself extends WebDAV, which extends HTTP. The new protocol elements
defined here allow interoperable scheduling operations on a CalDAV
repository.
Daboo, et al. Expires December 27, 2006 [Page 1]
Internet-Draft CalDAV June 2006
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 . . . . . . . . . . . . . 5
3.1. Example: Using OPTIONS for the Discovery of Support
for CalDAV . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Scheduling Collections . . . . . . . . . . . . . . . . . . 7
4.2. Scheduling Transactions . . . . . . . . . . . . . . . . . 8
5. New Resource Types and Properties . . . . . . . . . . . . . . 9
5.1. Scheduling Inbox Collection . . . . . . . . . . . . . . . 9
5.2. Scheduling Outbox Collection . . . . . . . . . . . . . . . 10
5.3. Scheduling Inbox Properties . . . . . . . . . . . . . . . 11
5.3.1. CALDAV:calendar-free-busy-set Property . . . . . . . . 11
5.4. Calendar Object Resource Properties . . . . . . . . . . . 12
5.4.1. CALDAV:originator Property . . . . . . . . . . . . . . 12
5.4.2. CALDAV:recipient Property . . . . . . . . . . . . . . 12
5.4.3. CALDAV:schedule-state Property . . . . . . . . . . . . 13
6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. Originator request header . . . . . . . . . . . . . . 15
6.1.2. ORGANIZER Property . . . . . . . . . . . . . . . . . . 16
6.1.3. Recipient request header . . . . . . . . . . . . . . . 16
6.1.4. Response to a POST request . . . . . . . . . . . . . . 17
6.1.5. Status Codes for use with the POST method . . . . . . 17
6.1.6. Example - Simple meeting invitation . . . . . . . . . 19
6.1.7. Example - Free-Busy lookup . . . . . . . . . . . . . . 20
6.2. Retrieving incoming scheduling messages . . . . . . . . . 21
6.2.1. Example - Retrieve incoming scheduling message . . . . 21
6.3. Acting on incoming scheduling messages . . . . . . . . . . 22
7. HTTP Request Headers for CalDAV . . . . . . . . . . . . . . . 22
7.1. Originator Request Header . . . . . . . . . . . . . . . . 22
7.2. Recipient Request Header . . . . . . . . . . . . . . . . . 23
8. Scheduling Access Control . . . . . . . . . . . . . . . . . . 23
8.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 23
8.1.1. CALDAV:schedule-request Privilege . . . . . . . . . . 23
8.1.2. CALDAV:schedule-reply Privilege . . . . . . . . . . . 25
8.1.3. CALDAV:schedule-free-busy Privilege . . . . . . . . . 27
8.1.4. CALDAV:schedule Privilege . . . . . . . . . . . . . . 29
8.1.5. Privilege aggregation and the
DAV:supported-privilege-set property . . . . . . . . . 31
8.2. Additional Principal Properties . . . . . . . . . . . . . 31
8.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 31
8.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 32
Daboo, et al. Expires December 27, 2006 [Page 2]
Internet-Draft CalDAV June 2006
8.2.3. CALDAV:calendar-user-address-set Property . . . . . . 32
8.2.4. Example: Searching for calendars belonging to a
user based on a calendar user address . . . . . . . . 33
8.2.5. Example: Finding the scheduling Inbox and Outbox
belonging to the currently authenticated user . . . . 35
9. Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 35
10.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 35
10.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 36
10.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 36
10.4. CALDAV:request-status XML Element . . . . . . . . . . . . 36
11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11.1. Verifying scheduling requests . . . . . . . . . . . . . . 37
12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 38
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
14. Normative References . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 39
A.1. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 39
A.2. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . . . 41
Daboo, et al. Expires December 27, 2006 [Page 3]
Internet-Draft CalDAV June 2006
1. Introduction
This document specifies a set of methods, headers, properties and
privileges that define the CalDAV [I-D.dusseault-caldav] scheduling
extensions to the WebDAV [I-D.ietf-webdav-rfc2518bis] protocol. This
document also provides the transport specific information necessary
to convey iCalendar [RFC2445] Transport-independent Interoperability
Protocol iTIP [RFC2446] 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 available 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-20040204].
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
[I-D.dusseault-caldav].
Also note that some CalDAV XML element names are identical to WebDAV
XML element names, though their namespace differs. Care MUST be
taken not to confuse the two sets of names.
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 December 27, 2006 [Page 4]
Internet-Draft CalDAV June 2006
"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.
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 the CALDAV:schedule privilege and its sub-privileges.
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 types.
o MUST support iTIP [RFC2446].
A CalDAV scheduling server MAY also support the CalDAV calendar-
access feature [I-D.dusseault-caldav], 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
Daboo, et al. Expires December 27, 2006 [Page 5]
Internet-Draft CalDAV June 2006
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, REPORT, ACL
DAV: 1, 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, 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
Daboo, et al. Expires December 27, 2006 [Page 6]
Internet-Draft CalDAV June 2006
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 his or her 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.
4.1. Scheduling Collections
It is useful for each participant in a scheduling transaction to
maintain their own "history" of invitations sent and received during
the process and after to keep track of what was done, and to properly
handle updates to invitations as they may change over time. This
history is usually kept separate from the actual "booked" event,
to-do, or daily journal entry, which would normally be placed in a
user's calendar collection.
In addition, it is useful to keep outgoing invitations separate from
incoming ones for organizational purposes.
Also, 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.
This specification introduces two new collection resource types that
are used for keeping incoming and outgoing scheduling messages
separate from other calendar object resources. These can also be
used to control who is able to send scheduling messages on behalf of
a user, and who is allowed to send scheduling messages to other users
by the use of new WebDAV ACL [RFC3744] privileges. Note that these
collections only contains scheduling messages that pertains to the
scheduling of events, to-dos and daily journal entries. Scheduling
Daboo, et al. Expires December 27, 2006 [Page 7]
Internet-Draft CalDAV June 2006
messages that describes requests for available busy time information,
or replies to such request, are not contained in these collections.
The scheduling "Inbox" collection contains received scheduling
messages. Scheduling messages are contained in calendar object
resources. Each calendar object resource has a WebDAV property that
indicates whether the scheduling message has already been processed
or not so that multiple clients do not repeat the processing actions
already done.
The scheduling "Outbox" collection contains scheduling message that
have been sent, which need to be tracked both to help synchronize
between multiple clients and to support delegation use cases. A
single user with multiple clients can use this collection to
synchronize the outbound request history. Two users coordinating
scheduling with one calendar (e.g., a calendar user and her
assistant) can see what scheduling messages the other user has sent.
The calendar owner would then typically have permission to DELETE the
scheduling messages but the assistant might 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 free-busy 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, 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.
The server may support delivery of scheduling messages to other
CalDAV servers, and the client may attempt to get the server to do
this by specifying remote addresses for the recipients, 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
Daboo, et al. Expires December 27, 2006 [Page 8]
Internet-Draft CalDAV June 2006
or server-to-client protocol to deliver 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.
5. New Resource Types and Properties
The CalDAV scheduling extension defines the following new resource
types for use with CalDAV.
5.1. 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
Daboo, et al. Expires December 27, 2006 [Page 9]
Internet-Draft CalDAV June 2006
(e.g., 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 in 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.
A new access control privilege can be defined on the scheduling Inbox
collection and can be used to control who is allowed to send
scheduling messages to the owner of the scheduling Inbox. See
Section 8.1 for more details.
5.2. Scheduling Outbox Collection
A scheduling Outbox collection contains outgoing scheduling messages.
These may be requests initiated by or on behalf of the owner of the
scheduling Outbox, or responses to requests received by the owner of
the scheduling Outbox.
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 (e.g., an iCalendar object that follows the iTIP semantic).
When a client targets the POST method at a scheduling Outbox, the
server MUST create a copy of the scheduling message in that
scheduling Outbox, unless the POST method corresponds to 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 (e.g., after a period of time or to keep within a
Daboo, et al. Expires December 27, 2006 [Page 10]
Internet-Draft CalDAV June 2006
quota). The server SHOULD allow deletion of calendar object
resources in the scheduling Outbox.
A new access control privilege can be defined on the scheduling
Outbox collection and can be used to control who is allowed to send
scheduling messages on behalf of the owner of the scheduling Outbox.
See Section 8.1 for more details.
5.3. Scheduling Inbox 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 owner of the scheduling Inbox.
Conformance: This property MAY be protected and SHOULD NOT be
returned by a PROPFIND allprop request (as defined in Section
12.14.1 of [I-D.ietf-webdav-rfc2518bis]). 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>
Daboo, et al. Expires December 27, 2006 [Page 11]
Internet-Draft CalDAV June 2006
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 a PROPFIND DAV:allprop request (as defined in Section
14.2 of [I-D.ietf-webdav-rfc2518bis]).
Description: The CALDAV:originator property MUST be defined on
calendar object resources stored in an Inbox or Outbox collection
as the result of a POST request. The value of the property MUST
be the value of the Originator request header in the POST request
that caused the resource to be created in the collection.
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.
Daboo, et al. Expires December 27, 2006 [Page 12]
Internet-Draft CalDAV June 2006
Conformance: This property MUST be protected and SHOULD NOT be
returned by a PROPFIND DAV:allprop request (as defined in Section
14.2 of [I-D.ietf-webdav-rfc2518bis]).
Description: The CALDAV:recipient property MUST be defined on
calendar object resources stored in a scheduling Outbox or Inbox
collection as the result of a POST request. For calendar object
resources in a scheduling Outbox, 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, 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 address will be one of those listed in
the CALDAV:calendar-user-address-set (see Section 8.2.3) property
for the principal that owns the scheduling Inbox. However, it
could, for example, be a calendar user address of a group that
includes the owner of the scheduling Inbox.
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>
5.4.3. CALDAV:schedule-state Property
Name: schedule-state
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Indicates the state of a scheduling message in a scheduling
Inbox.
Conformance: This property MAY be protected and SHOULD NOT be
returned by a PROPFIND DAV:allprop request (as defined in Section
14.2 of [I-D.ietf-webdav-rfc2518bis]).
Daboo, et al. Expires December 27, 2006 [Page 13]
Internet-Draft CalDAV June 2006
Description: The CALDAV:schedule-state property MUST be defined on
any calendar object resource in a scheduling Inbox collection. If
present, the property indicates whether the scheduling message has
been processed or not. Processing might have occurred as a result
of some form of automatic processing by the server or through a
client action. Clients MUST ensure that they set this property
value to indicate a processed state when they have processed the
scheduling message. This ensures that other clients with access
to the same resource don't attempt to repeat the actions required
to reply. Clients MUST NOT process a scheduling message that has
this property indicates the scheduling message has been processed.
When the scheduling message is delivered into the scheduling Inbox
the server MUST set this property value to indicate that the
scheduling message has not been processed.
Definition:
<!ELEMENT schedule-state (not-processed|processed)>
<!ELEMENT not-processed EMPTY>
<!ELEMENT processed EMPTY>
Example:
<C:schedule-state xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:processed/>
</C:schedule-state>
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.2).
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:
Daboo, et al. Expires December 27, 2006 [Page 14]
Internet-Draft CalDAV June 2006
(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., scheduling message follows the restriction of
iTIP);
(CALDAV:originator-specified): The POST request MUST include a
valid Originator request header specifying a 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 owner (or one of the owners) of the scheduling Outbox being
targeted by the request;
(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.
Postconditions: None
6.1.1. Originator request header
Every POST request MUST include an 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.
Typically the Originator request header's value will correspond to
Daboo, et al. Expires December 27, 2006 [Page 15]
Internet-Draft CalDAV June 2006
the Organizer of the calendar component and to the owner of the
Outbox being targeted by the request. However, the Organizer may
choose to allow another user to act on his behalf to send scheduling
messages. To allow for this a new privilege has been defined to
allow the owner of a scheduling Outbox to grant to other users the
right to execute POST requests on that Outbox.
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, and scheduling messages delivered to
any scheduling Inbox.
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 scheduling
messages, CalDAV servers MUST verify that the calendar user address
identified by the ORGANIZER property in the scheduling message data
corresponds to the principal owning the scheduling Outbox targeted by
the POST request. This MUST be done during the processing of the
POST request.
6.1.3. Recipient request header
Every POST request MUST include one or more Recipient request headers
in the 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 be delivered the scheduling message. The owner of the
scheduling Outbox 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.
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 is not listed as a Recipient, or
when a Recipient is not one of the ATTENDEE's.
For example, if the Organizer of an event wishes to attend the event
themselves, they must list themselves as one of the ATTENDEE's, 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
Daboo, et al. Expires December 27, 2006 [Page 16]
Internet-Draft CalDAV June 2006
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 were - they only get to see the
ATTENDEE information listed in the scheduling message data. So
listing a calendar user as a Recipient and not an ATTENDEE is the
equivalent of a 'Bcc' (blind-carbon-copy) operation in email.
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 10.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.
400 (Bad Request) - The client has provided an invalid scheduling
message.
Daboo, et al. Expires December 27, 2006 [Page 17]
Internet-Draft CalDAV June 2006
403 (Forbidden) - The client, for reasons the server chooses not to
specify, cannot submit a scheduling message to the specified Request-
URI.
404 (Not Found) - The URL in the Request-URI, the Originator, or the
Recipient request headers were 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.
502 (Bad Gateway) - The Recipient request header contained a URL
which the server considers to be in another domain, which it cannot
forward scheduling messages to.
507 (Insufficient Storage) - The server did not have sufficient space
to record the scheduling message in a recipient's scheduling inbox.
Daboo, et al. Expires December 27, 2006 [Page 18]
Internet-Draft CalDAV June 2006
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 December 27, 2006 [Page 19]
Internet-Draft CalDAV June 2006
>> Response <<
HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: text/xml
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 Inboxes
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
TODO:
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
Daboo, et al. Expires December 27, 2006 [Page 20]
Internet-Draft CalDAV June 2006
VFREEBUSY components for each of those calendar users with their busy
time indicated.
6.2. Retrieving incoming scheduling messages
Incoming scheduling messages will be stored in a scheduling Inbox
collection. The same reports work on scheduling collections, so the
client can use REPORT 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 December 27, 2006 [Page 21]
Internet-Draft CalDAV June 2006
>> 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
TODO: Need to explain here how to handle incoming scheduling
messages. If the client wants to accept a message, it needs to
create an event and mark the calendar object resource as "processed".
If the client wants to reject it, it simply changes a property. Need
to define that property. Also recommend locking the Inbox resource
to avoid race conditions with other clients -- or use ETags to
verify.
7. HTTP Request Headers for CalDAV
7.1. Originator Request Header
Daboo, et al. Expires December 27, 2006 [Page 22]
Internet-Draft CalDAV June 2006
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 RFC2396 [RFC2396].
7.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 RFC2396 [RFC2396]
8. Scheduling Access Control
8.1. Scheduling Privileges
A CalDAV server MUST support the WebDAV ACLs standard [RFC3744].
That standard provides a framework for an extensible list of
privileges on WebDAV collections and ordinary resources. A CalDAV
server MUST also support the set of calendar-specific privileges
defined in this section.
8.1.1. CALDAV:schedule-request Privilege
The CALDAV:schedule-request privilege controls who can initiate
scheduling requests, and who will accept such requests.
The CALDAV:schedule-request privilege can be applied to either a
scheduling Outbox or Inbox. Its effect depends on the type of
collection it is applied to.
When used on a scheduling Outbox, the CALDAV:schedule-request
privilege controls the use of the POST method to submit a scheduling
message via a scheduling Outbox collection. When granted to a
principal, that principal is allowed to use the POST method on the
schedule Outbox with the following restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
Daboo, et al. Expires December 27, 2006 [Page 23]
Internet-Draft CalDAV June 2006
the METHOD property in the iCalendar component in the request body
MUST be either PUBLISH or REQUEST.
When used on a scheduling Inbox, the CALDAV:schedule-request
privilege controls whether a scheduling message can be deposited in
the scheduling Inbox collection. When granted to a principal, that
principal is allowed to use the POST method to deposit scheduling
messages with the following restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
the METHOD property in the iCalendar component in the request body
MUST be either PUBLISH or REQUEST.
<!ELEMENT schedule-request EMPTY >
For example, the following ACE, on Bernard's scheduling Outbox, would
only grant the privilege to Bernard to send schedule request messages
on behalf of himself:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/bernard</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-request/></D:privilege>
</D:grant>
</D:ace>
Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
grant the privilege to Cyrus and his assistant Kim to send schedule
request messages on behalf of Cyrus:
Daboo, et al. Expires December 27, 2006 [Page 24]
Internet-Draft CalDAV June 2006
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/cyrus</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-request/></D:privilege>
</D:grant>
</D:ace>
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/kim</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-request/></D:privilege>
</D:grant>
</D:ace>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to send a schedule request message
to Bernard:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/lisa</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-request/></D:privilege>
</D:grant>
</D:ace>
8.1.2. CALDAV:schedule-reply Privilege
The CALDAV:schedule-reply privilege controls who can respond to
scheduling requests, and who will accept such responses.
The CALDAV:schedule-reply privilege can be applied to either a
scheduling Outbox or Inbox. Its effect depends on the type of
collection it is applied to.
When used on a scheduling Outbox, the CALDAV:schedule-reply privilege
controls the use of the POST method to submit a scheduling message
via a scheduling Outbox collection. When granted to a principal,
Daboo, et al. Expires December 27, 2006 [Page 25]
Internet-Draft CalDAV June 2006
that principal is allowed to use the POST method on the schedule
Outbox with the following restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
the METHOD property in the iCalendar component in the request body
MUST NOT be either PUBLISH or REQUEST.
When used on a scheduling Inbox, the CALDAV:schedule-reply privilege
controls whether a scheduling message can be deposited in the
scheduling Inbox collection. When granted to a principal, that
principal is allowed to use the POST method to deposit scheduling
messages with the following restrictions:
the iCalendar component in the request body MUST NOT be a
VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
the METHOD property in the iCalendar component in the request body
MUST NOT be either PUBLISH or REQUEST.
<!ELEMENT schedule-reply EMPTY >
For example, the following ACE, on Bernard's scheduling Outbox, would
only grant the privilege to Bernard to respond to schedule messages
on behalf of himself:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/bernard</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-reply/></D:privilege>
</D:grant>
</D:ace>
Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
grant the privilege to Cyrus and his assistant Kim to respond to
schedule messages on behalf of Cyrus:
Daboo, et al. Expires December 27, 2006 [Page 26]
Internet-Draft CalDAV June 2006
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/cyrus</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-reply/></D:privilege>
</D:grant>
</D:ace>
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/kim</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-reply/></D:privilege>
</D:grant>
</D:ace>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to send a scheduling reply message
to Bernard:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/lisa</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-reply/></D:privilege>
</D:grant>
</D:ace>
8.1.3. CALDAV:schedule-free-busy Privilege
The CALDAV:schedule-free-busy privilege controls who can initiate
free-busy requests, and who will accept such requests.
The CALDAV:schedule-free-busy privilege can be applied to either a
scheduling Outbox or Inbox. Its effect depends on the type of
collection it is applied to.
When used on a scheduling Outbox, the CALDAV:schedule-reply privilege
controls the use of the POST method to submit a scheduling message
via a scheduling Outbox collection. When granted to a principal,
Daboo, et al. Expires December 27, 2006 [Page 27]
Internet-Draft CalDAV June 2006
that principal is allowed to use the POST method on the schedule
Outbox with the following restrictions:
the iCalendar component in the request body MUST be a VFREEBUSY
component.
the METHOD property in the iCalendar component in the request body
MUST be REQUEST.
When used on a scheduling Inbox, the CALDAV:schedule-free-busy
privilege controls whether a scheduling message can be deposited in
the scheduling Inbox collection. When granted to a principal, that
principal is allowed to use the POST method to deposit scheduling
messages with the following restrictions:
the iCalendar component in the request body MUST be a VFREEBUSY
component.
the METHOD property in the iCalendar component in the request body
MUST be REQUEST.
<!ELEMENT schedule-free-busy EMPTY >
For example, the following ACE, on Bernard's scheduling Outbox, would
only grant the privilege to Bernard to request free-busy information
on behalf of himself:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/bernard</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-free-busy/></D:privilege>
</D:grant>
</D:ace>
Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
grant the privilege to Cyrus and his assistant Kim to free-busy
information on behalf of Cyrus:
Daboo, et al. Expires December 27, 2006 [Page 28]
Internet-Draft CalDAV June 2006
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/cyrus</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-free-busy/></D:privilege>
</D:grant>
</D:ace>
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/kim</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-free-busy/></D:privilege>
</D:grant>
</D:ace>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to retrieve free-busy information
for Bernard:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/lisa</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule-free-busy/></D:privilege>
</D:grant>
</D:ace>
8.1.4. CALDAV:schedule Privilege
The CALDAV:schedule privilege can be applied to either a scheduling
Outbox or Inbox. Its effect depends on the type of collection it is
applied to. This privilege is actually an aggregate of the CALDAV:
schedule-request, CALDAV:schedule-reply and CALDAV:schedule-free-busy
privileges.
<!ELEMENT schedule EMPTY >
For example, the following ACE, on Bernard's scheduling Outbox, would
only grant the privilege to Bernard to carry out any schedule
Daboo, et al. Expires December 27, 2006 [Page 29]
Internet-Draft CalDAV June 2006
operation on behalf of himself:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/bernard</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule/></D:privilege>
</D:grant>
</D:ace>
Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
grant the privilege to Cyrus and his assistant Kim to carry out any
schedule operation on behalf of Cyrus:
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/cyrus</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule/></D:privilege>
</D:grant>
</D:ace>
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/kim</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule/></D:privilege>
</D:grant>
</D:ace>
For example, the following ACE's, on Bernard's scheduling Inbox,
would grant the privilege to Lisa to carry out any schedule operation
with Bernard:
Daboo, et al. Expires December 27, 2006 [Page 30]
Internet-Draft CalDAV June 2006
<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/lisa</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule/></D:privilege>
</D:grant>
</D:ace>
8.1.5. Privilege aggregation and the DAV:supported-privilege-set
property
The CALDAV:schedule privilege MUST be non-abstract, and MUST be
aggregated under the DAV:bind privilege. The CALDAV:schedule
privilege MUST appear in the DAV:supported-privilege-set property of
scheduling Inbox and Outbox collections.
The CALDAV:schedule-request, CALDAV:schedule-reply and CALDAV:
schedule-free-busy privileges MUST be non-abstract, and MUST be
aggregated under the CALDAV:schedule privilege. These privileges
MUST appear in the DAV:supported-privilege-set property of scheduling
Inbox and Outbox collections.
8.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.
8.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
12.14.1 of [I-D.ietf-webdav-rfc2518bis]).
Daboo, et al. Expires December 27, 2006 [Page 31]
Internet-Draft CalDAV June 2006
Description: This property is needed for a client to determine where
the scheduling Inbox of the current user is located so that
processing of scheduling messages can occur.
Definition:
<!ELEMENT schedule-inbox-URL (href)>
8.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
12.14.1 of [I-D.ietf-webdav-rfc2518bis]).
Description: This property is needed for a client to determine where
the scheduling Outbox of the current user is located so that
sending of scheduling messages can occur.
Definition:
<!ELEMENT schedule-outbox-URL href>
8.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
12.14.1 of [I-D.ietf-webdav-rfc2518bis] ). 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.
Daboo, et al. Expires December 27, 2006 [Page 32]
Internet-Draft CalDAV June 2006
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. 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>
8.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-URL 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".
Daboo, et al. Expires December 27, 2006 [Page 33]
Internet-Draft CalDAV June 2006
>> Request <<
REPORT /users/ HTTP/1.1
Host: cal.example.com
Content-Type: text/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-URL/>
<D:displayname/>
</D:prop>
</D:principal-property-search>
>> Response <<
HTTP/1.1 207 Multi-Status
Content-Type: text/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-URL>
<D:href>/home/bernard/</D:href>
</C:calendar-home-URL>
<D:displayname>Bernard Desruisseaux</D:displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Daboo, et al. Expires December 27, 2006 [Page 34]
Internet-Draft CalDAV June 2006
8.2.5. Example: Finding the scheduling Inbox and Outbox 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
9. 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 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 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.
10. XML Element Definitions
10.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*)>
Daboo, et al. Expires December 27, 2006 [Page 35]
Internet-Draft CalDAV June 2006
10.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?)>
10.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 (#PCDATA)>
10.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.
Daboo, et al. Expires December 27, 2006 [Page 36]
Internet-Draft CalDAV June 2006
Definition:
<!ELEMENT request-status (#PCDATA)>
11. 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.
11.1. Verifying scheduling requests
When handling a POST request on a scheduling Outbox:
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 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
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).
Daboo, et al. Expires December 27, 2006 [Page 37]
Internet-Draft CalDAV June 2006
12. IANA Consideration
This specification does not require any IANA actions.
13. Acknowledgements
The authors would like to thank the following individuals for
contributing their ideas and support for writing this specification:
Julian F. Reschke 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.
14. Normative References
[I-D.dusseault-caldav]
Dusseault, L., "Calendaring Extensions to WebDAV
(CalDAV)", draft-dusseault-caldav-12 (work in progress),
April 2006.
[I-D.ietf-webdav-rfc2518bis]
Dusseault, L., "HTTP Extensions for Distributed Authoring
- WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in
progress), May 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[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.
[RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol (iMIP)", RFC 2447,
November 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Daboo, et al. Expires December 27, 2006 [Page 38]
Internet-Draft CalDAV June 2006
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.
[W3C.REC-xml-20040204]
Sperberg-McQueen, C., Maler, E., Bray, T., Paoli, J., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium
Recommendation http://www.w3.org/TR/2004/REC-xml-20040204,
February 2004.
Appendix A. Changes
A.1. Changes in -02
a. Split schedule privilege into three sub-privileges.
b. Made support for caldav-access optional.
c. Changed SCHEDULE method to POST.
A.2. 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.
e. Text related to alternative ways of doing scheduling (some
speculative) removed.
f. Added Security Considerations text.
g. Added IANA consideration text.
Daboo, et al. Expires December 27, 2006 [Page 39]
Internet-Draft CalDAV June 2006
Authors' Addresses
Cyrus Daboo
Email: cyrus@daboo.name
Bernard Desruisseaux
Oracle Corporation
600 blvd. de Maisonneuve West
Suite 1900
Montreal, QC H3A 3J2
CA
Email: bernard.desruisseaux@oracle.com
URI: http://www.oracle.com/
Lisa Dusseault
Open Source Application Foundation
2064 Edgewood Dr.
Palo Alto, CA 94303
US
Email: lisa@osafoundation.org
URI: http://www.osafoundation.org/
Daboo, et al. Expires December 27, 2006 [Page 40]
Internet-Draft CalDAV June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daboo, et al. Expires December 27, 2006 [Page 41]
