Network Working Group C. Daboo
Internet-Draft ISAMET
Expires: December 1, 2005 B. Desruisseaux
Oracle
L. Dusseault
OSAF
May 30, 2005
Scheduling Extensions to CalDAV
draft-desruisseaux-caldav-sched-00
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 1, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 1, 2005 [Page 1]
Internet-Draft CalDAV May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.3 Method Preconditions and Postconditions . . . . . . . . . 4
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 Model . . . . . . . . . . . . . . . . . . . . . . . 7
5. New Resource Types . . . . . . . . . . . . . . . . . . . . . . 9
5.1 iTIP Inbox Collection . . . . . . . . . . . . . . . . . . 9
5.2 iTIP Outbox Collection . . . . . . . . . . . . . . . . . . 9
6. Scheduling and Fanout . . . . . . . . . . . . . . . . . . . . 10
6.1 SCHEDULE Method . . . . . . . . . . . . . . . . . . . . . 11
6.1.1 Status Codes for use with 207 (Multi-Status) . . . . . 12
6.1.2 Example - Simple appointment invitation . . . . . . . 14
6.2 Retrieving incoming iTIP Messages . . . . . . . . . . . . 15
6.2.1 Example - Retrieve incoming iTIP Message . . . . . . . 15
6.3 Acting on incoming iTIP messages . . . . . . . . . . . . . 16
7. HTTP Headers for CalDAV . . . . . . . . . . . . . . . . . . . 17
7.1 Originator Header . . . . . . . . . . . . . . . . . . . . 17
7.2 Recipient Header . . . . . . . . . . . . . . . . . . . . . 17
8. Scheduling Access Control . . . . . . . . . . . . . . . . . . 18
8.1 Scheduling Privileges . . . . . . . . . . . . . . . . . . 18
8.1.1 CALDAV:schedule Privilege . . . . . . . . . . . . . . 18
8.1.2 CALDAV:calendar-bind Privilege . . . . . . . . . . . . 18
8.1.3 Privilege aggregation and the
DAV:supported-privilege-set property . . . . . . . . . 19
8.2 Additional Principal Properties . . . . . . . . . . . . . 20
8.2.1 CALDAV:itip-inbox-URL Property . . . . . . . . . . . . 20
8.2.2 CALDAV:itip-outbox-URL Property . . . . . . . . . . . 20
8.2.3 CALDAV:alternate-calendar-URI Property . . . . . . . . 20
9. Using CalDAV Reports . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . 23
11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. Normative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 27
Daboo, et al. Expires December 1, 2005 [Page 2]
Internet-Draft CalDAV May 2005
1. Introduction
This document specifies a set of methods, headers, properties and
privileges that define the CalDAV scheduling extensions to the WebDAV
[7] protocol. This document also provides the transport specific
information necessary to convey iCalendar Transport-independent
Interoperability Protocol iTIP [5] over WebDAV which enables
transactions such as publish, schedule, reschedule, respond to
scheduling requests, negotiation of changes or cancel iCalendar-based
calendar components.
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 [13].
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 type. 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.
Also note that some CalDAV XML element names are identiqual 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 [8]. Because this augmented BNF uses
the basic production rules provided in Section 2.2 of [8], those
rules apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
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
Daboo, et al. Expires December 1, 2005 [Page 3]
Internet-Draft CalDAV May 2005
"CALDAV:" will be prefixed to the element types respectively.
1.3 Method Preconditions and Postconditions
A "precondition" of a method describes the state of the server that
must be true for that method to be performed. A "postcondition" of a
method describes the state of the server that must be true after that
method has been completed. If a method precondition or postcondition
for a request is not satisfied, the response status of the request
MUST be either 403 (Forbidden) if the request should not be repeated
because it will always fail, or 409 (Conflict) if it is expected that
the user might be able to resolve the conflict and resubmit the
request.
In order to allow better client handling of 403 and 409 responses, a
distinct XML element type is associated with each method precondition
and postcondition of a request. When a particular precondition is
not satisfied or a particular postcondition cannot be achieved, the
appropriate XML element MUST be returned as the child of a top-level
DAV:error element in the response body, unless otherwise negotiated
by the request. In a 207 Multi-Status response, the DAV:error
element would appear in the appropriate DAV:responsedescription
element.
Daboo, et al. Expires December 1, 2005 [Page 4]
Internet-Draft CalDAV May 2005
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 calendar-access feature.
o MUST support the CALDAV:schedule and CALDAV:calendar-bind
privileges.
o MUST support the CALDAV:itip-inbox and CALDAV:itip-outbox
collection resource types.
o MUST support the SCHEDULE method and the Recipient and Originator
headers.
o MUST support iTIP.
Daboo, et al. Expires December 1, 2005 [Page 5]
Internet-Draft CalDAV May 2005
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, REPORT, SCHEDULE, ACL
DAV: 1, 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
SCHEDULE method.
Daboo, et al. Expires December 1, 2005 [Page 6]
Internet-Draft CalDAV May 2005
4. Scheduling Model
One of the key workflows in calendaring and scheduling is when a
meeting organizer creates an invitation and sends it to a number of
attendees. Each of those attendees wants the event to appear on
their own calendar (if they accept it) and have their participation
status sent back to the organizer in a related process. This section
is a brief overview of how scheduling workflows relate to the data
model of CalDAV.
To do scheduling, we need to model iTIP messages received by the
server as well as iTIP messages sent by the server on behalf of a
scheduling client. Each iTIP message is a CalDAV resource containing
an iCalendar object that has an iTIP METHOD property defined. We put
inbound and outbound iTIP messages in separate collections, so that
the client can easily locate relevant messages and assign scheduling
privileges.
The iTIP Inbox collection contains received iTIP messages. Received
replies (typically containing attendance information) may be
automatically parsed and the contained information can be applied to
the calendar. The Inbox contains inbound iTIP messages after they
are handled/seen by the user, because this serves as a track record
and to help synchronize between multiple clients.
The iTIP Outbox collection contains sent iTIP messages, 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.)
Thus, for every scheduling request, there should be one copy in the
organizer's iTIP Outbox, as well as one copy in each attendee's iTIP
Inbox. This document defines the SCHEDULE method to request that the
server place a copy of an iTIP message in a given iTIP Outbox, and to
deliver the iTIP message to the recipients' iTIP Inboxes.
The server may support delivery of iTIP 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 fanout operations even if it
advertises support for 'calendar-schedule' features. Note that
fanout mechanisms are not defined in CalDAV -- there is no server-to-
server or server-to-client protocol defined for delivering an iTIP
Daboo, et al. Expires December 1, 2005 [Page 7]
Internet-Draft CalDAV May 2005
message. Implementations may do this in a proprietary way, with
iMIP, or with iTIP bindings as yet unspecified.
After the fanout is completed, CalDAV clients will see the iTIP
messages the next time they synchronize or query the iTIP Inbox
collection. To reply to an iTIP REQUEST, the client uses the
SCHEDULE method to send another iTIP message (this time, a REPLY).
If the user has decided to accept the REQUEST, the client also uses
PUT (or some other method) to create a calendar resource (text/
calendar) in the appropriate calendar collection, and with the
appropriate details. The step of putting the calendar resource in
the calendar is left up to the client, so that the client can make
appropriate choices about where to put the calendar resource, and
with what alarms, etc. However, the server MAY be configured (how is
not defined here) to auto-accept or auto-reject invitations, and if
the server auto-accepts invitations then the server is responsible
for creating calendar resources in the user's calendar collection.
Multiple Calendars MAY share an iTIP Inbox collection, because an
iTIP Inbox maps more closely to a principal (e.g., a person) than a
calendar does. A person may have multiple calendars representing
different spheres of activity, but a scheduling request is unlikely
to address the correct sphere of activity. Instead, scheduling
requests are modelled as addressing a user's iITIP Inbox, and the
client accepting the scheduling request decides what Calendar the
request belongs to. Similarly, multiple calendars MAY share the same
iTIP Outbox collection, because we model scheduling requests as
coming from an iTIP Outbox, not the calendar.
Daboo, et al. Expires December 1, 2005 [Page 8]
Internet-Draft CalDAV May 2005
5. New Resource Types
CalDAV defines the following new resource types for use in calendar
repositories.
5.1 iTIP Inbox Collection
An iTIP Inbox collection contains incoming iTIP messages.
<resourcetype xmlns="DAV:">
<collection/>
<C:itip-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
</resourcetype>
Every non-collection resource in the iTIP Inbox collection is
considered to be an iTIP message. Every resource MUST have the media
type text/calendar, and contain the iCalendar METHOD property.
5.2 iTIP Outbox Collection
An iTIP Outbox collection contains outgoing iTIP messages, requests
and responses for appointments scheduled by the calendar owner (or
other users of this calendar). This collection is to store REQUESTs
initiated by this calendar server for this calendar, as well as REPLY
items received in reply. This collection is only for review because
the CalDAV server is responsible for parsing incoming iTIP messages
and adding attendee information to calendar resources.
<resourcetype xmlns="DAV:">
<collection/>
<C:itip-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
</resourcetype>
Every non-collection resource in the scheduling collection is
considered to be an iTIP message. Every resource MUST have the media
type text/calendar, and contain the iCalendar METHOD property. When
a client target the SCHEDULE method to an iTIP Outbox, the server is
responsible for putting a copy of of the iTIP message in that iTIP
Outbox. This then serves as a record of outgoing scheduling
messages.
The server MAY auto-delete messages in the outbox after a period of
time or to keep within a quota. The server SHOULD allow the calendar
owner to DELETE resources in the outbox.
Daboo, et al. Expires December 1, 2005 [Page 9]
Internet-Draft CalDAV May 2005
6. Scheduling and Fanout
Scheduling and fanout is a valuable function provided by calendaring
servers. Simple clients clearly benefit from having the logic
handled by the server. Rich clients also benefit from having to
upload less data to various servers (including messaging servers to
send invitations via messages) to accomplish the same things.
Servers can sometimes provide more advanced scheduling functionality
than clients - for example, a server providing fanout could create
"unconfirmed" VEVENT resources within invitees' calendars.
However, rich calendaring clients may prefer to do fanout. Clients
can perform special functionality during scheduling (for example, a
client may be configured to be able to directly put events on others'
calendars if the user has sufficient permissions). Thus, it is
proposed that CalDAV allow the client to either perform fanout and
merely create the event (complete with attendee information) OR
request that the server perform fanout.
TODO: We need to clarify if outgoing iTIP messages that have not yet
been delivered to all specified calendars should be accessible as
calendar resources in the iTIP Outbox collection.
Incoming iTIP messages may remain in the iTIP Inbox collection until
a client deletes them. CalDAV servers MUST parse incoming REPLY
messages and update the appropriate event with attendee information.
Thus, it's not necessary for clients to review REPLY messages,
although they may.
When a CalDAV server receives an iTIP message, it MUST store the
object in an iTIP Inbox collection for the client to handle. The
message will have properties indicating whether it is new, has been
accepted, has been rejected, and whether it is an obsolete REQUEST
(the event has passed). Note that when a calendar server receives
iTIP messages it MAY auto-accept based on user configured
preferences. How these preferences are configured is out of the
scope of this specification, but one could imagine that a CalDAV
server could host auto-accept configuration Web pages. A CalDAV
server is NOT REQUIRED to do any auto-accepting, it MAY simply store
the requests for the next time the client is online.
Servers SHOULD NOT delete messages before or after a client has
retrieved the messages in the inbox; instead the server SHOULD leave
Inbox cleanup to the client. A server MAY apply a quota to the iTIP
Inbox (limiting the number of messages, the total size, or some other
measurable) and MAY bounce incoming messages if the iTIP inbox is
full or some other repository or account problem has occurred.
Daboo, et al. Expires December 1, 2005 [Page 10]
Internet-Draft CalDAV May 2005
Exact mechanisms for triggering fanout requests must be determined
and input is welcome. There are several ways fanout could be
accomplished: (a) A PUT of the resource triggers fanout, so the body
must contain the fanout information (text and flags), (b) a PROPPATCH
triggers fanout if certain properties are set, (c) a new method
requests fanout of a resource that has already been uploaded. These
three approaches are the most obvious to this author and there is
surprisingly little to choose between. More input is needed, for
example input on whether the fanout should be synchronous or
asynchronous. An asynchronous fanout mechanism using PUT or
PROPPATCH would mean that the client would synchronously handle the
PUT or PROPPATCH itself, but send invitations at some later time. A
synchronous fanout mechanism would probably use a new method with a
name like SCHEDULE, because adding new synchronous behavior to
existing methods might require more complicated server implementation
work.
When the server does fanout, it may send requests and receive
replies. Probably these requests and responses should be stored as
WebDAV resources so that the client can examine the details if
desired. This could be a separate collection within the calendar
collection.
To achieve these goals, this section specifies a WebDAV binding for
the iCalendar Transport-independent Interoperability Protocol (iTIP
[5]). It provides the necessary information to convey iTIP over
WebDAV.
6.1 SCHEDULE Method
The SCHEDULE method submits an iTIP message specified in the request
body to the location specified by the Request-URI. The request body
of a SCHEDULE method MUST contain an iCalendar object that obey the
restrictions specified in iTIP [5]. The resource identified by the
Request-URI MUST be a resource collection of type CALDAV:itip-outbox
(Section 5.2).
The submitted iTIP message will be delivered to the calendar
addresses specified in the Recipient header.
The calendar address of the originator of the iTIP message MUST be
specified in the Originator header. This calendar address MUST
identify a resource collection of type CALDAV:itip-inbox
(Section 5.1). that is owned by the currently authenticated user.
The calendar address of the recipient(s) of the iTIP message MUST be
specified in the Recipient header. There MUST be at least one
Recipient per SCHEDULE request.
Daboo, et al. Expires December 1, 2005 [Page 11]
Internet-Draft CalDAV May 2005
The body of the SCHEDULE request is a complete iCalendar component
(content type text/calendar), and MUST have an iTIP method. The list
of attendees and the organizer information in this request body might
well be redundant with the values of the Recipient and Originator
headers. This is intentional, so that the client can have more
control over who receives invitations and who sends them:
o The client may send invitations to calendar users not on the
attendee list (for example, to an assistant, caterer, observer,
etc).
o The client may choose not to send invitations to calendar users
who are on the attendee list (for example, attendees who have been
scheduled through an out-of-band mechanism).
o The originator may be different than the organizer, for example an
assistant who has calendar-bind privileges on the organizer's
calendar.
The SCHEDULE request is intended to be independent with the PUT
request that stores an event on a particular calendar. This
independence gives greater flexibility and control to the client. In
the case where the event that is sent with SCHEDULE corresponds to an
event stored in a calendar, the client SHOULD submit the PUT request
first. That means that when the SCHEDULE request is sent and replies
are returned, the server is more likely to have an event on the
calendar on which to collate responses and show attendance.
6.1.1 Status Codes for use with 207 (Multi-Status)
The following are examples of response codes one would expect to be
used in a 207 (Multi-Status) response for this method. Note,
however, that unless explicitly prohibited any 2/3/4/5xx series
response code may be used in a 207 (Multi-Status) response.
200 (OK) - The command succeeded.
202 (Accepted) - The request was accepted, but the server has not
performed any action with it yet.
400 (Bad Request) - The client has provided an invalid iTIP message.
403 (Forbidden) - The client, for reasons the server chooses not to
specify, cannot submit an iTIP message to the specified Request-URI.
404 (Not Found) - The URL in the Request-URI, the Originator, or the
Recipient headers could not be found.
Daboo, et al. Expires December 1, 2005 [Page 12]
Internet-Draft CalDAV May 2005
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 header contained a URL which the
server considers to be in another domain, which it cannot forward
iTIP messages to.
507 (Insufficient Storage) - The server did not have sufficient space
to record the iTIP message in a recipient's iTIP inbox.
Also, many errors would be appropriate as top-level errors rather
than return a 207 (Multi-Status) response. For example, if the
server did not have sufficient space to record the iTIP message in
the originator's outbox, the server could send a 507 (Insufficient
Storage) response with no body.
Daboo, et al. Expires December 1, 2005 [Page 13]
Internet-Draft CalDAV May 2005
6.1.2 Example - Simple appointment invitation
>> Request <<
SCHEDULE /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
Originator: http://cal.example.com/lisa/inbox/
Recipient: http://cal.example.com/bernard/inbox/
Recipient: http://cal.example.com/cyrus/inbox/
Content-Type: text/calendar
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REQUEST
BEGIN:VEVENT
DTSTAMP:20040901T200200Z
CATEGORIES:APPOINTMENT
ORGANIZER:http://cal.example.com/lisa/inbox/
DTSTART:20040902T130000Z
DTEND:20040902T140000Z
SUMMARY:Design meeting
UID:34222-232@example.com
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
IVIDUAL;CN=Lisa Dusseault:http://cal.example.co
m/lisa/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:h
ttp://cal.example.com/bernard/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:http://cal
.example.com/cyrus/inbox/
END:VEVENT
END:VCALENDAR
Daboo, et al. Expires December 1, 2005 [Page 14]
Internet-Draft CalDAV May 2005
>> Response <<
HTTP/1.1 207 Multi-Status
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://cal.example.com/bernard/inbox/</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://cal.example.com/cyrus/inbox/</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
In this example, the client requests the server to deliver an
appointment invitation (iTIP REQUEST) in Bernard's and Cyrus's iTIP
Inbox collections.
6.2 Retrieving incoming iTIP Messages
Incoming iTIP messages will be stored in resource collection of type
"itip-inbox". The originator of the iTIP message will be specified
in the Originator response header. The same reports work on iTIP
collections, so the client can use REPORT to get partial information
on iTIP messages in the iTIP inbox.
6.2.1 Example - Retrieve incoming iTIP Message
>> Request <<
GET /bernard/calendar/inbox/mtg456.ics HTTP/1.1
Host: cal.example.com
Daboo, et al. Expires December 1, 2005 [Page 15]
Internet-Draft CalDAV May 2005
>> Response <<
HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 17:05:23 GMT
Originator: http://cal.example.com/lisa/inbox/
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:http://cal.example.com/lisa/inbox/
DTSTART:20040902T130000Z
DTEND:20040902T140000Z
SUMMARY:CalDAV draft review
UID:34222-232@example.com
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
IVIDUAL;CN=Lisa Dusseault:http://cal.example.co
m/lisa/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:h
ttp://cal.example.com/bernard/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:http://cal
.example.com/cyrus/inbox/
END:VEVENT
END:VCALENDAR
6.3 Acting on incoming iTIP messages
TODO: Need to explain here how to handle incoming iTIP messages. If
the client wants to accept a message, it needs to create an event and
mark the inbox resource as "accepted". 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.
Daboo, et al. Expires December 1, 2005 [Page 16]
Internet-Draft CalDAV May 2005
7. HTTP Headers for CalDAV
7.1 Originator Header
Originator = "Originator" ":" absoluteURI
The Originator header value is a URL which identifies an iTIP Inbox
collection owned by the originator of an iTIP message submitted with
the SCHEDULE method. Note that the absoluteURI production is defined
in RFC2396 [3].
7.2 Recipient Header
Recipient = "Recipient" ":" 1#absoluteURI
The Recipient header value is a URL which identifies one or more iTIP
Inbox collections to which the SCHEDULE method should delivered a
submitted iTIP message. Note that the absoluteURI production is
defined in RFC2396 [3]
Daboo, et al. Expires December 1, 2005 [Page 17]
Internet-Draft CalDAV May 2005
8. Scheduling Access Control
8.1 Scheduling Privileges
A CalDAV server MUST support the WebDAV ACLs standard [11]. 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 Privilege
The schedule privilege controls the use of SCHEDULE to submit an iTIP
message via an iTIP Outbox collection. A calendar owner will
generally have schedule permission on their own outbox and never
grant that permission to anybody else. If the privilege is granted
to somebody other than the calendar owner, that person is called the
delegate, somebody who can issue invitations or replies on behalf of
the calendar owner. Thus, if a server receives a SCHEDULE request
where the authenticated sender of the SCHEDULE request does not have
schedule permission, the server MUST reject the request.
<!ELEMENT schedule EMPTY >
For example, the following ACE, on Bernard's iTIP Outbox, would only
grant the privilege to Bernard to schedule 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>
8.1.2 CALDAV:calendar-bind Privilege
The calendar-bind privilege is used on a iTIP Inbox or on a calendar
collection, to govern whether a user may cause new calendar resources
(MIME type text/calendar) to be created in the collection. It is
similar to the WebDAV 'bind' privilege but more restricted, because
it only allows the user to create new resources of certain types. It
doesn't, for example, allow the privileged user to create new
collections.
Daboo, et al. Expires December 1, 2005 [Page 18]
Internet-Draft CalDAV May 2005
Recall that the iTIP Inbox is used to receive iTIP messages. The
server automatically creates resources inside the iTIP Inbox when it
handles invitations for the inbox's owner. Thus, the calendar-bind
privilege determines whether an event organizer is allowed to send an
invitation to an attendee and have it appear in their iTIP Inbox.
One way an invitation may appear in an iTIP inbox is with the
SCHEDULE request. If the server receives a SCHEDULE request where a
calendar inbox is named in the Recipient header, it MUST check to see
whether the 'calendar-bind' privilege is granted either to the
authenticated sender of the request, OR to the owner of the iTIP
Outbox that the request comes from (the Request-URI of the SCHEDULE
method). Thus, if user Alice grants Bob calendar-bind privilege on
Alice's inbox, and Bob grants Margaret (his assistant) schedule
privilege on Bob's outbox, then transitively, Margaret can send a
SCHEDULE request to Bob's outbox, where Alice's inbox is named in the
Recipient header. If the server's calendar-bind privilege check
fails for a given inbox, the rest of the SCHEDULE request may still
succeed, but a 403 Forbidden error would appear in the Multi-status
response to the SCHEDULE request.
The server SHOULD also attempt to apply the calendar-bind privilege
in other situations where it is requested to add a resource to the
iTIP inbox. For example, if the server handles invitations received
through some other iTIP binding, the server SHOULD try to see if the
invitation should be automatically rejected based on the access
control on the iTIP inbox.
Outside the iTIP inbox, the same privilege has a slightly different
effect, but has the same meaning. If the server receives any HTTP
request which would create a new resource inside a calendar, the
server MUST check to see whether calendar-bind privilege is granted
on that calendar collection.
Typically, not many users will allow others to put events directly on
their calendar, instead preferring to see invitations and choose
whether to accept. In the exceptional cases, users will allow a
select few to directly put events on their calendar, and in these
cases, the 'calendar-bind' privilege will be granted to those few.
On the other hand, many users are happy to receive invitations from
anyone, so an iTIP inbox may grant 'calendar-bind' privilege to all
users.
<!ELEMENT calendar-bind EMPTY >
8.1.3 Privilege aggregation and the DAV:supported-privilege-set
property
Daboo, et al. Expires December 1, 2005 [Page 19]
Internet-Draft CalDAV May 2005
The schedule and calendar-bind privileges MUST be non-abstract, and
MUST be aggregated under the 'bind' privilege. These MUST appear in
the 'supported-privilege-set' property.
8.2 Additional Principal Properties
This section defines new properties for WebDAV principal resources as
defined in RFC3744 [11]. All these properties SHOULD exist on every
principal if the server supports CalDAV scheduling anywhere in its
namespace. Generally, if no appropriate value is known for these
properties, the properties SHOULD exist but be blank. Generally
these properties are likely to be protected but the server MAY allow
them to be written by appropriate users.
8.2.1 CALDAV:itip-inbox-URL Property
Name: itip-inbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URL of the iTIP Inbox collection owned by the
associated principal resource.
<!ELEMENT itip-inbox-URL href>
8.2.2 CALDAV:itip-outbox-URL Property
Name: itip-outbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URL of the iTIP Outbox collection owned by the
associated principal resource.
<!ELEMENT itip-outbox-URL href>
8.2.3 CALDAV:alternate-calendar-URI Property
Name: alternate-calendar-URI
Namespace: urn:ietf:params:xml:ns:caldav
Daboo, et al. Expires December 1, 2005 [Page 20]
Internet-Draft CalDAV May 2005
Purpose: Identify the URI of an alternate calendar or scheduling
resource for the associated principal resource.
Description: The alternate-calendar-URI property is used to provide a
resource address or identifier, such as a mailto URL [2] calendar
address, that can be used as an alternative to the primary-itip-
inbox-URL of the associated resource in the Originator or
Recipient headers. This property SHOULD contain the mailto URL if
it is known to accept iMIP requests, because clients generally
need a way to find out if some calendar user for whom the iMIP
address is known is the same calendar user for whom the iTIP Inbox
address is known, and this property is the only reliable way to
link those addresses together.
Value: Zero or more URIs
<!ELEMENT alternate-calendar-URI (href*) >
Daboo, et al. Expires December 1, 2005 [Page 21]
Internet-Draft CalDAV May 2005
9. Using CalDAV Reports
TODO: Explain and give example(s) of using CalDAV report to query
resources in an iTIP Inbox or Outbox.
Daboo, et al. Expires December 1, 2005 [Page 22]
Internet-Draft CalDAV May 2005
10. Security Considerations
TODO
Daboo, et al. Expires December 1, 2005 [Page 23]
Internet-Draft CalDAV May 2005
11. IANA Consideration
TODO
Daboo, et al. Expires December 1, 2005 [Page 24]
Internet-Draft CalDAV May 2005
12. 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.
13. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL
scheme", RFC 2368, July 1998.
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[4] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
[5] 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.
[6] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message-
Based Interoperability Protocol (iMIP)", RFC 2447,
November 1998.
[7] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV",
RFC 2518, February 1999.
[8] 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.
[9] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
Whitehead, "Versioning Extensions to WebDAV (Web Distributed
Authoring and Versioning)", RFC 3253, March 2002.
[10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[11] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV) Access Control
Daboo, et al. Expires December 1, 2005 [Page 25]
Internet-Draft CalDAV May 2005
Protocol", RFC 3744, May 2004.
[12] Daboo, C., Desruisseaux, B., and L. Dusseault, "Scheduling
Extensions to CalDAV", ID draft-dusseault-caldav-06, May 2005.
[13] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F.
Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC-xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
Authors' Addresses
Cyrus Daboo
ISAMET Inc.
5001 Baum Blvd
Suite 650
Pittsburgh, PA 15213
US
Email: daboo@isamet.com
URI: http://www.isamet.com/
Bernard Desruisseaux
Oracle Corporation
600 blvd. de Maisonneuve West
10th Floor
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 1, 2005 [Page 26]
Internet-Draft CalDAV May 2005
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 (2005). 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 1, 2005 [Page 27]
