Network Working Group C. Daboo
Internet-Draft Apple Inc.
Intended status: Standards Track B. Desruisseaux
Expires: March 23, 2009 Oracle
September 19, 2008
CalDAV Scheduling Extensions to WebDAV
draft-desruisseaux-caldav-sched-05
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 March 23, 2009.
Abstract
This document defines extensions to the CalDAV "calendar-access"
feature to specify a standard way of performing scheduling
transactions with iCalendar-based calendar components. This document
defines the "calendar-auto-schedule" feature of CalDAV.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Level of Support for iTIP . . . . . . . . . . . . . . . . 4
1.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 5
Daboo & Desruisseaux Expires March 23, 2009 [Page 1]
Internet-Draft CalDAV Schedule September 2008
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. CalDAV Scheduling Support . . . . . . . . . . . . . . . . . . 7
3. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Scheduling Collections . . . . . . . . . . . . . . . . . . 9
3.1.1. Scheduling Calendar Collection . . . . . . . . . . . . 9
3.1.2. Scheduling Outbox Collection . . . . . . . . . . . . . 10
3.1.3. Scheduling Inbox Collection . . . . . . . . . . . . . 11
3.2. Automatic Scheduling Transactions . . . . . . . . . . . . 12
3.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Identifying Scheduling Object Resources . . . . . . . 12
3.2.3. Handling Scheduling Object Resources . . . . . . . . . 13
3.2.3.1. Organizer Scheduling Object Resources . . . . . . 13
3.2.3.2. Attendee Scheduling Object Resources . . . . . . . 16
3.2.3.3. HTTP Methods . . . . . . . . . . . . . . . . . . . 18
3.3. Processing of incoming scheduling messages . . . . . . . . 20
3.3.1. Automatic processing for the "Organizer" . . . . . . . 20
3.3.1.1. Processing an "Attendee" reply . . . . . . . . . . 20
3.3.1.2. Processing an "Attendee" refresh . . . . . . . . . 21
3.3.2. Automatic processing for the "Attendee" . . . . . . . 21
3.3.2.1. Processing a new scheduling message . . . . . . . 21
3.3.2.2. Processing a scheduling message update . . . . . . 21
3.3.3. Processing by the client . . . . . . . . . . . . . . . 22
3.4. Explicit Scheduling Request . . . . . . . . . . . . . . . 22
3.5. Other Considerations . . . . . . . . . . . . . . . . . . . 22
3.5.1. Handling recurring items . . . . . . . . . . . . . . . 22
3.5.1.1. Restricting what is sent . . . . . . . . . . . . . 22
3.5.1.2. "Attendee" overrides . . . . . . . . . . . . . . . 23
3.5.2. Handling the Default Calendar . . . . . . . . . . . . 23
3.5.3. DTSTAMP and SEQUENCE properties . . . . . . . . . . . 24
3.5.4. Schedule Status Values . . . . . . . . . . . . . . . . 24
3.5.5. Error Handling . . . . . . . . . . . . . . . . . . . . 26
3.5.6. "Organizer" is an "Attendee" . . . . . . . . . . . . . 26
4. New iCalendar Parameters . . . . . . . . . . . . . . . . . . . 26
4.1. Schedule Agent . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Schedule Status . . . . . . . . . . . . . . . . . . . . . 27
5. New WebDAV Request Header . . . . . . . . . . . . . . . . . . 28
5.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 28
6. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 29
6.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 29
6.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 30
6.3. CALDAV:schedule-state Property . . . . . . . . . . . . . . 30
7. New Preconditions . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Additional Preconditions for PUT, COPY and MOVE . . . . . 31
7.2. Additional Preconditions for PUT . . . . . . . . . . . . . 32
7.3. Additional Precondition for PROPPATCH . . . . . . . . . . 33
8. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.1. Handling a REFRESH . . . . . . . . . . . . . . . . . . 34
Daboo & Desruisseaux Expires March 23, 2009 [Page 2]
Internet-Draft CalDAV Schedule September 2008
8.1.2. Response to a POST request . . . . . . . . . . . . . . 35
8.1.3. Status Codes for use with the POST method . . . . . . 35
8.1.4. Example - Simple meeting invitation refresh . . . . . 36
8.1.5. Example - Freebusy lookup . . . . . . . . . . . . . . 37
8.2. Retrieving incoming scheduling messages . . . . . . . . . 38
9. Scheduling Access Control . . . . . . . . . . . . . . . . . . 39
9.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 39
9.1.1. Privileges on Scheduling Inbox Collections . . . . . . 39
9.1.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . 39
9.1.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . 39
9.1.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . 40
9.1.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . 40
9.1.2. Privileges on Scheduling Outbox Collections . . . . . 40
9.1.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . 40
9.1.2.2. CALDAV:schedule-send-invite Privilege . . . . . . 40
9.1.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . 41
9.1.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . 41
9.1.3. Aggregation of Scheduling Privileges . . . . . . . . . 41
9.2. Additional Principal Properties . . . . . . . . . . . . . 42
9.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 42
9.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 42
9.2.3. CALDAV:calendar-user-address-set Property . . . . . . 43
9.2.4. CALDAV:calendar-user-type Property . . . . . . . . . . 44
10. Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
11. XML Element Definitions . . . . . . . . . . . . . . . . . . . 45
11.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 45
11.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 45
11.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 46
11.4. CALDAV:request-status XML Element . . . . . . . . . . . . 46
12. Security Considerations . . . . . . . . . . . . . . . . . . . 46
12.1. Verifying scheduling requests . . . . . . . . . . . . . . 46
13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 47
13.1. HTTP header registration . . . . . . . . . . . . . . . . . 47
13.1.1. Schedule-Reply Request Header Registration . . . . . . 48
13.2. iCalendar Registrations . . . . . . . . . . . . . . . . . 48
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
15.1. Normative References . . . . . . . . . . . . . . . . . . . 48
15.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 49
A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 49
A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 51
Appendix B. Example Workflows . . . . . . . . . . . . . . . . . . 53
Appendix C. Changes (to be removed prior to publication as an
RFC) . . . . . . . . . . . . . . . . . . . . . . . . 53
C.1. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 53
Daboo & Desruisseaux Expires March 23, 2009 [Page 3]
Internet-Draft CalDAV Schedule September 2008
1. Introduction
This document specifies an extension to the CalDAV "calendar-access"
feature [RFC4791] to enable scheduling of iCalendar-based [RFC2445]
calendar components between calendar users. This extension leverages
the scheduling methods defined in the iCalendar Transport-independent
Interoperability Protocol iTIP [RFC2446] to permit calendar users to
perform scheduling transactions such as schedule, reschedule, respond
to scheduling request or cancel scheduled calendar components, as
well as search for busy time information.
iTIP [RFC2446] outlines a model where calendar users exchange
scheduling messages with one another. Often times, calendar user
agents are made responsible for generating and sending scheduling
messages as well as processing incoming scheduling messages. This
approach yields a number of problems, including:
o The handling of incoming scheduling messages and the updates to
calendars imposed by these messages only occurs when calendar user
agents are active.
o For most updates to a calendar, calendar user agents need to
address a separate scheduling message to the "Organizer" or the
"Attendees".
o Due to the update latency it is possible for calendars of
different calendar users to reflect different, inaccurate states.
This specification is using an alternative approach where the server
is made responsible for sending most scheduling messages and
processing most incoming scheduling messages. This approach frees
the calendar user agents from the delivery and processing of most
scheduling messages and ensures better consistency of users' calendar
data. The simple operation of creating, modifying or deleting a
calendar object resource in a calendar is enough to trigger the
CalDAV server to deliver appropriate scheduling messages to the
calendar users.
Discussion of this Internet-Draft is taking place on the mailing list
<http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
1.1. Level of Support for iTIP
While the scheduling features described in this specification are
based on iTIP [RFC2446], some of its more complex features have
deliberately not been implemented, in order to keep this
specification simple. In particular, the following iTIP [RFC2446]
features are not supported:
Daboo & Desruisseaux Expires March 23, 2009 [Page 4]
Internet-Draft CalDAV Schedule September 2008
o Sending scheduling messages with the scheduling methods "PUBLISH",
"COUNTER", and "DECLINECOUNTER"
o Delegating an Event to another calendar user
o Changing the "Organizer"
o Forwarding to an uninvited calendar user
The goal of this specification is to provide the essential scheduling
features needed, and it is anticipated that future extensions will be
developed to address the more complex features if the demand arises.
1.2. XML Namespaces
Definitions of XML elements in this document use XML element type
declarations (as found in XML Document Type Declarations), described
in Section 3.2 of [W3C.REC-xml-20060816].
The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
elements defined in this specification, or in other Standards Track
IETF RFCs written to extend CalDAV. It MUST NOT be used for
proprietary extensions.
Note that the XML declarations used in this document are incomplete,
in that they do not include namespace information. Thus, the reader
MUST NOT use these declarations as the only way to create valid
CalDAV properties or to validate CalDAV XML element types. Some of
the declarations refer to XML elements defined by WebDAV which use
the "DAV:" namespace. Wherever such elements appear, they are
explicitly given the "DAV:" prefix to help avoid confusion.
Additionally, some of the elements used here are defined in CalDAV
[RFC4791].
Also note that some CalDAV XML element names are identical to WebDAV
XML element names, though their namespace differs. Care MUST be
taken not to confuse the two sets of names.
1.3. Notational Conventions
The augmented BNF used by this document to describe protocol elements
is described in Section 2.1 of HTTP [RFC2616]. Because this
augmented BNF uses the basic production rules provided in Section 2.2
of HTTP [RFC2616], those rules apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Daboo & Desruisseaux Expires March 23, 2009 [Page 5]
Internet-Draft CalDAV Schedule September 2008
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.4. Terminology
Calendar user agent (CUA): Software with which the calendar user
communicates with a calendar service or local calendar store to
access calendar information.
Calendar collection: Same as CalDAV "calendar-access" [RFC4791].
Scheduling calendar collection: Calendar collection that supports
automatic scheduling transactions.
Basic calendar collection: Calendar collections as defined in CalDAV
"calendar-access" [RFC4791] are referred to as basic calendar
collections. Scheduling calendar collections are not basic
calendar collections.
Calendar object resource: Same as CalDAV "calendar-access"
[RFC4791].
Scheduling object resource: Calendar object resource contained in a
scheduling calendar collection for which the server will take care
of sending scheduling messages and processing incoming scheduling
messages on behalf of the owner of the calendar collection.
Organizer scheduling object resource: Scheduling object resource
owned by an "Organizer".
Attendee scheduling object resource: Scheduling object resource
owned by an "Attendee".
Automatic scheduling transaction: Add, change or remove operations
on a scheduling object resource in a scheduling calendar
collection for which the server will deliver scheduling messages
to other users.
Explicit scheduling request: Scheduling requests targeted at a
scheduling Outbox collection such as search for busy time
information as well as refresh requests.
Scheduling message: Calendar object resource that describes a
scheduling transaction such as publish, schedule, reschedule,
respond to scheduling requests, or cancel calendar components.
Daboo & Desruisseaux Expires March 23, 2009 [Page 6]
Internet-Draft CalDAV Schedule September 2008
Scheduling Outbox collection: Resource at which explicit scheduling
requests can be targeted.
Scheduling Inbox collection: A collection in which a recipient's
incoming scheduling messages are delivered.
2. CalDAV Scheduling Support
In order for a server to support the scheduling extensions defined in
this specification it MUST support the CalDAV "calendar-access"
feature [RFC4791] and all of its dependencies.
A server that supports the features described in this document MUST
include "calendar-auto-schedule" as a field in the DAV response
header from an OPTIONS request on any resource that supports any
scheduling actions, properties, privileges or methods.
>> Request <<
OPTIONS /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
>> Response <<
HTTP/1.1 204 No Content
Date: Thu, 31 Mar 2005 09:00:00 GMT
Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE,
Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, 3, access-control
DAV: calendar-access, calendar-auto-schedule
In this example, the OPTIONS response indicates that the server
supports both the "calendar-access" and "calendar-auto-schedule"
features and that resource "/lisa/calendar/outbox/" supports the
properties, reports, methods, and privileges defined in this
specification.
3. 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.
Daboo & Desruisseaux Expires March 23, 2009 [Page 7]
Internet-Draft CalDAV Schedule September 2008
In the first phase, the "Organizer" tries to determine a time for the
meeting that ought to be acceptable to each "Attendee". This
involves finding out when each "Attendee" is available during the
period of time in which the meeting needs to occur (or simply finding
a suitable time for all attendees to come together for the meeting),
and determining when the most appropriate time is for which each
"Attendee" is free. This process is called a "freebusy" lookup.
In the second phase, the "Organizer" sends out invitations to each
"Attendee" using the time determined from the freebusy lookup - or a
suitable guess as to an appropriate time based on other factors if
freebusy lookup is not feasible. Then, some "Attendees" may choose
to attend at the time provided by the "Organizer", while others may
decline to attend. Once the "Organizer" has received the replies
from the "Attendees" the "Organizer" can take appropriate action to
confirm the meeting, reschedule it or perhaps cancel it.
The user "expectation" as to how a calendaring and scheduling system
should respond in each of these two phases is somewhat different. In
the case of a freebusy lookup, users expect to get back results
immediately so that they can then move on to the invitation phase as
quickly as possible. In the case of invitations, it is expected that
each "Attendee" will reply with their participation status in their
own time, so delays in receiving replies are anticipated. Thus
calendaring and scheduling systems should treat these two operational
phases in different ways to accommodate the user expectations, and
this specification does that.
The scenario above covers the case of scheduling events ("VEVENT"
components) between calendar users, and doing freebusy lookups
("VFREEBUSY" components). However, iTIP [RFC2446] also allows
exchange of "VTODO" and "VJOURNAL" components. Since this
specification is based on iTIP, "VTODO" and "VJOURNAL" components can
also be used. For the majority of the following discussion,
scheduling of events and freebusy lookups will be discussed as these
are the more common operations.
In this specification there are two primary modes of carrying out a
scheduling transaction. For an "automatic scheduling transaction",
calendar data created, modified or removed from calendar collections
cause scheduling operations to occur. For an "explicit scheduling
request", scheduling operations are triggered by an HTTP POST request
to a special resource. iTIP freebusy lookups and iTIP "METHOD:
REFRESH" operations are done via explicit scheduling requests. All
other scheduling methods defined in iTIP, except for "PUBLISH",
"COUNTER", and "DECLINECOUNTER" which are not supported, are done via
automatic scheduling transactions.
Daboo & Desruisseaux Expires March 23, 2009 [Page 8]
Internet-Draft CalDAV Schedule September 2008
3.1. Scheduling Collections
This specification introduces new collection resource types that are
used for managing resources specific to scheduling, in addition to
basic calendar object resources.
3.1.1. Scheduling Calendar Collection
A "scheduling calendar collection" is a calendar collection, as
defined by CalDAV "calendar-access" [RFC4791], in which creation,
modification or deletion of a scheduling object resource that impacts
other calendar users, will cause automatic scheduling transactions to
occur.
A scheduling calendar collection MUST report the DAV:collection,
CALDAV:calendar and CALDAV:schedule-calendar XML elements in the
value of the DAV:resourcetype property. The element type declaration
for the new CALDAV:schedule-calendar is:
<!ELEMENT schedule-calendar EMPTY>
Example:
<D:resourcetype xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:collection />
<C:calendar />
<C:schedule-calendar />
</D:resourcetype>
As per CalDAV "calendar-access" [RFC4791], servers may automatically
provision calendar collections, in which case they can automatically
make those scheduling calendar collections if appropriate.
The MKCALENDAR method request defined in CalDAV "calendar-access"
[RFC4791] is extended by this specification in the following ways:
1. If an MKCALENDAR request does not have a request body, the server
MUST create a scheduling calendar collection if the request
succeeds.
2. If an MKCALENDAR request has a request body specifying WebDAV
properties to set and the DAV:resourcetype property is not
included in the list of properties to set, then the server MUST
create a scheduling calendar collection if the request succeeds.
3. If an MKCALENDAR request has a request body specifying WebDAV
properties to set and the DAV:resourcetype property is included
Daboo & Desruisseaux Expires March 23, 2009 [Page 9]
Internet-Draft CalDAV Schedule September 2008
in the list of properties to set, then the server MUST create a
calendar collection of the type determined by the value of the
DAV:resourcetype property if the request succeeds.
The DAV:resourcetype property on a calendar collection MUST be
immutable. Once a calendar collection has been created, servers MUST
NOT change it from a scheduling calendar collection to a basic
calendar collection, or vice versa.
Servers MUST support scheduling for all iCalendar component types
reported in the CALDAV:supported-calendar-component-set property on a
scheduling calendar collection. Also, servers MUST support
scheduling for all the media types reported in the CALDAV:supported-
calendar-data property on a scheduling calendar collection.
3.1.2. Scheduling Outbox Collection
A scheduling Outbox collection is used as the target for initiating
the processing of manual scheduling messages. Currently the only
defined use for this is for "VEVENT", "VTODO", and "VJOURNAL"
"REFRESH" iTIP messages as well as "VFREEBUSY" "REQUEST" iTIP
messages to request a synchronous freebusy lookup for a number of
calendar users.
A scheduling Outbox collection MUST report the DAV:collection and
CALDAV:schedule-outbox XML elements in the value of the DAV:
resourcetype property. The element type declaration for CALDAV:
schedule-outbox is:
<!ELEMENT schedule-outbox EMPTY>
Example:
<D:resourcetype xmlns:D="DAV:">
<D:collection/>
<C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
</D:resourcetype>
New WebDAV ACL [RFC3744] privileges can be used on the scheduling
Outbox collection to control who is allowed to send scheduling
messages on behalf of the calendar user associated with the
scheduling Outbox collection. See Section 9.1 for more details.
A scheduling Outbox collection MUST NOT be a child (at any depth) of
a calendar collection resource.
A scheduling Outbox collection MAY have a CALDAV:supported-calendar-
data WebDAV property defined on it as per CalDAV "calendar-access"
Daboo & Desruisseaux Expires March 23, 2009 [Page 10]
Internet-Draft CalDAV Schedule September 2008
[RFC4791] Section 5.2.4. When present this indicates the allowed
media types for scheduling messages POST'ed to the scheduling Outbox
collection.
3.1.3. 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:
<D:resourcetype xmlns:D="DAV:">
<D:collection/>
<C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
</D:resourcetype>
Every resource in the scheduling Inbox collection MUST be a valid
calendar object resource that defines a scheduling message (i.e., an
iCalendar object that follows the iTIP semantic). Note that unlike
calendar collections defined by the CalDAV "calendar-access" feature,
there are no restrictions on the nature of the resources stored
(e.g., there is no need to verify that the "UID" property of each
resource is unique) beyond the restrictions of iTIP itself. The
removal of the "UID" restriction, in particular, is needed because
multiple scheduling messages may be sent for one particular calendar
component, and each of those will have the same "UID" property in the
calendar object resource. This also implies that a scheduling Inbox
collection cannot contain any types of WebDAV collection resources.
New WebDAV ACL [RFC3744] privileges can be set on the scheduling
Inbox collection to control who the user associated with the
scheduling Inbox collection will accept scheduling messages from.
See Section 9.1 for more details.
A scheduling Inbox collection MUST NOT be a child (at any depth) of a
calendar collection resource.
A scheduling Inbox collection MAY have a CALDAV:supported-calendar-
data WebDAV property defined on it as per CalDAV "calendar-access"
[RFC4791] Section 5.2.4. When present this indicates the allowed
Daboo & Desruisseaux Expires March 23, 2009 [Page 11]
Internet-Draft CalDAV Schedule September 2008
media types for scheduling messages delivered to the scheduling Inbox
collection.
A scheduling Inbox collection MAY have a CALDAV:calendar-timezone
WebDAV property defined on it as per CalDAV "calendar-access"
[RFC4791] Section 5.2.2. When present this contains a time zone that
the server can use when calendar date-time operations are carried
out, for example when a time-range CALDAV:calendar-query REPORT is
targeted at a scheduling Inbox collection.
3.2. Automatic Scheduling Transactions
3.2.1. Introduction
When a calendar object resource is created, modified or removed from
a scheduling calendar collection that supports the operations defined
in this specification (either via a PUT, DELETE, COPY or MOVE HTTP
request), the server examines the calendar data and checks to see
whether the data represents a scheduling object resource. If it
does, the server will take care of automatically sending and
processing scheduling messages to the appropriate recipients.
Several types of scheduling operation can occur in this case,
equivalent to iTIP "REQUEST", "REPLY", "CANCEL" and "ADD" operations.
When a scheduling transaction is processed by the server, it will
attempt to deliver a scheduling message to each recipient.
3.2.2. Identifying Scheduling Object Resources
The server will only perform automatic scheduling transactions on
creations, modifications, and deletions of valid scheduling object
resources. There are two types of scheduling object resources:
organizer scheduling object resources, and attendee scheduling object
resources.
A calendar object resource is considered to be a valid organizer
scheduling object resource if the "ORGANIZER" iCalendar property is
present and set in all the calendar components to a value that
matches one of the calendar user addresses of the owner of the
scheduling calendar collection.
A calendar object resource is considered to be a valid attendee
scheduling object resource if the "ORGANIZER" iCalendar property is
present and set in all the calendar components to the same value and
doesn't match one of the calendar user addresses of the owner of the
scheduling calendar collection, and that one of the "ATTENDEE"
iCalendar property values match one of the calendar user addresses of
the owner of the scheduling calendar collection.
Daboo & Desruisseaux Expires March 23, 2009 [Page 12]
Internet-Draft CalDAV Schedule September 2008
The creation of attendee scheduling object resources will typically
be done by the server in cases where a default scheduling calendar
collection is defined. In cases where no default scheduling calendar
collection is defined, the server MAY prevent calendar user agents
from forging attendee scheduling object resources by forbidding their
creation or imposing restrictions on their creation. For instance, a
server MAY require the presence of a scheduling message, received
from the "ORGANIZER" with the same "UID" property value, in the
scheduling Inbox collection of the owner of the scheduling calendar
collection.
3.2.3. Handling Scheduling Object Resources
The server's behavior when processing a scheduling object resource
depends on whether it is owned by the "Organizer" or an "Attendee"
specified in the calendar data.
3.2.3.1. Organizer Scheduling Object Resources
An "Organizer" can create, modify or remove a scheduling object
resource by issuing HTTP requests with an appropriate method. The
create, modify and remove behaviors for the server are each described
next, and the way these are invoked via HTTP requests is described in
Section 3.2.3.3.
3.2.3.1.1. Actions on "Organizer" Scheduling Object Resource
3.2.3.1.1.1. Create
When a scheduling object resource is created by the "Organizer", the
server will inspect each "ATTENDEE" property to determine which ones
have the "SCHEDULE-AGENT" iCalendar property parameter.
For each "Attendee" the server will determine whether to attempt to
deliver a scheduling message into the "Attendee's" scheduling Inbox
collection, based on the table below:
+------------------+-------------+
| SCHEDULE-AGENT | iTIP METHOD |
+==================+=============+
| SERVER (default) | REQUEST |
+------------------+-------------+
| CLIENT | -- |
+------------------+-------------+
| NONE | -- |
+------------------+-------------+
The attempt to deliver the scheduling message will either succeed or
Daboo & Desruisseaux Expires March 23, 2009 [Page 13]
Internet-Draft CalDAV Schedule September 2008
fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
iCalendar property parameter to the "ATTENDEE" iCalendar property in
the scheduling object resource being created, and set its value as
described in Section 3.5.4. This will result in the created calendar
object resource differing from the calendar data sent in the HTTP
request. As a result clients SHOULD reload the calendar data from
the server as soon as it is stored in order to update to the new
server generated state information. Servers MUST NOT set the
"SCHEDULE-STATUS" property on any "ATTENDEE" properties for
"Attendees" that were not sent a scheduling message.
Restrictions:
1. The server MUST reject any attempt to set the "PARTSTAT"
iCalendar property parameter value of the "ATTENDEE" iCalendar
property of other users in the calendar object resource to a
value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property
parameter value is not present or set to the value "SERVER".
2. The server MUST reject any attempt to create a duplicate
scheduling object resource in any of the scheduling calendar
collections owned by the "Organizer". A duplicate scheduling
object resource is one with the same "UID" as an existing
scheduling object resource.
3. The server MUST take into account scheduling privileges when
handling the creation of a scheduling object resource as
described in Section 9.1.
3.2.3.1.1.2. Modify
When a scheduling object resource is modified by the "Organizer", the
server will inspect each "ATTENDEE" property in the new calendar data
to determine which ones have the "SCHEDULE-AGENT" iCalendar property
parameter. It will then need to compare this with the "ATTENDEE"
properties in the existing calendar object resource that is being
modified.
For each "Attendee" in the old and new calendar data on a per-
instance basis, and taking into account the addition or removal of
"Attendees", the server will determine whether to attempt to deliver
a scheduling message to the "Attendee". The following table
determines whether the server needs to delivery a scheduling message,
and if so using which iTIP scheduling method. The heading values
"SERVER", "CLIENT" and "NONE" makes reference to the "SCHEDULE-AGENT"
parameter value of the "ATTENDEE" property, and the heading values
"<Absent>" and "<Removed>" are used to cover the cases where the
"ATTENDEE" property was not present (Old) or has been removed (New).
Daboo & Desruisseaux Expires March 23, 2009 [Page 14]
Internet-Draft CalDAV Schedule September 2008
+---------------+-----------------------------------------------+
| | New |
| ATTENDEE +-----------+-----------+-----------+-----------+
| | <Removed> | SERVER | CLIENT | NONE |
| | | (default) | | |
+===+===========+===========+===========+===========+===========+
| | <Absent> | -- | REQUEST / | -- | -- |
| | | | ADD | | |
| +-----------+-----------+-----------+-----------+-----------+
| | SERVER | CANCEL | REQUEST | CANCEL | CANCEL |
| O | (default) | | | | |
| l +-----------+-----------+-----------+-----------+-----------+
| d | CLIENT | -- | REQUEST / | -- | -- |
| | | | ADD | | |
| +-----------+-----------+-----------+-----------+-----------+
| | NONE | -- | REQUEST / | -- | -- |
| | | | ADD | | |
+---+-----------+-----------+-----------+-----------+-----------+
The attempt to deliver the scheduling message will either succeed or
fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
iCalendar property parameter to the "ATTENDEE" iCalendar property in
the scheduling object resource being modified, and set its value as
described in Section 3.5.4. This will result in the created calendar
object resource differing from the calendar data sent in the HTTP
request. As a result clients SHOULD reload the calendar data from
the server as soon as it is stored in order to update to the new
server generated state information.
Restrictions:
1. The client MUST NOT change the "PARTSTAT" iCalendar property
parameter value on any "ATTENDEE" iCalendar property in the
calendar object resource to a value other than "NEEDS-ACTION" if
the "SCHEDULE-AGENT" property parameter value is not present or
set to the value "SERVER".
2. The client MUST NOT change the "UID" iCalendar property parameter
value in the scheduling object resource.
3. The server MUST take into account scheduling privileges when
handling the modification of a scheduling object resources as
described in Section Section 9.1.
Daboo & Desruisseaux Expires March 23, 2009 [Page 15]
Internet-Draft CalDAV Schedule September 2008
3.2.3.1.1.3. Remove
When a scheduling object resource is removed by the "Organizer", the
server will inspect each "ATTENDEE" property in the scheduling object
resource being removed to determine which ones have the "SCHEDULE-
AGENT" iCalendar property parameter.
For each "Attendee" the server will determine whether to attempt to
deliver a scheduling message into the "Attendee's" scheduling Inbox
collection, based on the table below:
+------------------+-------------+
| SCHEDULE-AGENT | iTIP METHOD |
+==================+=============+
| SERVER (default) | CANCEL |
+------------------+-------------+
| CLIENT | -- |
+------------------+-------------+
| NONE | -- |
+------------------+-------------+
The attempt to deliver the scheduling message will either succeed or
fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
iCalendar property parameter to the "ATTENDEE" iCalendar property in
the scheduling object resource being created, and set its value as
described in Section 3.5.4. This will result in the created calendar
object resource differing from the calendar data sent in the HTTP
request. As a result clients SHOULD reload the calendar data from
the server as soon as it is stored in order to update to the new
server generated state information. Servers MUST NOT set the
"SCHEDULE-STATUS" property on any "ATTENDEE" properties for
"Attendees" that were not sent a scheduling message.
Restrictions:
1. The server MUST take into account scheduling privileges when
handling the removal of a scheduling object resource as described
in Section 9.1.
3.2.3.2. Attendee Scheduling Object Resources
An "Attendee" can create, modify or remove a scheduling object
resource by issuing HTTP requests with an appropriate method. The
create, modify and remove behaviors for the server are each described
next, and the way these are invoked via HTTP requests is described in
Section 3.2.3.3.
Daboo & Desruisseaux Expires March 23, 2009 [Page 16]
Internet-Draft CalDAV Schedule September 2008
3.2.3.2.1. Actions on a Scheduling Object Resource
3.2.3.2.1.1. Allowed "Attendee" Changes
Attendees need to some changes to a scheduling object resource,
though the key scheduling properties such as start, end, location,
summary etc. are typically under the control of the "Organizer" of
the event.
The server MUST allow attendees to:
1. change their own "PARTSTAT" iCalendar property parameter value.
2. add or remove "X-" iCalendar property parameters on their own
"ATTENDEE" properties.
3. add, modify or remove any "TRANSP" iCalendar properties.
4. add, modify or remove any "X-" iCalendar properties in any
component.
5. add, modify or remove any "VALARM" iCalendar components.
6. add, modify or remove "PRODID", "CALSCALE" or "X-" iCalendar
properties within the top-level "VCALENDAR" component.
7. create new components to represent overridden recurrence
instances, provided the only changes to the recurrence instance
follow the rules above.
3.2.3.2.1.2. Create
A scheduling object resource is created by an "Attendee" when the
client creates a scheduling object resource corresponding to an
unprocessed scheduling message currently in that "Attendee's"
scheduling Inbox collection.
The "Attendee" is allowed to make changes as noted above.
If the "Attendee" changes one or more "PARTSTAT" iCalendar property
values on any component, or adds an overridden component with a
changed "PARTSTAT" property, then the server MUST deliver an
iTIP"REPLY" scheduling message to the "Organizer" to indicate the new
participation status of the "Attendee".
The attempt to deliver the scheduling message will either succeed or
fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
iCalendar property parameter to the "ORGANIZER" iCalendar property in
Daboo & Desruisseaux Expires March 23, 2009 [Page 17]
Internet-Draft CalDAV Schedule September 2008
the scheduling object resource being created, and set its value as
described in Section 3.5.4. This will result in the created calendar
object resource differing from the calendar data sent in the HTTP
request. As a result clients SHOULD reload the calendar data from
the server as soon as it is stored in order to update to the new
server generated state information.
3.2.3.2.1.3. Modify
Behavior is as per the Create action above.
3.2.3.2.1.4. Remove
When a scheduling object resource is removed by the "Attendee", one
of two possibilities exist:
1. If the HTTP request contains a request header "Schedule-Reply"
set to the value "T" or there is no "Schedule-Reply" request
header, then the server MUST attempt to deliver a scheduling
message to the "Organizer" indicating that the "Attendee" has a
"PARTSTAT" iCalendar property parameter value set to "DECLINED",
i.e., the "Attendee" has chosen not to attend any instances. If
the server is unable to deliver the scheduling message, the
remove action MUST fail, and an appropriate "SCHEDULE-STATUS"
iCalendar property parameter set on the "ORGANIZER" property in
the scheduling object resource stored by the server.
2. If the HTTP request contains a request header "Schedule-Reply"
set to the value "F", the server MUST NOT attempt to deliver a
scheduling message. The resource is simply removed. This
provides the client a way to silently remove unwanted scheduling
attempts.
3.2.3.3. HTTP Methods
This section describes how use of various HTTP methods on a
scheduling object resource will cause a create, modify or remove
action on that resource as described above.
3.2.3.3.1. PUT
When a PUT method request is received, the server will execute the
following actions, provided all appropriate pre-conditions are met:
Daboo & Desruisseaux Expires March 23, 2009 [Page 18]
Internet-Draft CalDAV Schedule September 2008
+--------------------------+--------------------------+-------------+
| Existing Destination | Resulting Destination | Server |
| Resource | Resource | Action |
+--------------------------+--------------------------+-------------+
| None | Calendar object resource | None |
| None | Scheduling object | Create |
| | resource | |
| Calendar object resource | Calendar object resource | None |
| Calendar object resource | Scheduling object | Create |
| | resource | |
| Scheduling object | Calendar object resource | Remove |
| resource | | |
| Scheduling object | Scheduling object | Modify |
| resource | resource | |
+--------------------------+--------------------------+-------------+
3.2.3.3.2. COPY
When a COPY method request is received, the server will execute the
same behavior as described above for a PUT method, with appropriate
pre-conditions applied.
3.2.3.3.3. MOVE
When a MOVE method request is received:
when moving from a basic calendar collection, into a scheduling
calendar collection, the server will execute the same behavior as
described above for a PUT method, with appropriate pre-conditions
applied.
when moving from a scheduling calendar collection, into a basic
calendar collection, the server will execute the behavior shown in
Table 1.
when moving from a scheduling calendar collection, into a
scheduling calendar collection, no special behavior occurs, though
appropriate pre-conditions are applied.
+----------------------------+---------------+
| Source Resource | Server Action |
+----------------------------+---------------+
| Calendar object resource | None |
| Scheduling object resource | Remove |
+----------------------------+---------------+
Table 1
Daboo & Desruisseaux Expires March 23, 2009 [Page 19]
Internet-Draft CalDAV Schedule September 2008
3.2.3.3.4. DELETE
When a DELETE method is targeted at a scheduling object resource the
server will execute the Remove action.
When a DELETE method is targeted at a scheduling calendar collection
the server will execute the Remove action on all scheduling object
resources contained in the scheduling calendar collection.
3.3. Processing of incoming scheduling messages
Scheduling operations can cause the delivery of a scheduling message
into an "Organizer's" or "Attendee's" scheduling Inbox collection.
In the former case the scheduling messages are replies or refresh
requests from "Attendees", in the latter case the scheduling messages
are requests, cancellations or additions from the "Organizer".
In some cases the server will automatically process the scheduling
message, in other cases the scheduling message will be left for the
client to process. In each case, the scheduling message in the
scheduling Inbox collection is used as an indicator to the client
that a scheduling operation has taken place.
3.3.1. Automatic processing for the "Organizer"
3.3.1.1. Processing an "Attendee" reply
For a scheduling message reply sent by an "Attendee", the server
first locates the corresponding scheduling object resource belonging
to the "Organizer".
The server MUST then update the "PARTSTAT" iCalendar parameter value
of each "ATTENDEE" iCalendar property in the scheduling object
resource to match the changes indicated in the reply (taking into
account the fact that an "Attendee" could have created a new
overridden iCalendar component to indicate different participation
status on one or more instances of a recurring event).
The server MUST also update or add the "SCHEDULE-STATUS" property
parameter on each matching "ATTENDEE" iCalendar property and sets its
value to that of the "REQUEST-STATUS" property in the reply, or to
"2.0" if "REQUEST-STATUS" is not present (also taking into account
recurrence instances).
At the same time, the server MUST add the CALDAV:schedule-state
WebDAV property with the value CALDAV:schedule-processed (see
Section 6.3) to the scheduling message in the Inbox scheduling
collection.
Daboo & Desruisseaux Expires March 23, 2009 [Page 20]
Internet-Draft CalDAV Schedule September 2008
The server MUST send scheduling messages to all the other "Attendees"
indicating the change in participation status of the "Attendee"
replying, subject to the recurrence requirements of Section 3.5.1.
3.3.1.2. Processing an "Attendee" refresh
TODO: write something here.
3.3.2. Automatic processing for the "Attendee"
For a scheduling message sent by the "Organizer", the server first
tries to locate a corresponding scheduling object resource belonging
to the "Attendee". If no matching scheduling object resource exists,
the server treats the scheduling message as a new message, otherwise
it is treated as an update.
3.3.2.1. Processing a new scheduling message
When a scheduling message for a new calendar components is detected,
two possibilities exist, depending on whether a "default" calendar
(Section 3.5.2) is set for the "Attendee":
1. if no valid default calendar is set, the server leaves the
scheduling message in the scheduling Inbox collection, but it
MUST add the CALDAV:schedule-state WebDAV property with the value
CALDAV:schedule-unprocessed (see Section 6.3) to the scheduling
message. It is then up to the client to explicitly process the
scheduling message and remove it from the scheduling Inbox
collection once it has done so.
2. if a valid default calendar is set, the server MUST process the
scheduling message and create an appropriate scheduling object
resource in the default calendar set for the "Attendee". At the
same time it MUST add the CALDAV:schedule-state WebDAV property
with the value CALDAV:schedule-processed (see Section 6.3) to the
scheduling message.
3.3.2.2. Processing a scheduling message update
When an update to scheduling message is detected, the server MUST
update the matching scheduling object resource belonging to the
"Attendee" to reflect the changes proposed in the scheduling message.
At the same time it MUST add the CALDAV:schedule-state WebDAV
property with the value CALDAV:schedule-processed (see Section 6.3)
to the scheduling message.
Daboo & Desruisseaux Expires March 23, 2009 [Page 21]
Internet-Draft CalDAV Schedule September 2008
3.3.3. Processing by the client
When a client detects a scheduling message in the scheduling Inbox
collection it needs to look at the CALDAV:schedule-state WebDAV
property on the resource and act accordingly:
1. if CALDAV:schedule-state is set to CALDAV:schedule-unprocessed,
then it is the client's responsibility to process the scheduling
message and remove it from the scheduling Inbox collection once
it has done so.
2. if CALDAV:schedule-state is set to CALDAV:schedule-processed,
then the server has already processed the scheduling message, but
has left it in the scheduling Inbox collection to serve as a
notification to the client that a change has been made to the
corresponding scheduling object resource. It is then the
client's responsibility to remove the scheduling object resource
from the scheduling Inbox collection once it has made note of the
fact that a change has occurred.
3.4. Explicit Scheduling Request
An explicit scheduling request sends a scheduling message via an HTTP
POST request targeted at a scheduling Outbox collection. Full
details can be found in Section 8.1.
3.5. Other Considerations
3.5.1. Handling recurring items
3.5.1.1. Restricting what is sent
When delivering scheduling messages for recurring calendar components
to "Attendees", servers MUST ensure that "Attendees" only get
information about recurrence instances that explicitly include them
as an "Attendee".
For example, if an "Attendee" is invited to a single recurrence
instance of a recurring event, and no others, the scheduling objet
resource contained in the "Organizer's" scheduling calendar
collection will contain an overridden instance in the form of a
separate calendar component. That separate calendar component will
include the "ATTENDEE" property referencing the "one-off" "Attendee".
That "Attendee" will not be listed in any other calendar components
in the scheduling object resource. The scheduling message that will
be delivered to the "Attendee" will only contain information about
this overridden instance.
Daboo & Desruisseaux Expires March 23, 2009 [Page 22]
Internet-Draft CalDAV Schedule September 2008
As another example, an "Attendee" could be excluded from one instance
of a recurring event. In that case the scheduling object resource
contained in the scheduling calendar collection of the "Organizer"
will include an overridden instance with an "ATTENDEE" list that does
not include the "Attendee" being excluded. The scheduling message
that will be delivered to the "Attendee" will not specify the
overridden instance but rather include an "EXDATE" property to the
master recurring component defining the recurrence set.
This requirement is needed to ensure that "Attendees" only have
access to calendar data for items they have been explicitly invited
to.
3.5.1.2. "Attendee" overrides
When a recurring scheduling message is sent to an "Attendee", that
"Attendee" may wish to reply with different participation status on
one or more recurrence instances. In order to do that it will need
to add an overridden iCalendar component for the instances with
different participation status, and send that as a reply back to the
"Organizer". The "Organizer" will then need to incorporate any new
overridden instances into the matching scheduling object resource to
ensure that the "Attendee's" participation status is accurately
recorded for all recurrence instances.
3.5.2. Handling the Default Calendar
A calendar user may have multiple calendars representing different
"spheres of activity". However, scheduling requests are targeted at
calendar users and not a specific calendar of a calendar user. Often
it is not appropriate to automatically deliver a scheduling message
to a particular calendar because that scheduling message refers to an
event for a different "sphere of activity". By storing all incoming
scheduling requests in a separate special collection, clients can
process the requests in that collection and choose which calendar
("sphere of activity") the request belongs to and make its own
arrangements to place the relevant calendar object in that calendar.
This specification defines the concept of a "default" scheduling
calendar collection. If a valid default scheduling calendar
collection is specified, then servers are required to automatically
process new scheduling messages and create the appropriate scheduling
object resource in the default calendar collection. If there is no
valid default calendar, then the server does not automatically
process new scheduling messages, and instead leaves it up to the
client to process the scheduling message and create the appropriate
scheduling object resource in a scheduling calendar collection chosen
by the calendar user.
Daboo & Desruisseaux Expires March 23, 2009 [Page 23]
Internet-Draft CalDAV Schedule September 2008
In order to manage this behavior, a new CALDAV:schedule-default-
calendar-URL WebDAV property is defined for use on scheduling Inbox
collections. This property is used to define the default calendar
collection, if one is required. See Section 6.2.
3.5.3. DTSTAMP and SEQUENCE properties
Whenever the server generates a scheduling message for delivery to a
recipient, it MUST ensure that a "DTSTAMP" iCalendar property is
present and MUST set the value to the UTC time that the scheduling
message was generated (as required by iCalendar).
iTIP [RFC2446] places certain requirements on how the "SEQUENCE"
iCalendar property value in scheduling messages changes. The server
MUST ensure that for each type of scheduling operation, the
"SEQUENCE" iCalendar property value is appropriately updated. If the
client does not update the "SEQUENCE" iCalendar property itself when
that is required, the server MUST update the property and change any
scheduling object resource accordingly.
3.5.4. Schedule Status Values
When scheduling with an "Attendee" there are two types of status
information that can be returned during the transaction. The first
status information is a "delivery" status that indicates whether the
scheduling message from the "Organizer" to the "Attendee" was
delivered or not, or what the current status of delivery is. The
second status information is a "reply" status corresponding to the
"Attendee's" own "REQUEST-STATUS" information from the scheduling
message reply that is sent back to the "Organizer".
Similarly, when an "Attendee" sends a reply back to the "Organizer",
there will be "delivery" status information for the scheduling
message sent to the "Organizer". However, there is no "REQUEST-
STATUS" sent back by the "Organizer", so there is no equivalent of
the "reply" status as per scheduling messages to "Attendees".
The "delivery" status information on an "ORGANIZER" or "ATTENDEE"
iCalendar property is conveyed in the "SCHEDULE-STATUS" property
parameter value (Section 4.2). The status code value for "delivery"
status can be one of the following:
Daboo & Desruisseaux Expires March 23, 2009 [Page 24]
Internet-Draft CalDAV Schedule September 2008
+----------+--------------------------------------------------------+
| Delivery | Description |
| Status | |
| Code | |
+----------+--------------------------------------------------------+
| 1.0 | The scheduling message is pending, that is, the server |
| | is still in the process of sending the message. The |
| | status code value can be expected to change once the |
| | server has completed its sending and delivery |
| | attempts. |
| | |
| 1.1 | The scheduling message has been successfully sent. |
| | However, the server does not have explicit information |
| | about whether the scheduling message was successfully |
| | delivered to the recipient. This state van occur with |
| | "store and forward" style scheduling protocols such as |
| | iMIP [RFC2447] (iTIP using email). |
| | |
| 1.2 | The scheduling message has been successfully |
| | delivered. |
| | |
| 3.7 | The scheduling message was not delivered because the |
| | server did not recognize the calendar user address of |
| | the recipient as being a supported URI. |
| | |
| 3.8 | The scheduling message was not delivered because |
| | access privileges do not allow it. |
| | |
| 5.1 | The scheduling message was not delivered because the |
| | server could not complete delivery of the message. |
| | This is likely due to a temporary failure, and the |
| | originator can try to send the message again at a |
| | later time. |
| | |
| 5.2 | The scheduling message was not delivered because the |
| | server was not able to find a suitable way to deliver |
| | the message. This is likely a permanent failure, and |
| | the originator should not try to send the message |
| | again, at least without verifying/correcting the |
| | calendar user address of the recipient. |
| | |
| 5.3 | The scheduling message was not delivered and was |
| | rejected because scheduling with that recipient is not |
| | allowed. This is likely a permanent failure, and the |
| | originator should not try to send the message again. |
+----------+--------------------------------------------------------+
The status code for "reply" status can be any of the valid iTIP
Daboo & Desruisseaux Expires March 23, 2009 [Page 25]
Internet-Draft CalDAV Schedule September 2008
[RFC2446] "REQUEST-STATUS" values.
3.5.5. Error Handling
TODO: e.g., how to deal with failed cancels.
3.5.6. "Organizer" is an "Attendee"
The "Organizer" of a scheduled calendar component may also be an
"Attendee" of that calendar component. In such cases the server MUST
NOT send a scheduling message to the "Attendee" that matches the
"Organizer".
4. New iCalendar Parameters
This section describes additions to iCalendar [RFC2445] to support
CalDAV scheduling.
4.1. Schedule Agent
Parameter Name: SCHEDULE-AGENT
Purpose: Indicates what agent is expected to handle scheduling for
the corresponding "Attendee".
Format Definition: This property parameter is defined by the
following notation:
scheduleagentparam = "SCHEDULE-AGENT" "="
("SERVER" ; The server handles scheduling
/ "CLIENT" ; The client handles scheduling
/ "NONE" ; No automatic scheduling
/ x-name ; Experimental type
/ iana-token) ; Other IANA registered
; type
; Default is SERVER
Description: This property parameter MAY be present on any
"ATTENDEE" iCalendar property. In the absence of this parameter,
the value "SERVER" MUST be used for the default behavior. The
value determines whether or not an automatic scheduling
transaction on a server will cause a scheduling message to be sent
to the corresponding calendar user identified by the "ATTENDEE"
property value. When the value "SERVER" is specified (or the
parameter is absent) then it is the server's responsibility to
send a scheduling messages as part of an automatic scheduling
transaction. When the value "CLIENT" is specified, that indicates
that the client is handling scheduling messages with the calendar
Daboo & Desruisseaux Expires March 23, 2009 [Page 26]
Internet-Draft CalDAV Schedule September 2008
user itself. When "NONE" is specified, no scheduling messages are
being sent to the calendar user.
Servers MUST NOT include this parameter in any scheduling messages
sent as the result of an automatic scheduling transaction.
Clients SHOULD NOT include this parameter in any scheduling
messages that they themselves send.
Example:
ATTENDEE;SCHEDULE-AGENT=SERVER:mailto:cyrus@example.org
4.2. Schedule Status
Parameter Name: SCHEDULE-STATUS
Purpose: Indicates the status code returned from processing of the
most recent scheduling message sent to the corresponding
"Attendee", or received from the corresponding "Organizer".
Format Definition: This property parameter is defined by the
following notation:
schedulestatusparam = "SCHEDULE-STATUS" "=" statcode
; statcode defined in RFC2445.
Description: This property parameter may be present on any
"ATTENDEE" or "ORGANIZER" iCalendar property.
Servers MUST add this parameter to any "ATTENDEE" properties
corresponding to calendar users who were sent a scheduling message
via an automatic scheduling transaction. Clients SHOULD NOT
change or remove this parameter if it was provided by the server.
In the case where the client is handling the scheduling the client
MAY add, change or remove this parameter to indicate the last
scheduling message status it received.
Servers MUST add this parameter to any "ORGANIZER" properties
corresponding to calendar users who were sent a scheduling message
reply by an "Attendee" via an automatic scheduling transaction.
Clients SHOULD NOT change or remove this parameter if it was
provided by the server. In the case where the client is handling
the scheduling the client MAY add, change or remove this parameter
to indicate the last scheduling message status it received.
Daboo & Desruisseaux Expires March 23, 2009 [Page 27]
Internet-Draft CalDAV Schedule September 2008
Servers MUST NOT include this parameter in any scheduling messages
sent as the result of an automatic scheduling transaction.
Clients SHOULD NOT include this parameter in any scheduling
messages that they themselves send.
Suitable values for this property parameter are described in
Section 3.5.4.
Example:
ATTENDEE;SCHEDULE-STATUS="2.0":mailto:cyrus@example.org
5. New WebDAV Request Header
The CalDAV scheduling extension defines the following new WebDAV
request headers for use with CalDAV.
5.1. Schedule-Reply Request Header
ScheduleReply = "Schedule-Reply" ":" ("T" | "F")
When an HTTP DELETE request occurs on a scheduling object resource,
and the Schedule-Reply header is not present, or present and set to
the value "T", the server MUST send an appropriate iTIP "CANCEL"
scheduling message as part of its normal automatic scheduling
transaction processing.
When an HTTP DELETE request occurs on a scheduling object resource,
and the Schedule-Reply header is set to the value "F", the server
MUST NOT send an iTIP scheduling message as part of its normal
automatic scheduling transaction processing.
The Schedule-Reply request header is used by a client to indicate to
a server whether or not an automatic scheduling transaction should
occur when an "Attendee" deletes a scheduling object resource. In
particular it controls whether an iTIP "CANCEL" message is sent to
the "Organizer" as a result of the deletion. There are situations in
which unsolicited scheduling messages need to be silently deleted (or
ignored) for security or privacy reasons. The new header allows the
scheduling message to be suppressed if such a need arises.
All scheduling object resources MUST support the Schedule-Reply
header.
Daboo & Desruisseaux Expires March 23, 2009 [Page 28]
Internet-Draft CalDAV Schedule September 2008
6. New WebDAV Properties
The CalDAV scheduling extension defines the following new WebDAV
properties for use with CalDAV.
6.1. CALDAV:schedule-calendar-transp Property
Name: schedule-calendar-transp
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Determines whether the calendar object resources in a
calendar collection will affect the owner's freebusy.
Protected: This property MAY be protected and SHOULD NOT be returned
by a PROPFIND allprop request (as defined in Section 14.2 of
WebDAV [RFC4918]).
COPY/MOVE behavior: This property value SHOULD be kept during a MOVE
operation, but is normally re-initialized when a resource is
created with a COPY. It should not be set in a COPY.
Description: This property SHOULD be defined on all calendar object
resources. If present, it contains one of two XML elements that
indicate whether the calendar object resources should contribute
to the owner's freebusy or not. When the 'opaque' element is
used, all calendar object resources MUST contribute to freebusy,
assuming access privileges and other iCalendar properties allow it
to. When the 'transparent' XML element is used, all calendar
object resources MUST NOT contribute to freebusy.
Definition:
<!ELEMENT schedule-calendar-transp (opaque|transparent) >
<!ELEMENT opaque EMPTY>
<!-- Calendar object resources affect owner freebusy -->
<!ELEMENT transparent EMPTY>
<!-- Calendar object resources never affect owner freebusy -->
Example:
<C:schedule-calendar-transp
xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:opaque/>
</C:schedule-calendar-transp>
Daboo & Desruisseaux Expires March 23, 2009 [Page 29]
Internet-Draft CalDAV Schedule September 2008
6.2. CALDAV:schedule-default-calendar-URL Property
Name: schedule-default-calendar-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a default calendar for an attendee that will
automatically have new scheduling messages deposited into it when
they arrive.
Protected: This property MAY be protected in the case where a server
supports only a single scheduling calendar collection, or does not
support changing the default calendar, or does not support a
default calendar.
COPY/MOVE behavior: This property is only defined on a scheduling
Inbox collection which cannot be moved or copied.
Description: This property MAY be defined on a scheduling Inbox
collection. If present, it contains zero or one DAV:href XML
elements. When a DAV:href element is present, its value indicates
a URL to a scheduling calendar collection that is used as the
default calendar. When no DAV:href element is present, it
indicates that there is no default calendar. In the absence of
this property there is no default calendar.
Definition:
<!ELEMENT schedule-default-calendar-URL (DAV:href?) >
Example:
<C:schedule-default-calendar-URL xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>/calendars/users/cdaboo/calendar/</D:href>
</C:schedule-default-calendar-URL>
6.3. CALDAV:schedule-state Property
Name: schedule-state
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Indicates whether a scheduling message in a scheduling
Inbox collection has been processed as part of an automatic
scheduling transaction.
Daboo & Desruisseaux Expires March 23, 2009 [Page 30]
Internet-Draft CalDAV Schedule September 2008
Protected: This property MUST be protected as only the server can
carry out automatic processing of scheduling messages.
COPY/MOVE behavior: This property is only defined on a scheduling
message in a scheduling Inbox collection. If a scheduling message
is copied or moved into a scheduling Inbox collection, this
property MUST NOT be set.
Description: This property MAY be defined on a scheduling resource
in a scheduling Inbox collection. If present, it contains one of
two XML elements. When the CALDAV:schedule-unprocessed XML
element is used, it indicates that the scheduling message has not
been automatically processed by the server, and thus needs action
on the part of the client. When the CALDAV:schedule-processed XML
element is used, it indicates that automatic processing of the
scheduling message has taken place, so no scheduling operations
are needed by the client.
Definition:
<!ELEMENT schedule-state (schedule-processed|schedule-unprocessed) >
<!ELEMENT schedule-processed EMPTY>
<!-- Scheduling message has been automatically processed -->
<!ELEMENT schedule-unprocessed EMPTY>
<!-- Scheduling message has not been automatically processed -->
Example:
<C:schedule-state xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:schedule-processed/>
</C:schedule-state>
7. New Preconditions
7.1. Additional Preconditions for PUT, COPY and MOVE
This specification requires additional Preconditions for the PUT,
COPY and MOVE methods. The preconditions are:
(CALDAV:unique-scheduling-object-resource): Only one scheduling
object with a particular iCalendar property "UID" value MUST exist
in the system for each "Organizer" and each "Attendee".
(CALDAV:same-organizer-in-all-components): All the calendar
components in a scheduling object resource being stored in a
scheduling calendar collection MUST contain the same "ORGANIZER"
Daboo & Desruisseaux Expires March 23, 2009 [Page 31]
Internet-Draft CalDAV Schedule September 2008
property value if the "ORGANIZER" property is present.
7.2. Additional Preconditions for PUT
This specification requires additional Preconditions for the PUT
method. The preconditions are:
(CALDAV:allowed-organizer-scheduling-object-change): The following
restrictions exist for the "PARTSTAT" property value in scheduling
object resources created or modified by an "Organizer":
1. when creating a scheduling object resource the "Organizer"
MUST NOT set the "PARTSTAT" iCalendar parameter value to
anything other than "NEEDS-ACTION" if the corresponding
"ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar
parameter with its value set to "SERVER".
2. when modifying a scheduling object resource the "Organizer"
MUST NOT change the "PARTSTAT" iCalendar parameter value to
anything other than "NEEDS-ACTION" if the corresponding
"ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar
parameter with its value set to "SERVER".
(CALDAV:allowed-attendee-scheduling-object-change): When creating
or modifying a scheduling object resource in a scheduling calendar
collection, the "Attendee" can only make the following changes:
1. any iCalendar parameter on any "ATTENDEE" property whose value
corresponds to the calendar user address of the "Attendee"
2. add, change or remove a "TRANSP" property in any component
3. add, change or remove a "COMMENT" property in any component
4. add, change or remove a "PERCENT-COMPLETE" property in any
component
5. add, change or remove the "PRODID" property in the top-level
"VCALENDAR" component
6. add, change or remove the "CALSCALE" property in the top-level
"VCALENDAR" component
7. add, change or remove any "VALARM" components
8. create overridden recurring instances with only changes as
detailed above
Daboo & Desruisseaux Expires March 23, 2009 [Page 32]
Internet-Draft CalDAV Schedule September 2008
The "Attendee" MUST NOT make any other type of change.
7.3. Additional Precondition for PROPPATCH
This specification requires an additional Precondition for the
property response elements in PROPPATCH method response. The
precondition is:
(CALDAV:valid-schedule-default-calendar-URL): When the server
allows the client to change the CALDAV:schedule-default-calendar-
URL property on a scheduling Inbox collection, the URL specified
in any DAV:href element MUST reference a scheduling calendar
collection owned by the owner of the scheduling Inbox collection.
8. Scheduling
8.1. POST Method
The POST method submits a scheduling or freebusy message to one or
more recipients by targeting the request at the URI of a scheduling
Outbox collection. The request body of a POST method MUST contain a
scheduling message or freebusy message (e.g., an iCalendar object
that follows the iTIP semantic). The resource identified by the
Request-URI MUST be a resource collection of type CALDAV:schedule-
outbox (Section 3.1.2).
Only specific types of scheduling message are allowed in a POST
request on a scheduling Outbox collection:
+----------------+---------------------------------+
| iTIP METHOD | COMPONENT |
+----------------+---------------------------------+
| PUBLISH | None |
| REQUEST | VFREEBUSY |
| REPLY | None |
| ADD | None |
| CANCEL | None |
| REFRESH | Any except VTIMEZONE, VFREEBUSY |
| COUNTER | None |
| DECLINECOUNTER | None |
+----------------+---------------------------------+
Servers SHOULD reject any scheduling message that is not allowed.
However, for backwards compatibility with earlier version of this
specification, servers MAY return a valid schedule response result
indicating success for the iTIP operation being executed.
Preconditions:
Daboo & Desruisseaux Expires March 23, 2009 [Page 33]
Internet-Draft CalDAV Schedule September 2008
(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 (e.g., "text/
calendar") for scheduling or freebusy messages;
(CALDAV:valid-calendar-data): The resource submitted in the POST
request MUST be valid data for the media type being specified
(e.g., valid iCalendar object);
(CALDAV:valid-scheduling-message): The resource submitted in the
POST request MUST obey all restrictions specified for the POST
request (e.g., the scheduling message follows the restrictions of
iTIP);
(CALDAV:originator-allowed): The currently authenticated user MUST
be granted the CALDAV:schedule-deliver privilege or a suitable
sub-privilege on the scheduling Outbox collection being targeted
by the request;
(CALDAV:organizer-allowed): The calendar user identified by the
"ORGANIZER" property in the POST request's scheduling message MUST
be the calendar user (or one of the calendar users) associated
with the scheduling Outbox collection being targeted by the
request when the scheduling message is an outgoing scheduling
message;
(CALDAV:max-resource-size): The resource submitted in the POST
request MUST have an octet size less than or equal to the value of
the CALDAV:max-resource-size property value [RFC4791]on the
scheduling Outbox collection targeted by the request;
(CALDAV:attachments-allowed): The resource submitted in the POST
request MUST NOT contain any inline ATTACH properties;
Postconditions: None
8.1.1. Handling a REFRESH
When an iTIP REFRESH scheduling message is executed, the server
delivers the scheduling message to the calendar user specified by the
"ORGANIZER" property value in the scheduling object resource that was
POST'ed.
Daboo & Desruisseaux Expires March 23, 2009 [Page 34]
Internet-Draft CalDAV Schedule September 2008
8.1.2. Response to a POST request
A POST request may deliver a scheduling message to one or more
calendar user recipients. Since the behavior of each recipient may
vary, it is useful to get response status information for each
recipient in the overall POST response. This specification defines a
new XML response to convey multiple recipient status.
A response to a POST method that indicates status for one or more
recipients MUST be a CALDAV:schedule-response XML element. This MUST
contain one or more CALDAV:response elements for each recipient, with
each of those containing elements that indicate which recipient they
correspond to, the scheduling status of the request for that
recipient, any error codes and an optional description. See
Section 11.1.
In the case of a freebusy request, the CALDAV:response elements can
also contain CALDAV:calendar-data elements which contain freebusy
information (e.g., an iCalendar VFREEBUSY component) indicating the
busy state of the corresponding recipient, assuming that the freebusy
request for that recipient succeeded.
8.1.3. Status Codes for use with the POST method
The following are examples of response codes one would expect to be
used for this method. Note, however, that unless explicitly
prohibited any 2/3/4/5xx series response code may be used in a
response.
200 (OK) - The command succeeded.
201 (Created) - The command succeeded and a new resource was
created in the scheduling Outbox collection.
400 (Bad Request) - The client has provided an invalid scheduling
message.
403 (Forbidden) - The client cannot submit a scheduling message to
the specified Request-URI.
404 (Not Found) - The URL in the Request-URI was not present.
423 (Locked) - The specified resource is locked and the client
either is not a lock owner or the lock type requires a lock token
to be submitted and the client did not submit it.
507 (Insufficient Storage) - The server did not have sufficient
space to record the scheduling message in a scheduling Outbox
Daboo & Desruisseaux Expires March 23, 2009 [Page 35]
Internet-Draft CalDAV Schedule September 2008
collection being targeted by the POST request.
8.1.4. Example - Simple meeting invitation refresh
>> Request <<
POST /bernard/calendar/outbox/ HTTP/1.1
Host: cal.example.com
Content-Type: text/calendar
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REFRESH
BEGIN:VEVENT
UID:43777-876@example.com
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
uisseaux:mailto:bernard@example.com
END:VEVENT
END:VCALENDAR
>> Response <<
HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<C:schedule-response xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:response>
<C:recipient>mailto:lisa@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
"REFRESH" scheduling message to the "Organizer" of the meeting
mailto:lisa@example.com. The response indicates that delivery to the
relevant scheduling Inbox collection of the "Organizer" was
accomplished successfully.
Daboo & Desruisseaux Expires March 23, 2009 [Page 36]
Internet-Draft CalDAV Schedule September 2008
8.1.5. Example - Freebusy lookup
>> Request <<
POST /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com
Content-Type: text/calendar
Content-Length: xxxx
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REQUEST
BEGIN:VFREEBUSY
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
DTSTART:20040902T000000Z
DTEND:20040903T000000Z
UID:34222-232@example.com
ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
example.com
ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com
END:VFREEBUSY
END:VCALENDAR
>> Response <<
HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<C:schedule-response xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:response>
<C:recipient>mailto:bernard@example.com</C:recipient>
<C:request-status>2.0;Success</C:request-status>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REPLY
BEGIN:VFREEBUSY
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
DTSTART:20040902T000000Z
DTEND:20040903T000000Z
UID:34222-232@example.com
Daboo & Desruisseaux Expires March 23, 2009 [Page 37]
Internet-Draft CalDAV Schedule September 2008
ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
example.com
FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
20040902T090000Z,20040902T170000Z/20040903T000000Z
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
</C:response>
<C:response>
<C:recipient>mailto:cyrus@example.com</C:recipient>
<C:request-status>2.0;Success</C:request-status>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REPLY
BEGIN:VFREEBUSY
DTSTAMP:20040901T200200Z
ORGANIZER:mailto:lisa@example.com
DTSTART:20040902T000000Z
DTEND:20040903T000000Z
UID:34222-232@example.com
ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com
FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
20040902T090000Z,20040902T170000Z/20040903T000000Z
FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
</C:response>
</C:schedule-response>
In this example, the client requests the server to determine the busy
information of the calendar users mailto:bernard@example.com and
mailto:cyrus@example.com, over the time range specified by the
scheduling message sent in the request. The response includes
"VFREEBUSY" components for each of those calendar users with their
busy time indicated.
8.2. Retrieving incoming scheduling messages
Incoming scheduling messages will be stored in a scheduling Inbox
collection. As per Section 10, CalDAV "calendar-access" reports work
on scheduling collections, so the client can use those to get partial
information on scheduling messages in the scheduling Inbox
collection.
Daboo & Desruisseaux Expires March 23, 2009 [Page 38]
Internet-Draft CalDAV Schedule September 2008
9. Scheduling Access Control
9.1. Scheduling Privileges
CalDAV servers MUST support and adhere to the requirements of WebDAV
ACL [RFC3744]. Furthermore, CalDAV servers that advertise support
for the "calendar-auto-schedule" feature MUST also support the
scheduling privileges defined in this section.
All the scheduling privileges MUST be non-abstract and MUST appear in
the DAV:supported-privilege-set property of scheduling Outbox and
Inbox collections on which they are defined.
The tables specified in Appendix A clarifies which scheduling methods
(e.g., "REQUEST" "REPLY" etc.) are controlled by each scheduling
privilege defined in this section.
9.1.1. Privileges on Scheduling Inbox Collections
This section defines new WebDAV ACL privileges that are for use on
scheduling Inbox collections. These privileges determine whether a
calendar user is allowed to have scheduling messages delivered to the
calendar user who "owns" the scheduling Inbox collection. This
allows calendar users to choose which other calendar users can
schedule with them.
The privileges defined in this section are ignored if applied to a
resource other than a scheduling Inbox collection.
9.1.1.1. CALDAV:schedule-deliver Privilege
CALDAV:schedule-deliver is an aggregate privilege that contains all
the scheduling privileges that control the processing and delivery of
incoming scheduling messages, that is, CALDAV:schedule-deliver-invite
and CALDAV:schedule-deliver-reply, as well as freebusy requests
targeted at the owner of the scheduling Inbox collection, that is,
CALDAV:schedule-query-freebusy.
<!ELEMENT schedule-deliver EMPTY >
9.1.1.2. CALDAV:schedule-deliver-invite Privilege
The CALDAV:schedule-deliver-invite privilege controls the processing
and delivery of scheduling messages coming from an "Organizer".
<!ELEMENT schedule-deliver-invite EMPTY >
Daboo & Desruisseaux Expires March 23, 2009 [Page 39]
Internet-Draft CalDAV Schedule September 2008
9.1.1.3. CALDAV:schedule-deliver-reply Privilege
The CALDAV:schedule-deliver-reply privilege controls the processing
and delivery of scheduling messages coming from an "Attendee".
<!ELEMENT schedule-deliver-reply EMPTY >
9.1.1.4. CALDAV:schedule-query-freebusy Privilege
The CALDAV:schedule-query-freebusy privilege controls freebusy
requests targeted at the owner of the scheduling Inbox collection.
<!ELEMENT schedule-query-freebusy EMPTY >
9.1.2. Privileges on Scheduling Outbox Collections
This section defines new WebDAV ACL privileges that are defined for
use on scheduling Outbox collections. These privileges determine
which calendar users are allowed to send scheduling messages on
behalf of the calendar user who "owns" the scheduling Outbox
collection. This allows calendar users to choose other calendar
users who can act on their behalf to schedule with other calendar
users (e.g., assistants working on behalf of their boss).
The privileges defined in this section are ignored if applied to a
resource other than a scheduling Outbox collection.
9.1.2.1. CALDAV:schedule-send Privilege
CALDAV:schedule-send is an aggregate privilege that contains all the
scheduling privileges that control the use of methods that will cause
scheduling messages to be delivered to other users, that is, CALDAV-
schedule-send-invite and CALDAV-schedule-send-reply, as well as
freebusy requests to be targeted at other users, that is, CALDAV-
schedule-send-freebusy.
<!ELEMENT schedule-send EMPTY >
9.1.2.2. CALDAV:schedule-send-invite Privilege
The CALDAV:schedule-send-invite privilege controls the sending of
scheduling messages by "Organizers".
Users granted the DAV:bind privilege on a scheduling calendar
collection, or DAV:write privilege on scheduling object resources,
will also need the CALDAV:schedule-send-invite privilege granted on
the scheduling Outbox collection of the owner of the scheduling
calendar collection or scheduling object resource in order to be
Daboo & Desruisseaux Expires March 23, 2009 [Page 40]
Internet-Draft CalDAV Schedule September 2008
allowed to create, modify or delete scheduling object resources in a
way that will trigger the CalDAV server to deliver organizer
scheduling messages to other calendar users.
<!ELEMENT schedule-send-invite EMPTY >
9.1.2.3. CALDAV:schedule-send-reply Privilege
The CALDAV:schedule-send-invite privilege controls the sending of
scheduling messages by "Attendees".
Users granted the DAV:bind privilege on a scheduling calendar
collection, or DAV:write privilege on scheduling object resources,
will also need the CALDAV:schedule-send-reply privilege granted on
the scheduling Outbox collection of the owner of the scheduling
calendar collection or scheduling object resource in order to be
allowed to create, modify or delete scheduling object resources in a
way that will trigger the CalDAV server to deliver attendee
scheduling messages to other calendar users.
<!ELEMENT schedule-send-reply EMPTY >
9.1.2.4. CALDAV:schedule-send-freebusy Privilege
The CALDAV:schedule-send-freebusy privilege controls the use of the
POST method to submit scheduling messages that specify the scheduling
method "REQUEST" with a "VFREEBUSY" calendar component.
<!ELEMENT schedule-send-freebusy EMPTY >
9.1.3. Aggregation of Scheduling Privileges
Server implementations MUST aggregate the scheduling privileges as
follows:
DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule-
deliver;
CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite,
CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy;
CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver-
invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query-
freebusy.
The following diagram illustrates how scheduling privileges are
aggregated according to the above requirements.
Daboo & Desruisseaux Expires March 23, 2009 [Page 41]
Internet-Draft CalDAV Schedule September 2008
[DAV:all] (aggregate)
|
+-- [CALDAV:schedule-deliver] (aggregate)
| |
| +-- [CALDAV:schedule-deliver-invite]
| +-- [CALDAV:schedule-deliver-reply]
| +-- [CALDAV:schedule-query-freebusy]
|
+-- [CALDAV:schedule-send] (aggregate)
|
+-- [CALDAV:schedule-send-invite]
+-- [CALDAV:schedule-send-reply]
+-- [CALDAV:schedule-send-freebusy]
9.2. Additional Principal Properties
This section defines new properties for WebDAV principal resources as
defined in RFC3744 [RFC3744]. These properties are likely to be
protected but the server MAY allow them to be written by appropriate
users.
9.2.1. CALDAV:schedule-inbox-URL Property
Name: schedule-inbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URL of the scheduling Inbox collection owned
by the associated principal resource.
Conformance: This property MAY be protected and SHOULD NOT be
returned by a PROPFIND allprop request (as defined in Section 14.2
of WebDAV [RFC4918]).
Description: This property is needed for a client to determine where
the scheduling Inbox collection of the current user is located so
that processing of scheduling messages can occur.
Definition:
<!ELEMENT schedule-inbox-URL (DAV:href)>
9.2.2. CALDAV:schedule-outbox-URL Property
Daboo & Desruisseaux Expires March 23, 2009 [Page 42]
Internet-Draft CalDAV Schedule September 2008
Name: schedule-outbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URL of the scheduling Outbox collection owned
by the associated principal resource.
Conformance: This property MAY be protected and SHOULD NOT be
returned by a PROPFIND allprop request (as defined in Section 14.2
of WebDAV [RFC4918]).
Description: This property is needed for a client to determine where
the scheduling Outbox collection of the current user is located so
that sending of scheduling messages can occur.
Definition:
<!ELEMENT schedule-outbox-URL DAV:href>
9.2.3. CALDAV:calendar-user-address-set Property
Name: calendar-user-address-set
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the calendar addresses of the associated principal
resource.
Conformance: This property MAY be protected and SHOULD NOT be
returned by a PROPFIND allprop request (as defined in Section 14.2
of WebDAV [RFC4918]). Support for this property is REQUIRED.
This property SHOULD be searchable using the DAV:principal-
property-search REPORT. The DAV:principal-search-property-set
REPORT SHOULD identify this property as such.
Description: This property is needed to map calendar user addresses
in iCalendar data to principal resources and their associated
scheduling Inbox and Outbox collections. In the event that a user
has no well defined identifier for their calendar user address,
the URI of their principal resource can be used.
Definition:
<!ELEMENT calendar-user-address-set (DAV:href*)>
Daboo & Desruisseaux Expires March 23, 2009 [Page 43]
Internet-Draft CalDAV Schedule September 2008
Example:
<C:calendar-user-address-set xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>mailto:bernard@example.com</D:href>
<D:href>mailto:bernard.desruisseaux@example.com</D:href>
</C:calendar-user-address-set>
9.2.4. CALDAV:calendar-user-type Property
Name: calendar-user-type
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identifies the calendar user type of the associated
principal resource.
Conformance: This property MAY be protected and SHOULD NOT be
returned by a PROPFIND allprop request (as defined in Section 14.2
of WebDAV [RFC4918]). Support for this property is OPTIONAL.
This property SHOULD be searchable using the DAV:principal-
property-search REPORT. The DAV:principal-search-property-set
REPORT SHOULD identify this property as such.
Description: This property is used to indicate the type of calendar
user associated with the principal resource. Its value is the
same as the iCalendar "CUTYPE" property parameter that can be used
on "ATTENDEE" properties.
Definition:
<!ELEMENT calendar-user-type #PCDATA>
<!-- The supported values are those defined in iCalendar [RFC2445]
Section 4.2.3 for the "CUTYPE" -->
Example:
<C:calendar-user-type
xmlns:C="urn:ietf:params:xml:ns:caldav">INDIVIDUAL<
/C:calendar-user-type>
10. Reports
This specification extends the CALDAV:calendar-query and CALDAV:
calendar-multiget reports to return results for calendar object
resources in scheduling Inbox collections when the report directly
targets such a collection, i.e., the Request-URI for a REPORT MUST be
the URI of the scheduling Inbox collection or of a child resource
Daboo & Desruisseaux Expires March 23, 2009 [Page 44]
Internet-Draft CalDAV Schedule September 2008
within a scheduling Inbox collection. A report run on a regular
collection that includes a scheduling Inbox collection as a child
resource at any depth MUST NOT examine or return any calendar object
resources from within any scheduling Inbox collections.
When a CALDAV:calendar-query REPORT includes a time-range query and
targets a scheduling Inbox collection, if any calendar object
resources contain "VEVENT" calendar components that do not include a
"DTSTART" iCalendar property (as allowed by iTIP [RFC2446]) then such
components MUST always match the time-range query test.
Note that the CALDAV:free-busy-query report is NOT supported on
scheduling Inbox collections.
11. XML Element Definitions
11.1. CALDAV:schedule-response XML Element
Name: schedule-response
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Contains the set of responses for a POST method request.
Description: See Section 8.1.2.
Definition:
<!ELEMENT schedule-response (response*)>
11.2. CALDAV:response XML Element
Name: response
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Contains a single response for a POST method request.
Description: See Section 8.1.2.
Definition:
<!ELEMENT response (recipient,
request-status,
calendar-data?,
DAV:error?,
DAV:responsedescription?)>
Daboo & Desruisseaux Expires March 23, 2009 [Page 45]
Internet-Draft CalDAV Schedule September 2008
11.3. CALDAV:recipient XML Element
Name: recipient
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: The calendar user address (recipient header value) that the
enclosing response for a POST method request is for.
Description: See Section 8.1.2.
Definition:
<!ELEMENT recipient (DAV:href)>
11.4. CALDAV:request-status XML Element
Name: request-status
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: The iTIP "REQUEST-STATUS" property value for this response.
Description: See Section 8.1.2.
Definition:
<!ELEMENT request-status #PCDATA>
12. Security Considerations
The process of scheduling involves the sending and receiving of
scheduling messages. As a result, the security problems related to
messaging in general are relevant here. In particular the
authenticity of the scheduling messages needs to be verified
absolutely. Servers and clients MUST use an HTTP connection
protected with TLS as defined in [RFC2818] for all scheduling
transactions.
12.1. Verifying scheduling requests
When handling an implicit scheduling operation:
Servers MUST verify that the currently authenticated user has the
CALDAV:schedule-deliver privilege or a suitable sub-privilege on
the scheduling Outbox collection of the DAV:owner of the
scheduling calendar collection in which a scheduling object
resource is being manipulated.
Daboo & Desruisseaux Expires March 23, 2009 [Page 46]
Internet-Draft CalDAV Schedule September 2008
Servers MUST verify that the principal associated with the DAV:
owner of the scheduling calendar collection in which a scheduling
object resource is being manipulated contains a CALDAV:schedule-
outbox-URL property value.
Servers MUST only deliver scheduling messages to recipients when
the principal associated with the DAV:owner of the scheduling
calendar collection in which a scheduling object resource is being
manipulated has the CALDAV:schedule privilege or a suitable sub-
privilege on the scheduling Inbox collections for recipient.
To prevent impersonation of calendar users, the server MUST verify
that the "ORGANIZER" property in an organizer scheduling object
resource matches one of the calendar user addresses of the DAV:
owner of the schedule calendar collection in which the resource is
stored.
To prevent spoofing of an existing scheduling object resource,
servers MUST verify that the "UID" iCalendar property value in a
new scheduling object resource does not match that of an existing
scheduling object resource with a different "ORGANIZER" property
value.
When handling a POST request on a scheduling Outbox collection:
Servers MUST verify that the currently authenticated user has the
CALDAV:schedule-deliver privilege or a suitable sub-privilege on
the scheduling Outbox collection targeted by the request.
Servers MUST verify that the principal associated with the
calendar user address specified in the "ORGANIZER" property of the
scheduling message data in the request contains a CALDAV:schedule-
outbox-URL property value that matches the scheduling Outbox
collection targeted by the request.
Servers MUST verify that the principal associated with the
calendar user address specified in the "ORGANIZER" property of the
scheduling message data in the request has the CALDAV:schedule
privilege or a suitable sub-privilege on all of the scheduling
Inbox collections for those recipients to whom a scheduling
message is being delivered.
13. IANA Consideration
13.1. HTTP header registration
This specification registers one new header for use with HTTP as per
[RFC3864].
Daboo & Desruisseaux Expires March 23, 2009 [Page 47]
Internet-Draft CalDAV Schedule September 2008
13.1.1. Schedule-Reply Request Header Registration
Header field name: Schedule-Reply
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document(s): this specification
Related information: none
13.2. iCalendar Registrations
This specification registers two new iCalendar property parameters as
defined in Section 4.
14. Acknowledgements
The authors would like to thank the following individuals for
contributing their ideas and support for writing this specification:
Mike Douglass, Lisa Dusseault, Arnaud Quillaud, Julian F. Reschke,
Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim Whitehead.
The authors would also like to thank the Calendaring and Scheduling
Consortium for advice with this specification, and for organizing
interoperability testing events to help refine it.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[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.
Daboo & Desruisseaux Expires March 23, 2009 [Page 48]
Internet-Draft CalDAV Schedule September 2008
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk,
H., Masinter, L., Leach, P., and T. Berners-
Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
May 2000.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J.
Whitehead, "Web Distributed Authoring and
Versioning (WebDAV) Access Control Protocol",
RFC 3744, May 2004.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
"Registration Procedures for Message Header
Fields", BCP 90, RFC 3864, September 2004.
[RFC4791] Daboo, C., Desruisseaux, B., and L.
Dusseault, "Calendaring Extensions to WebDAV
(CalDAV)", RFC 4791, March 2007.
[RFC4918] Dusseault, L., "HTTP Extensions for Web
Distributed Authoring and Versioning
(WebDAV)", RFC 4918, June 2007.
[W3C.REC-xml-20060816] Paoli, J., Sperberg-McQueen, C., Bray, T.,
Yergeau, F., and E. Maler, "Extensible Markup
Language (XML) 1.0 (Fourth Edition)", World
Wide Web Consortium Recommendation REC-xml-
20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
15.2. Informative References
[RFC2447] Dawson, F., Mansour, S., and S. Silverberg,
"iCalendar Message-Based Interoperability
Protocol (iMIP)", RFC 2447, November 1998.
Appendix A. Scheduling Privileges Summary
A.1. Scheduling Inbox Privileges
The following tables specify which scheduling privileges grant the
right to a calendar user to deliver a scheduling message to the
scheduling Inbox collection of another calendar user. The
appropriate behavior depends on the calendar component type in the
scheduling message and the scheduling "METHOD" in use.
Daboo & Desruisseaux Expires March 23, 2009 [Page 49]
Internet-Draft CalDAV Schedule September 2008
+-----------------------+
| METHOD for VEVENT |
+---+---+---+---+---+---+
| P | R | R | A | C | R |
| U | E | E | D | A | E |
| B | Q | P | D | N | F |
| L | U | L | | C | R |
| I | E | Y | | E | E |
+----------------------------+| S | S | | | L | S |
| Scheduling Inbox Privilege || H | T | | | | H |
+============================++===+===+===+===+===+===+
| schedule-deliver || * | * | * | * | * | * |
| schedule-deliver-invite || * | * | | * | * | |
| schedule-deliver-reply || | | * | | | * |
| schedule-query-freebusy || | | | | | |
+----------------------------++---+---+---+---+---+---+
+-----------------------+
| METHOD for VTODO |
+---+---+---+---+---+---+
| P | R | R | A | C | R |
| U | E | E | D | A | E |
| B | Q | P | D | N | F |
| L | U | L | | C | R |
| I | E | Y | | E | E |
+----------------------------+| S | S | | | L | S |
| Scheduling Inbox Privilege || H | T | | | | H |
+============================++===+===+===+===+===+===+
| schedule-deliver || * | * | * | * | * | * |
| schedule-deliver-invite || * | * | | * | * | |
| schedule-deliver-reply || | | * | | | * |
| schedule-query-freebusy || | | | | | |
+----------------------------++---+---+---+---+---+---+
Daboo & Desruisseaux Expires March 23, 2009 [Page 50]
Internet-Draft CalDAV Schedule September 2008
+-----------------------+
| METHOD for VJOURNAL |
+-------+-------+-------+
| P | A | C |
| U | D | A |
| B | D | N |
| L | | C |
| I | | E |
+----------------------------+| S | | L |
| Scheduling Inbox Privilege || H | | |
+============================++=======+=======+=======+
| schedule-deliver || * | * | * |
| schedule-deliver-invite || * | * | * |
| schedule-deliver-reply || | | |
| schedule-query-freebusy || | | |
+----------------------------++-------+-------+-------+
+---------------+
| METHOD for |
| VFREEBUSY |
+-------+-------+
| P | R |
| U | E |
| B | Q |
| L | U |
| I | E |
+----------------------------+| S | S |
| Scheduling Inbox Privilege || H | T |
+============================++=======+=======+
| schedule-deliver || * | * |
| schedule-deliver-invite || * | |
| schedule-deliver-reply || | |
| schedule-query-freebusy || | * |
+----------------------------++-------+-------+
A.2. Scheduling Outbox Privileges
The following tables specify which scheduling privileges grant the
right to a calendar user to submit a scheduling message to another
calendar user, either as the result of an explicit scheduling request
or an automatic scheduling transaction. The appropriate behavior
depends on the calendar component type in the scheduling message and
the scheduling "METHOD" in use.
Daboo & Desruisseaux Expires March 23, 2009 [Page 51]
Internet-Draft CalDAV Schedule September 2008
+-------------------+
| METHOD for VEVENT |
+---+---+---+---+---+
| R | R | A | C | R |
| E | E | D | A | E |
| Q | P | D | N | F |
| U | L | | C | R |
| E | Y | | E | E |
+-----------------------------+| S | | | L | S |
| Scheduling Outbox Privilege || T | | | | H |
+=============================++===+===+===+===+===+
| schedule-send || * | * | * | * | * |
| schedule-send-invite || * | | * | * | |
| schedule-send-reply || | * | | | * |
| schedule-send-freebusy || | | | | |
+-----------------------------++---+---+---+---+---+
+-------------------+
| METHOD for VTODO |
+---+---+---+---+---+
| R | R | A | C | R |
| E | E | D | A | E |
| Q | P | D | N | F |
| U | L | | C | R |
| E | Y | | E | E |
+-----------------------------+| S | | | L | S |
| Scheduling Outbox Privilege || T | | | | H |
+=============================++===+===+===+===+===+
| schedule-send || * | * | * | * | * |
| schedule-send-invite || * | | * | * | |
| schedule-send-reply || | * | | | * |
| schedule-send-freebusy || | | | | |
+-----------------------------++---+---+---+---+---+
Daboo & Desruisseaux Expires March 23, 2009 [Page 52]
Internet-Draft CalDAV Schedule September 2008
+-----------------------+
| METHOD for VJOURNAL |
+-------+-------+-------+
| P | A | C |
| U | D | A |
| B | D | N |
| L | | C |
| I | | E |
+-----------------------------+| S | | L |
| Scheduling Outbox Privilege || H | | |
+=============================++=======+=======+=======+
| schedule-send || * | * | * |
| schedule-send-invite || * | * | * |
| schedule-send-reply || | | |
| schedule-send-freebusy || | | |
+-----------------------------++-------+-------+-------+
+---------------+
| METHOD for |
| VFREEBUSY |
+-------+-------+
| P | R |
| U | E |
| B | Q |
| L | U |
| I | E |
+-----------------------------+| S | S |
| Scheduling Outbox Privilege || H | T |
+=============================++=======+=======+
| schedule-send || * | * |
| schedule-send-invite || * | |
| schedule-send-reply || | |
| schedule-send-freebusy || | * |
+-----------------------------++-------+-------+
Appendix B. Example Workflows
Appendix C. Changes (to be removed prior to publication as an RFC)
C.1. Changes in -05
This draft has changed substantially since the -04 version. The
primary reason for this change was implementation experience from a
number of vendors who implemented products based on the earlier
drafts. Experience showed that the client/server interaction was not
reliable in keeping scheduling messages synchronized between
organizer and attendees. In addition the latency in updates due to
Daboo & Desruisseaux Expires March 23, 2009 [Page 53]
Internet-Draft CalDAV Schedule September 2008
clients being offline proved unacceptable to users. These issues led
to the redesign of this specification to support a server-based
processing model that eliminates all the problems seen previously.
Whilst this adds significant complexity to the server in that it
needs to be a full blown iTIP processing agent, it does remove a lot
of the same complexity from clients, opening up the possibility of
supporting complex scheduling behaviors even with "thin" clients.
In the judgement of the authors, we consider this new specification
to be a substantial improvement over the old one and believe it
represents a stronger protocol that will lead to better
interoperability.
Authors' Addresses
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/
Bernard Desruisseaux
Oracle Corporation
600 Blvd. de Maisonneuve West
Suite 1900
Montreal, QC H3A 3J2
CANADA
EMail: bernard.desruisseaux@oracle.com
URI: http://www.oracle.com/
Daboo & Desruisseaux Expires March 23, 2009 [Page 54]
Internet-Draft CalDAV Schedule September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Daboo & Desruisseaux Expires March 23, 2009 [Page 55]
