[CalendarServer-changes] [3046] CalendarServer/trunk/doc/RFC/draft-desruisseaux-caldav-sched.txt
source_changes at macosforge.org
source_changes at macosforge.org
Wed Sep 24 12:10:38 PDT 2008
Revision: 3046
http://trac.macosforge.org/projects/calendarserver/changeset/3046
Author: wsanchez at apple.com
Date: 2008-09-24 12:10:38 -0700 (Wed, 24 Sep 2008)
Log Message:
-----------
Update to -05
Modified Paths:
--------------
CalendarServer/trunk/doc/RFC/draft-desruisseaux-caldav-sched.txt
Modified: CalendarServer/trunk/doc/RFC/draft-desruisseaux-caldav-sched.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-desruisseaux-caldav-sched.txt 2008-09-24 17:42:42 UTC (rev 3045)
+++ CalendarServer/trunk/doc/RFC/draft-desruisseaux-caldav-sched.txt 2008-09-24 19:10:38 UTC (rev 3046)
@@ -1,2408 +1,3080 @@
-
-
-
-Network Working Group C. Daboo
-Internet-Draft Apple
-Intended status: Standards Track B. Desruisseaux
-Expires: July 30, 2007 Oracle
- L. Dusseault
- CommerceNet
- January 26, 2007
-
-
- Scheduling Extensions to CalDAV
- draft-desruisseaux-caldav-sched-03
-
-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 July 30, 2007.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2007).
-
-Abstract
-
- This document defines extensions to the Web Distributed Authoring and
- Versioning (WebDAV) protocol to specify a standard way of exchanging
- and processing scheduling messages based on the iCalendar Transport-
- Independent Interoperability Protocol (iTIP). This document defines
- the "calendar-schedule" feature of CalDAV.
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 1]
-
-Internet-Draft CalDAV January 2007
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4
- 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
- 2. Required Scheduling features . . . . . . . . . . . . . . . . . 5
- 3. CalDAV Scheduling Support Discovery . . . . . . . . . . . . . 6
- 3.1. Example: Using OPTIONS for the Discovery of Support
- for CalDAV . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 6
- 4.1. Scheduling Collections . . . . . . . . . . . . . . . . . . 7
- 4.2. Scheduling Transactions . . . . . . . . . . . . . . . . . 8
- 5. New Resource Types and Properties . . . . . . . . . . . . . . 9
- 5.1. Scheduling Inbox Collection . . . . . . . . . . . . . . . 9
- 5.2. Scheduling Outbox Collection . . . . . . . . . . . . . . . 10
- 5.3. Scheduling Inbox Properties . . . . . . . . . . . . . . . 11
- 5.3.1. CALDAV:calendar-free-busy-set Property . . . . . . . . 11
- 5.4. Calendar Object Resource Properties . . . . . . . . . . . 12
- 5.4.1. CALDAV:originator Property . . . . . . . . . . . . . . 12
- 5.4.2. CALDAV:recipient Property . . . . . . . . . . . . . . 13
- 6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.1.1. Originator request header . . . . . . . . . . . . . . 15
- 6.1.2. ORGANIZER Property . . . . . . . . . . . . . . . . . . 15
- 6.1.3. Recipient request header . . . . . . . . . . . . . . . 15
- 6.1.4. Response to a POST request . . . . . . . . . . . . . . 16
- 6.1.5. Status Codes for use with the POST method . . . . . . 17
- 6.1.6. Example - Simple meeting invitation . . . . . . . . . 18
- 6.1.7. Example - Free-Busy lookup . . . . . . . . . . . . . . 20
- 6.2. Retrieving incoming scheduling messages . . . . . . . . . 22
- 6.2.1. Example - Retrieve incoming scheduling message . . . . 22
- 6.3. Acting on incoming scheduling messages . . . . . . . . . . 23
- 7. HTTP Request Headers for CalDAV . . . . . . . . . . . . . . . 24
- 7.1. Originator Request Header . . . . . . . . . . . . . . . . 24
- 7.2. Recipient Request Header . . . . . . . . . . . . . . . . . 24
- 8. Scheduling Access Control . . . . . . . . . . . . . . . . . . 24
- 8.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 24
- 8.1.1. CALDAV:schedule-request Privilege . . . . . . . . . . 25
- 8.1.2. CALDAV:schedule-reply Privilege . . . . . . . . . . . 27
- 8.1.3. CALDAV:schedule-free-busy Privilege . . . . . . . . . 29
- 8.1.4. CALDAV:schedule Privilege . . . . . . . . . . . . . . 31
- 8.1.5. Privilege aggregation and the
- DAV:supported-privilege-set property . . . . . . . . . 32
- 8.2. Additional Principal Properties . . . . . . . . . . . . . 32
- 8.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 32
- 8.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 33
- 8.2.3. CALDAV:calendar-user-address-set Property . . . . . . 33
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 2]
-
-Internet-Draft CalDAV January 2007
-
-
- 8.2.4. Example: Searching for calendars belonging to a
- user based on a calendar user address . . . . . . . . 34
- 8.2.5. Example: Finding the scheduling Inbox and Outbox
- belonging to the currently authenticated user . . . . 36
- 9. Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
- 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36
- 10.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 36
- 10.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 37
- 10.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 37
- 10.4. CALDAV:request-status XML Element . . . . . . . . . . . . 37
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
- 11.1. Verifying scheduling requests . . . . . . . . . . . . . . 38
- 12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 39
- 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
- 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
- 14.1. Normative References . . . . . . . . . . . . . . . . . . . 39
- 14.2. Informative References . . . . . . . . . . . . . . . . . . 40
- Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 40
- A.1. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 40
- A.2. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 41
- A.3. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 41
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 3]
-
-Internet-Draft CalDAV January 2007
-
-
-1. Introduction
-
- This document specifies a set of headers, properties and privileges
- that define the CalDAV [I-D.dusseault-caldav] scheduling extensions
- to the WebDAV [RFC2518] protocol. This document also provides the
- transport specific information necessary to convey iCalendar
- [RFC2445] Transport-independent Interoperability Protocol iTIP
- [RFC2446] over WebDAV which enables transactions such as publish,
- schedule, reschedule, respond to scheduling requests, negotiation of
- changes or cancel iCalendar-based calendar components, as well as
- search for available busy time information.
-
- Discussion of this Internet-Draft is taking place on the mailing list
- <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
-
-1.1. XML Namespaces
-
- Definitions of XML elements in this document use XML element type
- declarations (as found in XML Document Type Declarations), described
- in Section 3.2 of [W3C.REC-xml-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
- [I-D.dusseault-caldav].
-
- Also note that some CalDAV XML element names are identical to WebDAV
- XML element names, though their namespace differs. Care MUST be
- taken not to confuse the two sets of names.
-
-1.2. Notational Conventions
-
- The augmented BNF used by this document to describe protocol elements
- is described in Section 2.1 of [RFC2616]. Because this augmented BNF
- uses the basic production rules provided in Section 2.2 of [RFC2616],
- those rules apply to this document as well.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 4]
-
-Internet-Draft CalDAV January 2007
-
-
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:caldav" are referenced in this document
- outside of the context of an XML fragment, the string "DAV:" and
- "CALDAV:" will be prefixed to the element types respectively.
-
-1.3. Terminology
-
- Scheduling message: A message that describes a transaction such as
- publish, schedule, reschedule, respond to scheduling requests,
- negotiation of changes or cancel calendar components.
-
- Free busy message: A message that describes a transaction such as
- publish unsolicited busy time information, request busy time
- information, or respond to a busy time request.
-
-2. Required Scheduling features
-
- This section lists what functionality is required of a CalDAV
- scheduling server. To advertise support for this specification a
- server:
-
- o MUST support iCalendar [RFC2445] as a media type for calendar
- object resource format;
-
- o MUST support iTIP [RFC2446].
-
- o MUST support WebDAV Class 1 & Class 2 [RFC2518] (note that
- [I-D.ietf-webdav-rfc2518bis] describes clarifications to [RFC2518]
- that aid interoperability);
-
- o MUST support WebDAV ACL [RFC3744] with the additional privilege
- defined in Section 8.1 of this document;
-
- o MUST support transport over TLS [RFC2246] as defined in [RFC2818]
- (note that [RFC2246] has been obsoleted by [RFC4346]);
-
- o MUST support ETags [RFC2616];
-
- o MUST support the CALDAV:schedule privilege and its sub-privileges.
-
- o MUST support the CALDAV:schedule-inbox and CALDAV:schedule-outbox
- collection resource types.
-
- o MUST support the POST method with the Recipient and Originator
- request headers targeted at a CALDAV:schedule-outbox collection
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 5]
-
-Internet-Draft CalDAV January 2007
-
-
- resource types.
-
- A CalDAV scheduling server MAY also support the CalDAV calendar-
- access feature [I-D.dusseault-caldav], and that adds the following
- requirements:
-
- MUST support the CALDAV:calendar-query and CALDAV:multiget REPORTs
- on CALDAV:schedule-inbox and CALDAV:schedule-outbox collection
- resource types.
-
-3. CalDAV Scheduling Support Discovery
-
- If the server supports the calendar scheduling features described in
- this document it MUST include "calendar-schedule" as a field in the
- DAV response header from an OPTIONS request on any resource that
- supports any scheduling properties, privileges or methods.
-
-3.1. Example: Using OPTIONS for the Discovery of Support for CalDAV
-
- >> Request <<
-
- OPTIONS /lisa/calendar/outbox/ HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
- Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
- DAV: 1, 2, access-control, calendar-access, calendar-schedule
- Content-Length: 0
-
- In this example, the OPTIONS response indicates that the server
- supports both the calendar-access and calendar-schedule features and
- that /lisa/calendar/outbox/ can be specified as a Request-URI to the
- POST method.
-
-4. Scheduling Process
-
- The process of scheduling a meeting between different parties often
- involves a series of steps with different "actors" playing particular
- roles during the whole process. Typically there is a meeting
- "Organizer" whose role is to setup a meeting between one or more
- meeting "Attendees", and this is done by sending out invitations and
- handling responses from each Attendee.
-
- This process can typically be broken down into two phases.
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 6]
-
-Internet-Draft CalDAV January 2007
-
-
- In the first phase the "Organizer" tries to determine a time for the
- meeting that ought to be the most acceptable to each "Attendee".
- This involves finding out when each Attendee is available during the
- period of time in which the meeting needs to occur (or simply finding
- a suitable time for all attendees to come together for the meeting),
- and determining when the most appropriate time is for which each
- Attendee is free. This process is called a "free-busy" lookup.
-
- In the second phase the "Organizer" sends out invitations to each
- "Attendee" using the time determined from the free-busy lookup - or a
- suitable guess as to an appropriate time based on other factors if
- free-busy lookup is not feasible. There then follows a process of
- negotiation between "Organizer" and "Attendees" regarding the
- invitation. Some "Attendees" may choose to attend at the original
- time provided by the "Organizer", others may decline to attend at
- that time, but suggest another time, others may decline to attend at
- any time. The "Organizer" needs to process each of the replies from
- the "Attendees" and take appropriate action to confirm the meeting,
- reschedule it or perhaps cancel it depending on those replies.
-
- The user "expectation" as to how a calendaring and scheduling system
- should respond in each of these two phases is somewhat different. In
- the case of a free-busy lookup, users expect to get back results
- immediately so that they can then move on to the invitation phase as
- quickly as possible. In the case of invitations, its expected that
- each "Attendee" will reply in his or her own time, so delays in
- receiving replies are anticipated. Thus calendaring and scheduling
- systems should treat these two operational phases in different ways
- to accommodate the user expectations, and this specification does
- that.
-
-4.1. Scheduling Collections
-
- It is useful for each participant in a scheduling transaction to
- maintain their own "history" of invitations sent and received during
- the process and after to keep track of what was done, and to properly
- handle updates to invitations as they may change over time. This
- history is usually kept separate from the actual "booked" event,
- to-do, or daily journal entry, which would normally be placed in a
- user's calendar collection.
-
- In addition, it is useful to keep outgoing invitations separate from
- incoming ones for organizational purposes.
-
- Also, a calendar user may have multiple calendars representing
- different spheres of activity, but scheduling requests are targeted
- at calendar user addresses, and there is no formal way to have those
- indicate which sphere of activity they might apply to. By storing
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 7]
-
-Internet-Draft CalDAV January 2007
-
-
- all incoming scheduling requests in a separate collection, clients
- can process the requests in that collection and choose what calendar
- the request belongs to and make its own arrangements to place the
- relevant calendar object in that calendar to "book" it.
-
- This specification introduces two new collection resource types that
- are used for keeping incoming and outgoing scheduling messages
- separate from other calendar object resources. These can also be
- used to control who is able to send scheduling messages on behalf of
- a user, and who is allowed to send scheduling messages to other users
- by the use of new WebDAV ACL [RFC3744] privileges. Note that these
- collections only contains scheduling messages that pertains to the
- scheduling of events, to-dos and daily journal entries. Scheduling
- messages that describes requests for available busy time information,
- or replies to such request, are not contained in these collections.
-
- The scheduling "Inbox" collection contains received scheduling
- messages. Scheduling messages are contained in calendar object
- resources. Each calendar object resource has a WebDAV property that
- indicates whether the scheduling message has already been processed
- or not so that multiple clients do not repeat the processing actions
- already done.
-
- The scheduling "Outbox" collection contains scheduling message that
- have been sent, which need to be tracked both to help synchronize
- between multiple clients and to support delegation use cases. A
- single user with multiple clients can use this collection to
- synchronize the outbound request history. Two users coordinating
- scheduling with one calendar (e.g., a calendar user and her
- assistant) can see what scheduling messages the other user has sent.
- The calendar owner would then typically have permission to DELETE the
- scheduling messages but the assistant might not.
-
-4.2. Scheduling Transactions
-
- The iCalendar Transport-independent Interoperability Protocol (iTIP)
- [RFC2446] outlines a model for scheduling and free-busy message
- exchanges to perform scheduling transactions. This specification
- makes use of scheduling free-busy messages to handle scheduling
- transactions on the server by having such messages passed between
- different users on the server depending on their role in the
- scheduling process.
-
- To that end each scheduling message is modeled as a calendar object
- resource which contains the iCalendar object that conforms to the
- iTIP requirements for the type of transaction being requested.
-
- This specification defines the POST method, acting on an Organizer's
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 8]
-
-Internet-Draft CalDAV January 2007
-
-
- scheduling Outbox, to trigger schedule processing by the server.
- This can take one of two forms: for free-busy messages the POST
- request returns immediately with free busy results; for scheduling
- messages, a copy of the scheduling message specified in the request
- body is deposited into each recipient's scheduling Inbox.
-
- The server may support delivery of scheduling messages to other
- CalDAV servers if the client specifies a remote calendar user address
- for any recipient, but the server is not bound to support or complete
- remote delivery operations even if it advertises support for the
- "calendar-schedule" feature. Note that remote delivery mechanisms
- are not defined in this specification. This specification does not
- define a server-to-server or server-to-client protocol to deliver
- remote scheduling messages. Implementations may do this in a
- proprietary way, with iMIP [RFC2447], or with iTIP bindings as yet
- unspecified.
-
- After the delivery is completed, CalDAV clients will see the
- scheduling message the next time they synchronize or query a
- scheduling Inbox collection. To reply to a scheduling REQUEST, the
- client uses the POST method to send another scheduling message (this
- time, a REPLY) back to the "Organizer". If the user has decided to
- accept the REQUEST, the client can create a suitable calendar object
- resource in the appropriate calendar collection for the recipient.
- The step of putting the calendar object resource in the calendar is
- left up to the client, so that the client can make appropriate
- choices about where to put the calendar object resource, and with
- what alarms, etc. However, the server MAY be configured to
- automatically accept or reject invitations, and if the server auto-
- accepts invitations then the server is responsible for creating
- calendar object resources in a calendar collection specified by the
- user.
-
-5. New Resource Types and Properties
-
- The CalDAV scheduling extension defines the following new resource
- types for use with CalDAV.
-
-5.1. Scheduling Inbox Collection
-
- A scheduling Inbox collection contains incoming scheduling messages.
- These may be requests sent by an Organizer, or replies sent by an
- Attendee in response to a request.
-
- A scheduling Inbox collection MUST report the DAV:collection and
- CALDAV:schedule-inbox XML elements in the value of the DAV:
- resourcetype property. The element type declaration for CALDAV:
- schedule-inbox is:
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 9]
-
-Internet-Draft CalDAV January 2007
-
-
- <!ELEMENT schedule-inbox EMPTY>
-
- Example:
-
- <resourcetype xmlns="DAV:">
- <collection/>
- <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
- </resourcetype>
-
- Every non-collection resource in the scheduling Inbox collection MUST
- be a valid calendar object resource that defines a scheduling message
- (e.g., an iCalendar object that follows the iTIP semantic). Note,
- that unlike calendar collections defined by the calendar-access
- feature, there are no restrictions on the nature of the resources
- stored (e.g., there is no need to verify that the UIDs in each
- resource are unique) beyond the restrictions of iTIP itself. The
- removal of the UID restriction, in particular, is needed because
- multiple scheduling messages may be sent for one particular calendar
- component, and each of those will have the same UID property in the
- calendar object resource.
-
- A new access control privilege can be set on the scheduling Inbox
- collection to control who is allowed to send scheduling messages to
- the calendar user associated with the scheduling Inbox. See
- Section 8.1 for more details.
-
-5.2. Scheduling Outbox Collection
-
- A scheduling Outbox collection contains outgoing scheduling messages.
- These may be requests initiated by or on behalf of the calendar user
- associated with the scheduling Outbox, or responses to requests
- received by the calendar user associated with the scheduling Outbox.
-
- A scheduling Outbox collection MUST report the DAV:collection and
- CALDAV:schedule-outbox XML elements in the value of the DAV:
- resourcetype property. The element type declaration for CALDAV:
- schedule-outbox is:
-
- <!ELEMENT schedule-outbox EMPTY>
-
- Example:
-
- <resourcetype xmlns="DAV:">
- <collection/>
- <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
- </resourcetype>
-
- Every non-collection resource in the scheduling Outbox collection
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 10]
-
-Internet-Draft CalDAV January 2007
-
-
- MUST be a valid calendar object resource that defines a scheduling
- message (e.g., an iCalendar object that follows the iTIP semantic).
- When a client targets the POST method at a scheduling Outbox, the
- server MAY create a copy of the scheduling message in that scheduling
- Outbox, unless the POST method corresponds to a free-busy message, in
- which case the server MUST NOT store a copy of the free-busy message.
- Copies that are created serve as a record of outgoing scheduling
- messages.
-
- The server MAY auto-delete calendar object resources in the
- scheduling Outbox (e.g., after a period of time or to keep within a
- quota).
-
- A new access control privilege 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.
- See Section 8.1 for more details.
-
-5.3. Scheduling Inbox Properties
-
- This section describes new WebDAV properties on scheduling Inbox
- collection resources.
-
-5.3.1. CALDAV:calendar-free-busy-set Property
-
- Name: calendar-free-busy-set
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the calendars that contribute to the free-busy
- information for the calendar user associated with the scheduling
- Inbox.
-
- Conformance: This property MAY be protected and SHOULD NOT be
- returned by a PROPFIND allprop request (as defined in Section
- 12.14.1 of [RFC2518]). Support for this property is REQUIRED.
-
- Description: This property is required to allow a POST request to
- automatically determine the free busy information for each
- specified Recipient for immediate return in the response. A
- server with a fixed set of calendars per user can make this
- property protected. A server that allows users to create their
- own calendars SHOULD allow users to change their own property
- value.
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 11]
-
-Internet-Draft CalDAV January 2007
-
-
- Definition:
-
- <!ELEMENT calendar-free-busy-set (DAV:href*) >
-
- Example:
-
- <C:calendar-free-busy-set xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:href>/calendars/bernard/work/</D:href>
- <D:href>/calendars/bernard/home/</D:href>
- <D:href>/public/holidays/CA/</D:href>
- </C:calendar-free-busy-set>
-
-5.4. Calendar Object Resource Properties
-
- This section describes new WebDAV properties for calendar object
- resources stored in scheduling Inbox or Outbox collections.
-
-5.4.1. CALDAV:originator Property
-
- Name: originator
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Indicates the Originator of the scheduling message
- contained in a scheduling Inbox or Outbox collection.
-
- Conformance: This property MUST be protected and SHOULD NOT be
- returned by a PROPFIND DAV:allprop request (as defined in Section
- 12.14.1 of [RFC2518]).
-
- Description: The CALDAV:originator property MUST be defined on
- calendar object resources stored in an Inbox or Outbox collection
- as the result of a POST request. The value of the property MUST
- be the value of the Originator request header in the POST request
- that caused the resource to be created in the collection.
-
- Definition:
-
- <!ELEMENT originator (DAV:href)>
- DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])
-
- Example:
-
- <C:originator xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:href>mailto:bernard at example.com</D:href>
- </C:originator>
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 12]
-
-Internet-Draft CalDAV January 2007
-
-
-5.4.2. CALDAV:recipient Property
-
- Name: recipient
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: On a calendar object resource contained in a scheduling
- Outbox collection, this indicates the list of Recipients to whom
- the scheduling message was sent. On a calendar object resource in
- a scheduling Inbox collection, this indicates the recipient
- calendar user address that caused the scheduling message to be
- delivered into the scheduling Inbox.
-
- Conformance: This property MUST be protected and SHOULD NOT be
- returned by a PROPFIND DAV:allprop request (as defined in Section
- 12.14.1 of [RFC2518]).
-
- Description: The CALDAV:recipient property MUST be defined on
- calendar object resources stored in a scheduling Outbox or Inbox
- collection as the result of a POST request. For calendar object
- resources in a scheduling Outbox, the value of the property MUST
- be a list of calendar user addresses formed from all the addresses
- in any Recipient request headers in the POST request that caused
- the resource to be created in the collection. For calendar object
- resources in a scheduling Inbox, the value of the property MUST be
- the calendar user address from the Recipient request header in the
- POST request that caused the resource to be created in the
- collection. Typically this calendar user address will be one of
- those listed in the CALDAV:calendar-user-address-set (see
- Section 8.2.3) property for the principal that owns the scheduling
- Inbox. However, it could, for example, be a calendar user address
- of a group that includes the calendar user associated with the
- scheduling Inbox.
-
- Definition:
-
-
- <!ELEMENT recipient (DAV:href+)>
- DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])
-
-
- Example:
-
- <C:recipient xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:href>mailto:cyrus at example.com</D:href>
- <D:href>mailto:lisa at example.com</D:href>
- </C:recipient>
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 13]
-
-Internet-Draft CalDAV January 2007
-
-
-6. Scheduling
-
-6.1. POST Method
-
- The POST method submits a scheduling or free-busy message to one or
- more recipients by targeting the request at the URI of a scheduling
- Outbox collection. The request body of a POST method MUST contain a
- scheduling message or free-busy message (e.g., an iCalendar object
- that follows the iTIP semantic). The resource identified by the
- Request-URI MUST be a resource collection of type CALDAV:schedule-
- outbox (Section 5.2).
-
- A submitted scheduling message will be delivered to the calendar user
- addresses specified in the Recipient request header. A submitted
- free-busy message will be immediately executed and a free-busy
- response returned.
-
- Preconditions:
-
- (CALDAV:supported-collection): The Request-URI MUST identify the
- location of a scheduling Outbox collection;
-
- (CALDAV:supported-calendar-data): The resource submitted in the
- POST request MUST be a supported media type (i.e., text/calendar)
- for scheduling or free-busy messages;
-
- (CALDAV:valid-calendar-data): The resource submitted in the POST
- request MUST be valid data for the media type being specified
- (i.e., valid iCalendar object);
-
- (CALDAV:valid-scheduling-message): The resource submitted in the
- POST request MUST obey all restrictions specified for the POST
- request (e.g., scheduling message follows the restriction of
- iTIP);
-
- (CALDAV:originator-specified): The POST request MUST include a
- valid Originator request header specifying a calendar user address
- of the currently authenticated user;
-
- (CALDAV:originator-allowed): The calendar user identified by the
- Originator request header in the POST request MUST be granted the
- CALDAV:schedule privilege or a suitable sub-privilege on the
- scheduling Outbox collection being targeted by the request;
-
- (CALDAV:organizer-allowed): The calendar user identified by the
- ORGANIZER property in the POST request's scheduling message MUST
- be the calendar user (or one of the calendar users) associated
- with of the scheduling Outbox being targeted by the request;
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 14]
-
-Internet-Draft CalDAV January 2007
-
-
- (CALDAV:recipient-specified): The POST request MUST include one or
- more valid Recipient request headers specifying the calendar user
- address of users to whom the scheduling message will be delivered.
-
- Postconditions: None
-
-6.1.1. Originator request header
-
- Every POST request MUST include an Originator request header that
- specifies the calendar user address of the originator of a given
- scheduling message. The value specified in this request header MUST
- be a calendar user address specified in the CALDAV:calendar-user-
- address-set property defined on the principal resource of the
- currently authenticated user. Also, the currently authenticated user
- MUST have the CALDAV:schedule privilege or a suitable sub-privilege
- granted on the targeted scheduling Outbox collection.
-
- Typically the Originator request header's value will correspond to
- the Organizer of the calendar component and to the calendar user
- associated with the Outbox being targeted by the request. However,
- the Organizer may choose to allow another user to act on his behalf
- to send scheduling messages. To allow for this a new privilege has
- been defined to allow the calendar user associated with a scheduling
- Outbox to grant to other users the right to execute POST requests on
- that Outbox.
-
- The value of the Originator request header is kept in the CALDAV:
- originator property on any resources saved as a result of the
- schedule request. This includes the copy of the scheduling message
- saved in the scheduling Outbox, and scheduling messages delivered to
- any scheduling Inbox.
-
-6.1.2. ORGANIZER Property
-
- iTIP requires that every scheduling message contains an ORGANIZER
- property identifying the calendar user address of the Organizer of
- the calendar object. To prevent 'spoofing' (forgeries) of scheduling
- messages, CalDAV servers MUST verify that the calendar user address
- identified by the ORGANIZER property in the scheduling message data
- corresponds to the principal owning the scheduling Outbox targeted by
- the POST request. This MUST be done during the processing of the
- POST request.
-
-6.1.3. Recipient request header
-
- Every POST request MUST include one or more Recipient request header.
- The value of this header is a list of one or more calendar user
- addresses and corresponds to the set of calendar users who will be
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 15]
-
-Internet-Draft CalDAV January 2007
-
-
- delivered the scheduling message. The calendar user associated with
- of the scheduling Outbox being targeted by the POST method MUST have
- the CALDAV:schedule privilege or a suitable sub-privilege granted on
- the scheduling Inbox collection of each recipient.
-
- Typically the list of recipients would correspond to any ATTENDEE
- property values listed in the scheduling message data. However,
- there are cases when an ATTENDEE is not listed as a Recipient, or
- when a Recipient is not one of the ATTENDEE's.
-
- For example, if the Organizer of an event wishes to attend the event
- themselves, they must list themselves as one of the ATTENDEE's, as
- the ORGANIZER of an event does not implicitly attend. However, the
- Organizer does not need to receive an invitation as they know their
- own participation status, so there is no need to be listed as a
- Recipient of the scheduling message.
-
- Alternatively, a client may have determined participation status of
- some ATTENDEE's out-of-band and has no need to send another request
- via CalDAV.
-
- In some cases it is handy to be able to send information about a
- meeting to someone who is not an ATTENDEE. In that case, there would
- be a Recipient in the request without a corresponding ATTENDEE
- property in the scheduling message data.
-
- Note that the recipient of a CalDAV scheduling message has no
- knowledge of who the other recipients were - they only get to see the
- ATTENDEE information listed in the scheduling message data. So
- listing a calendar user as a Recipient and not an ATTENDEE is the
- equivalent of a 'Bcc' (blind-carbon-copy) operation in email.
-
-6.1.4. Response to a POST request
-
- A POST request may deliver a scheduling message to one or more
- calendar users specified in the Recipient request header. Since the
- behavior of each recipient may vary, it is useful to get response
- status information for each recipient in the overall POST response.
- This specification defines a new XML response to convey multiple
- recipient status.
-
- A response to a POST method that indicates status for one or more
- recipients MUST be a CALDAV:schedule-response XML element. This MUST
- contain one or more CALDAV:response elements for each recipient, with
- each of those containing elements that indicate which recipient they
- correspond to, the scheduling status of the request for that
- recipient, any error codes and an optional description. See
- Section 10.1.
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 16]
-
-Internet-Draft CalDAV January 2007
-
-
- In the case of a free-busy request, the CALDAV:response elements can
- also contain CALDAV:calendar-data elements which contain free busy
- information (e.g., an iCalendar VFREEBUSY component) indicating the
- busy state of the corresponding recipient, assuming that the free-
- busy request for that recipient succeeded.
-
-6.1.5. Status Codes for use with the POST method
-
- The following are examples of response codes one would expect to be
- used for this method. Note, however, that unless explicitly
- prohibited any 2/3/4/5xx series response code may be used in a
- response.
-
- 200 (OK) - The command succeeded.
-
- 400 (Bad Request) - The client has provided an invalid scheduling
- message.
-
- 403 (Forbidden) - The client, for reasons the server chooses not to
- specify, cannot submit a scheduling message to the specified Request-
- URI.
-
- 404 (Not Found) - The URL in the Request-URI, the Originator, or the
- Recipient request headers were not present.
-
- 423 (Locked) - The specified resource is locked and the client either
- is not a lock owner or the lock type requires a lock token to be
- submitted and the client did not submit it.
-
- 502 (Bad Gateway) - The Recipient request header contained a URL
- which the server considers to be in another domain, which it cannot
- forward scheduling messages to.
-
- 507 (Insufficient Storage) - The server did not have sufficient space
- to record the scheduling message in a recipient's scheduling inbox.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 17]
-
-Internet-Draft CalDAV January 2007
-
-
-6.1.6. Example - Simple meeting invitation
-
- >> Request <<
-
-
- POST /lisa/calendar/outbox/ HTTP/1.1
- Host: cal.example.com
- Originator: mailto:lisa at example.com
- Recipient: mailto:bernard at example.com
- Recipient: mailto:cyrus at example.com
- Content-Type: text/calendar
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REQUEST
- BEGIN:VEVENT
- DTSTAMP:20040901T200200Z
- ORGANIZER:mailto:lisa at example.com
- DTSTART:20040902T130000Z
- DTEND:20040902T140000Z
- SUMMARY:Design meeting
- UID:34222-232 at example.com
- ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
- IVIDUAL;CN=Lisa Dusseault:mailto:lisa at example.c
- om
- ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
- uisseaux:mailto:bernard at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
- mailto:cyrus at example.com
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 18]
-
-Internet-Draft CalDAV January 2007
-
-
- >> Response <<
-
-
- HTTP/1.1 200 OK
- Date: Thu, 02 Sep 2004 16:53:32 GMT
- Content-Type: text/xml
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <C:schedule-response xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <C:response>
- <C:recipient>mailto:bernard at example.com</C:recipient>
- <C:request-status>2.0;Success</C:request-status>
- <D:responsedescription>Delivered to recipient
- scheduling inbox</D:responsedescription>
- </C:response>
- <C:response>
- <C:recipient>mailto:cyrus at example.com</C:recipient>
- <C:request-status>2.0;Success</C:request-status>
- <D:responsedescription>Delivered to recipient
- scheduling inbox</D:responsedescription>
- </C:response>
- </C:schedule-response>
-
-
- In this example, the client requests the server to deliver a meeting
- invitation (scheduling REQUEST) to the calendar users
- mailto:bernard at example.com and mailto:cyrus at example.com. The
- response indicates that delivery to the relevant scheduling Inboxes
- of each recipient was accomplished successfully.
-
- Note that the Originator and Organizer calendar user addresses were
- both set to mailto:lisa at example.com. In order to indicate that she
- is also attending the meeting, mailto:lisa at example.com also included
- an ATTENDEE property in the iCalendar data corresponding to her
- calendar user address, however she did not include a Recipient
- request header for that calendar user address since she already has
- here own copy of the meeting stored in a calendar collection.
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 19]
-
-Internet-Draft CalDAV January 2007
-
-
-6.1.7. Example - Free-Busy lookup
-
- >> Request <<
-
-
- POST /lisa/calendar/outbox/ HTTP/1.1
- Host: cal.example.com
- Originator: mailto:lisa at example.com
- Recipient: mailto:bernard at example.com
- Recipient: mailto:cyrus at 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 at example.com
- DTSTART:20040902T000000Z
- DTEND:20040903T000000Z
- UID:34222-232 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
- uisseaux:mailto:bernard at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
- mailto:cyrus at example.com
- END:VFREEBUSY
- END:VCALENDAR
-
-
- >> Response <<
-
-
- HTTP/1.1 200 OK
- Date: Thu, 02 Sep 2004 16:53:32 GMT
- Content-Type: text/xml
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <C:schedule-response xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <C:response>
- <C:recipient>mailto:bernard at example.com</C:recipient>
- <C:request-status>2.0;Success</C:request-status>
- <C:calendar-data>BEGIN:VCALENDAR
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 20]
-
-Internet-Draft CalDAV January 2007
-
-
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REPLY
- BEGIN:VFREEBUSY
- DTSTAMP:20040901T200200Z
- ORGANIZER:mailto:lisa at example.com
- DTSTART:20040902T000000Z
- DTEND:20040903T000000Z
- UID:34222-232 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
- uisseaux:mailto:bernard at example.com
- FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
- 20040902T090000Z,20040902T170000Z/20040903T000000Z
- END:VFREEBUSY
- END:VCALENDAR
- </C:calendar-data>
- <D:responsedescription>Immediate response from recipient
- </D:responsedescription>
- </C:response>
- <C:response>
- <C:recipient>mailto:cyrus at 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 Client//EN
- METHOD:REPLY
- BEGIN:VFREEBUSY
- DTSTAMP:20040901T200200Z
- ORGANIZER:mailto:lisa at example.com
- DTSTART:20040902T000000Z
- DTEND:20040903T000000Z
- UID:34222-232 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
- mailto:cyrus at example.com
- FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
- 20040902T090000Z,20040902T170000Z/20040903T000000Z
- FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z
- END:VFREEBUSY
- END:VCALENDAR
- </C:calendar-data>
- <D:responsedescription>Immediate response from recipient
- </D:responsedescription>
- </C:response>
- </C:schedule-response>
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 21]
-
-Internet-Draft CalDAV January 2007
-
-
- In this example, the client requests the server to determine the busy
- information of the calendar users mailto:bernard at example.com and
- mailto:cyrus at example.com, over the time range specified by the
- scheduling message sent in the request. The response includes
- VFREEBUSY components for each of those calendar users with their busy
- time indicated.
-
-6.2. Retrieving incoming scheduling messages
-
- Incoming scheduling messages will be stored in a scheduling Inbox
- collection. As per Section 9, CalDAV calendar access reports work on
- scheduling collections, so the client can use those to get partial
- information on scheduling messages in the scheduling inbox.
-
-6.2.1. Example - Retrieve incoming scheduling message
-
- >> Request <<
-
-
- GET /bernard/calendar/inbox/mtg456.ics HTTP/1.1
- Host: cal.example.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 22]
-
-Internet-Draft CalDAV January 2007
-
-
- >> Response <<
-
-
- HTTP/1.1 200 OK
- Date: Thu, 02 Sep 2004 17:05:23 GMT
- Content-Type: text/calendar
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REQUEST
- BEGIN:VEVENT
- DTSTAMP:20040901T200200Z
- CATEGORIES:APPOINTMENT
- ORGANIZER:mailto:lisa at example.com
- DTSTART:20040902T130000Z
- DTEND:20040902T140000Z
- SUMMARY:CalDAV draft review
- UID:34222-232 at example.com
- ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
- IVIDUAL;CN=Lisa Dusseault:mailto:lisa at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
- ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:
- mailto:bernard at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
- ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:mailto:cyr
- us at example.com
- END:VEVENT
- END:VCALENDAR
-
-
-6.3. Acting on incoming scheduling messages
-
- Scheduling messages are delivered into a recipients Inbox collection.
- To process these messages a calendar user agent client needs to
- follow a sequence of steps to ensure good interoperability with other
- clients that may also be monitoring or processing the Inbox.
-
- Processing a scheduling message in an Inbox collections requires the
- client to read the message, determine the nature of the scheduling
- operation, make appropriate adjustments to the recipients actual
- calendars, and then, if required, send a response.
-
- In order to ensure that only one client at a time is processing
- scheduling messages in an Inbox collection, clients MUST use the
- WebDAV locking feature to lock the entire Inbox collection for the
- duration of its processing step. Once a collection is locked, other
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 23]
-
-Internet-Draft CalDAV January 2007
-
-
- clients attempting to obtain their own lock will fail as the WebDAV
- server will return a protocol error at that point. Clients MUST NOT
- attempt to process scheduling messages in an Inbox without having
- obtained a lock first.
-
- When a scheduling message has been processed by a client it MUST
- delete that message from the Inbox before removing the webDAV lock on
- the Inbox collection. This ensures that other clients will not in
- the future attempt to process the scheduling message again.
-
- TODO: provide definitions of new iCalendar parameters RECEIVED-
- DTSTAMP and RECEIVED-SEQUENCE that will help with schedule
- processing.
-
-7. HTTP Request Headers for CalDAV
-
-7.1. Originator Request Header
-
-
- Originator = "Originator" ":" absoluteURI
-
-
- The Originator request header value is a URI which specifies the
- calendar user address of the originator of the scheduling message.
- Note that the absoluteURI production is defined in RFC2396 [RFC2396].
-
-7.2. Recipient Request Header
-
-
- Recipient = "Recipient" ":" 1#absoluteURI
-
-
- The Recipient request header value is a URI which specifies the
- calendar user address of the recipients to which the POST method
- should deliver the submitted scheduling message. Note that the
- absoluteURI production is defined in RFC2396 [RFC2396]
-
-8. Scheduling Access Control
-
-8.1. Scheduling Privileges
-
- A CalDAV server MUST support the WebDAV ACLs standard [RFC3744].
- That standard provides a framework for an extensible list of
- privileges on WebDAV collections and ordinary resources. A CalDAV
- server MUST also support the set of calendar-specific privileges
- defined in this section.
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 24]
-
-Internet-Draft CalDAV January 2007
-
-
-8.1.1. CALDAV:schedule-request Privilege
-
- The CALDAV:schedule-request privilege controls who can initiate
- scheduling requests, and who will accept such requests.
-
- The CALDAV:schedule-request privilege can be applied to either a
- scheduling Outbox or Inbox. Its effect depends on the type of
- collection it is applied to.
-
- When used on a scheduling Outbox, the CALDAV:schedule-request
- privilege controls the use of the POST method to submit a scheduling
- message via a scheduling Outbox collection. When granted to a
- principal, that principal is allowed to use the POST method on the
- schedule Outbox with the following restrictions:
-
- the iCalendar component in the request body MUST NOT be a
- VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
-
- the METHOD property in the iCalendar component in the request body
- MUST be either PUBLISH or REQUEST.
-
- When used on a scheduling Inbox, the CALDAV:schedule-request
- privilege controls whether a scheduling message can be deposited in
- the scheduling Inbox collection. When granted to a principal, that
- principal is allowed to use the POST method to deposit scheduling
- messages with the following restrictions:
-
- the iCalendar component in the request body MUST NOT be a
- VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
-
- the METHOD property in the iCalendar component in the request body
- MUST be either PUBLISH or REQUEST.
-
- <!ELEMENT schedule-request EMPTY >
-
- For example, the following ACE, on Bernard's scheduling Outbox, would
- only grant the privilege to Bernard to send schedule request messages
- on behalf of himself:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/bernard</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-request/></D:privilege>
- </D:grant>
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 25]
-
-Internet-Draft CalDAV January 2007
-
-
- </D:ace>
-
-
- Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
- grant the privilege to Cyrus and his assistant Kim to send schedule
- request messages on behalf of Cyrus:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/cyrus</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-request/></D:privilege>
- </D:grant>
- </D:ace>
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/kim</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-request/></D:privilege>
- </D:grant>
- </D:ace>
-
-
- For example, the following ACE's, on Bernard's scheduling Inbox,
- would grant the privilege to Lisa to send a schedule request message
- to Bernard:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/lisa</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-request/></D:privilege>
- </D:grant>
- </D:ace>
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 26]
-
-Internet-Draft CalDAV January 2007
-
-
-8.1.2. CALDAV:schedule-reply Privilege
-
- The CALDAV:schedule-reply privilege controls who can respond to
- scheduling requests, and who will accept such responses.
-
- The CALDAV:schedule-reply privilege can be applied to either a
- scheduling Outbox or Inbox. Its effect depends on the type of
- collection it is applied to.
-
- When used on a scheduling Outbox, the CALDAV:schedule-reply privilege
- controls the use of the POST method to submit a scheduling message
- via a scheduling Outbox collection. When granted to a principal,
- that principal is allowed to use the POST method on the schedule
- Outbox with the following restrictions:
-
- the iCalendar component in the request body MUST NOT be a
- VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
-
- the METHOD property in the iCalendar component in the request body
- MUST NOT be either PUBLISH or REQUEST.
-
- When used on a scheduling Inbox, the CALDAV:schedule-reply privilege
- controls whether a scheduling message can be deposited in the
- scheduling Inbox collection. When granted to a principal, that
- principal is allowed to use the POST method to deposit scheduling
- messages with the following restrictions:
-
- the iCalendar component in the request body MUST NOT be a
- VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
-
- the METHOD property in the iCalendar component in the request body
- MUST NOT be either PUBLISH or REQUEST.
-
- <!ELEMENT schedule-reply EMPTY >
-
- For example, the following ACE, on Bernard's scheduling Outbox, would
- only grant the privilege to Bernard to respond to schedule messages
- on behalf of himself:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/bernard</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-reply/></D:privilege>
- </D:grant>
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 27]
-
-Internet-Draft CalDAV January 2007
-
-
- </D:ace>
-
-
- Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
- grant the privilege to Cyrus and his assistant Kim to respond to
- schedule messages on behalf of Cyrus:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/cyrus</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-reply/></D:privilege>
- </D:grant>
- </D:ace>
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/kim</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-reply/></D:privilege>
- </D:grant>
- </D:ace>
-
-
- For example, the following ACE's, on Bernard's scheduling Inbox,
- would grant the privilege to Lisa to send a scheduling reply message
- to Bernard:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/lisa</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-reply/></D:privilege>
- </D:grant>
- </D:ace>
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 28]
-
-Internet-Draft CalDAV January 2007
-
-
-8.1.3. CALDAV:schedule-free-busy Privilege
-
- The CALDAV:schedule-free-busy privilege controls who can initiate
- free-busy requests, and who will accept such requests.
-
- The CALDAV:schedule-free-busy privilege can be applied to either a
- scheduling Outbox or Inbox. Its effect depends on the type of
- collection it is applied to.
-
- When used on a scheduling Outbox, the CALDAV:schedule-free-busy
- privilege controls the use of the POST method to submit a scheduling
- message via a scheduling Outbox collection. When granted to a
- principal, that principal is allowed to use the POST method on the
- schedule Outbox with the following restrictions:
-
- the iCalendar component in the request body MUST be a VFREEBUSY
- component.
-
- the METHOD property in the iCalendar component in the request body
- MUST be REQUEST.
-
- When used on a scheduling Inbox, the CALDAV:schedule-free-busy
- privilege controls whether a scheduling message can be deposited in
- the scheduling Inbox collection. When granted to a principal, that
- principal is allowed to use the POST method to deposit scheduling
- messages with the following restrictions:
-
- the iCalendar component in the request body MUST be a VFREEBUSY
- component.
-
- the METHOD property in the iCalendar component in the request body
- MUST be REQUEST.
-
- <!ELEMENT schedule-free-busy EMPTY >
-
- For example, the following ACE, on Bernard's scheduling Outbox, would
- only grant the privilege to Bernard to request free-busy information
- on behalf of himself:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/bernard</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-free-busy/></D:privilege>
- </D:grant>
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 29]
-
-Internet-Draft CalDAV January 2007
-
-
- </D:ace>
-
-
- Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
- grant the privilege to Cyrus and his assistant Kim to free-busy
- information on behalf of Cyrus:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/cyrus</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-free-busy/></D:privilege>
- </D:grant>
- </D:ace>
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/kim</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-free-busy/></D:privilege>
- </D:grant>
- </D:ace>
-
-
- For example, the following ACE's, on Bernard's scheduling Inbox,
- would grant the privilege to Lisa to retrieve free-busy information
- for Bernard:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/lisa</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule-free-busy/></D:privilege>
- </D:grant>
- </D:ace>
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 30]
-
-Internet-Draft CalDAV January 2007
-
-
-8.1.4. CALDAV:schedule Privilege
-
- The CALDAV:schedule privilege can be applied to either a scheduling
- Outbox or Inbox. Its effect depends on the type of collection it is
- applied to. This privilege is actually an aggregate of the CALDAV:
- schedule-request, CALDAV:schedule-reply and CALDAV:schedule-free-busy
- privileges.
-
- <!ELEMENT schedule EMPTY >
-
- For example, the following ACE, on Bernard's scheduling Outbox, would
- only grant the privilege to Bernard to carry out any schedule
- operation on behalf of himself:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/bernard</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule/></D:privilege>
- </D:grant>
- </D:ace>
-
-
- Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
- grant the privilege to Cyrus and his assistant Kim to carry out any
- schedule operation on behalf of Cyrus:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/cyrus</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule/></D:privilege>
- </D:grant>
- </D:ace>
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/kim</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule/></D:privilege>
- </D:grant>
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 31]
-
-Internet-Draft CalDAV January 2007
-
-
- </D:ace>
-
-
- For example, the following ACE's, on Bernard's scheduling Inbox,
- would grant the privilege to Lisa to carry out any schedule operation
- with Bernard:
-
-
- <D:ace xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:principal>
- <D:href>http://cal.example.com/users/lisa</D:href>
- </D:principal>
- <D:grant>
- <D:privilege><C:schedule/></D:privilege>
- </D:grant>
- </D:ace>
-
-
-8.1.5. Privilege aggregation and the DAV:supported-privilege-set
- property
-
- The CALDAV:schedule privilege MUST be non-abstract, and MUST be
- aggregated under the DAV:bind privilege. The CALDAV:schedule
- privilege MUST appear in the DAV:supported-privilege-set property of
- scheduling Inbox and Outbox collections.
-
- The CALDAV:schedule-request, CALDAV:schedule-reply and CALDAV:
- schedule-free-busy privileges MUST be non-abstract, and MUST be
- aggregated under the CALDAV:schedule privilege. These privileges
- MUST appear in the DAV:supported-privilege-set property of scheduling
- Inbox and Outbox collections.
-
-8.2. Additional Principal Properties
-
- This section defines new properties for WebDAV principal resources as
- defined in RFC3744 [RFC3744]. These properties are likely to be
- protected but the server MAY allow them to be written by appropriate
- users.
-
-8.2.1. CALDAV:schedule-inbox-URL Property
-
- Name: schedule-inbox-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 32]
-
-Internet-Draft CalDAV January 2007
-
-
- Purpose: Identify the URL of the scheduling Inbox collection owned
- by the associated principal resource.
-
- Conformance: This property MAY be protected and SHOULD NOT be
- returned by a PROPFIND allprop request (as defined in Section
- 12.14.1 of [RFC2518]).
-
- Description: This property is needed for a client to determine where
- the scheduling Inbox of the current user is located so that
- processing of scheduling messages can occur.
-
- Definition:
-
- <!ELEMENT schedule-inbox-URL (href)>
-
-8.2.2. CALDAV:schedule-outbox-URL Property
-
- Name: schedule-outbox-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the URL of the scheduling Outbox collection owned
- by the associated principal resource.
-
- Conformance: This property MAY be protected and SHOULD NOT be
- returned by a PROPFIND allprop request (as defined in Section
- 12.14.1 of [RFC2518]).
-
- Description: This property is needed for a client to determine where
- the scheduling Outbox of the current user is located so that
- sending of scheduling messages can occur.
-
- Definition:
-
- <!ELEMENT schedule-outbox-URL href>
-
-8.2.3. CALDAV:calendar-user-address-set Property
-
- Name: calendar-user-address-set
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the calendar addresses of the associated principal
- resource.
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 33]
-
-Internet-Draft CalDAV January 2007
-
-
- Conformance: This property MAY be protected and SHOULD NOT be
- returned by a PROPFIND allprop request (as defined in Section
- 12.14.1 of [RFC2518] ). Support for this property is REQUIRED.
- This property SHOULD be searchable using the DAV:principal-
- property-search REPORT. The DAV:principal-search-property-set
- REPORT SHOULD identify this property as such.
-
- Description: This property is needed to map Originator and Recipient
- values in a POST request to principal resources and their
- associated scheduling Inbox and Outbox. In the event that a user
- has no well defined identifier for their calendar user address,
- the URI of their principal resource can be used.
-
- Definition:
-
-
- <!ELEMENT calendar-user-address-set (DAV:href*)>
-
-
- Example:
-
-
- <C:calendar-user-address-set xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:href>mailto:bernard at example.com</D:href>
- <D:href>mailto:bernard.desruisseaux at example.com</D:href>
- </C:calendar-user-address-set>
-
-
-8.2.4. Example: Searching for calendars belonging to a user based on a
- calendar user address
-
- In this example, the client requests the CALDAV:calendar-home-URL of
- the principal resources whose CALDAV:calendar-user-address-set
- property contains the substring "mailto:bernard at example.com". In
- addition, the client requests the DAV:displayname of each principal
- to also be returned for the matching principals.
-
- The response shows that only one principal resource meets the search
- specification, "mailto:bernard at example.com".
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 34]
-
-Internet-Draft CalDAV January 2007
-
-
- >> Request <<
-
-
- REPORT /users/ HTTP/1.1
- Host: cal.example.com
- Content-Type: text/xml; charset="utf-8"
- Content-Length: xxxx
- Depth: 0
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:principal-property-search xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:property-search>
- <D:prop>
- <C:calendar-user-address-set/>
- </D:prop>
- <D:match>mailto:bernard at example.com</D:match>
- </D:property-search>
- <D:prop>
- <C:calendar-home-URL/>
- <D:displayname/>
- </D:prop>
- </D:principal-property-search>
-
- >> Response <<
-
- HTTP/1.1 207 Multi-Status
- Content-Type: text/xml; charset=utf-8
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <D:multistatus xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:response>
- <D:href>/users/bernard</D:href>
- <D:propstat>
- <D:prop>
- <C:calendar-home-URL>
- <D:href>/home/bernard/</D:href>
- </C:calendar-home-URL>
- <D:displayname>Bernard Desruisseaux</D:displayname>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
- </D:multistatus>
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 35]
-
-Internet-Draft CalDAV January 2007
-
-
-8.2.5. Example: Finding the scheduling Inbox and Outbox belonging to
- the currently authenticated user
-
- In this example, the client requests the CALDAV:schedule-inbox-URL
- and CALDAV:schedule-outbox-URL of the currently authenticated user.
-
- TODO: principal-match report
-
-9. Reports
-
- When the calendar-access feature is supported in addition to
- calendar-schedule, this specification extends the CALDAV:calendar-
- query and CALDAV:calendar-multiget reports to return results for
- calendar object resources in scheduling Inbox and Outbox collections
- when the report directly targets such a collection. i.e. the Request-
- URI for a REPORT MUST be the URI of the scheduling Inbox or Outbox or
- of a child resource within a scheduling Inbox or Outbox collection.
- A report run on a regular collection that includes a scheduling Inbox
- or Outbox as a child resource at any depth MUST NOT examine or return
- any calendar object resources from within any scheduling Inbox or
- Outbox collections.
-
- Note that the CALDAV:free-busy-query report is NOT supported on
- scheduling Inbox or Outbox collections when the calendar-access
- feature is also present.
-
-10. XML Element Definitions
-
-10.1. CALDAV:schedule-response XML Element
-
- Name: schedule-response
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Contains the set of responses for a POST method request.
-
- Description: See Section 6.1.4.
-
- Definition:
-
-
- <!ELEMENT schedule-response (response*)>
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 36]
-
-Internet-Draft CalDAV January 2007
-
-
-10.2. CALDAV:response XML Element
-
- Name: response
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Contains a single response for a POST method request.
-
- Description: See Section 6.1.4.
-
- Definition:
-
- <!ELEMENT response (recipient,
- request-status,
- calendar-data?,
- DAV:error?,
- DAV:responsedescription?)>
-
-10.3. CALDAV:recipient XML Element
-
- Name: recipient
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: The calendar user address (recipient header value) that the
- enclosing response for a POST method request is for.
-
- Description: See Section 6.1.4.
-
- Definition:
-
-
- <!ELEMENT recipient (#PCDATA)>
-
-
-10.4. CALDAV:request-status XML Element
-
- Name: request-status
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: The iTIP REQUEST-STATUS property value for this response.
-
- Description: See Section 6.1.4.
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 37]
-
-Internet-Draft CalDAV January 2007
-
-
- Definition:
-
-
- <!ELEMENT request-status (#PCDATA)>
-
-
-11. Security Considerations
-
- The process of scheduling involves the sending and receiving of
- scheduling messages. As a result, the security problems related to
- messaging in general are relevant here. In particular the
- authenticity of the scheduling messages needs to be verified
- absolutely. Servers and clients MUST use an HTTP connection
- protected with TLS as defined in [RFC2818] for all scheduling
- transactions.
-
-11.1. Verifying scheduling requests
-
- When handling a POST request on a scheduling Outbox:
-
- Servers MUST verify that the principal associated with the
- calendar user address specified in the Originator request header
- in the request matches the currently authenticated user.
-
- Servers MUST verify that the currently authenticated user has the
- CALDAV:schedule privilege or a suitable sub-privilege on the
- scheduling Outbox targeted by the request.
-
- Servers MUST verify that the principal associated with the
- calendar user address specified in the ORGANIZER property of the
- scheduling message data in the request contains a CALDAV:schedule-
- outbox-URL property value that matches the scheduling Outbox
- targeted by the request.
-
- Servers MUST verify that the principal associated with the
- calendar user address specified in the ORGANIZER property of the
- scheduling message data in the request has the CALDAV:schedule
- privilege or a suitable sub-privilege on all of the scheduling
- Inbox collections for the principals associated with all of the
- calendar user addresses specified in any Recipient request headers
- in the request.
-
- The CALDAV:calendar-free-busy-set property on principal resources
- SHOULD only be accessible when that principal is authenticated
- (i.e., the property SHOULD be hidden from other principals).
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 38]
-
-Internet-Draft CalDAV January 2007
-
-
-12. IANA Consideration
-
- This specification does not require any IANA actions.
-
-13. Acknowledgements
-
- The authors would like to thank the following individuals for
- contributing their ideas and support for writing this specification:
- Mike Douglass, Julian F. Reschke, Wilfredo Sanchez Vega, Simon
- Vaillancourt, and Jim Whitehead.
-
- The authors would also like to thank the Calendaring and Scheduling
- Consortium for advice with this specification, and for organizing
- interoperability testing events to help refine it.
-
-14. References
-
-14.1. Normative References
-
- [I-D.dusseault-caldav] Dusseault, L., "Calendaring Extensions to
- WebDAV (CalDAV)", draft-dusseault-caldav-15
- (work in progress), September 2006.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to
- Indicate Requirement Levels", BCP 14,
- RFC 2119, March 1997.
-
- [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol
- Version 1.0", RFC 2246, January 1999.
-
- [RFC2396] Berners-Lee, T., Fielding, R., and L.
- Masinter, "Uniform Resource Identifiers
- (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [RFC2445] Dawson, F. and Stenerson, D., "Internet
- Calendaring and Scheduling Core Object
- Specification (iCalendar)", RFC 2445,
- November 1998.
-
- [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and
- R. Hopson, "iCalendar Transport-Independent
- Interoperability Protocol (iTIP) Scheduling
- Events, BusyTime, To-dos and Journal
- Entries", RFC 2446, November 1998.
-
- [RFC2447] Dawson, F., Mansour, S., and S. Silverberg,
- "iCalendar Message-Based Interoperability
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 39]
-
-Internet-Draft CalDAV January 2007
-
-
- Protocol (iMIP)", RFC 2447, November 1998.
-
- [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter,
- S., and D. Jensen, "HTTP Extensions for
- Distributed Authoring -- WEBDAV", RFC 2518,
- February 1999.
-
- [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.
-
- [RFC4346] Dierks, T. and E. Rescorla, "The Transport
- Layer Security (TLS) Protocol Version 1.1",
- RFC 4346, April 2006.
-
- [W3C.REC-xml-20060816] Yergeau, F., Paoli, J., Sperberg-McQueen, C.,
- Maler, E., and T. Bray, "Extensible Markup
- Language (XML) 1.0 (Fourth Edition)", World
- Wide Web Consortium Recommendation REC-xml-
- 20060816, August 2006,
- <http://www.w3.org/TR/2006/REC-xml-20060816>.
-
-14.2. Informative References
-
- [I-D.ietf-webdav-rfc2518bis] Dusseault, L., "HTTP Extensions for
- Distributed Authoring - WebDAV",
- draft-ietf-webdav-rfc2518bis-17 (work
- in progress), December 2006.
-
-Appendix A. Changes
-
-A.1. Changes in -03
-
- a. Added free-busy example.
- b. Better abstract.
- c. Requiring DAV level 2 for locking of Inbox.
- d. Do not require servers to actually save Outbox requests.
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 40]
-
-Internet-Draft CalDAV January 2007
-
-
- e. Removed CALDAV:schedule-state Property. Clients now must remove
- inbox items after processing them, using locking etc to prevent
- race conditions.
- f. Switched back to 2518 reference from 2518bis.
- g. Updated to more recent XML reference.
- h. Revised required features section to better match caldav-access.
-
-A.2. Changes in -02
-
- a. Split schedule privilege into three sub-privileges.
- b. Made support for caldav-access optional.
- c. Changed SCHEDULE method to POST.
-
-A.3. Changes in -01
-
- a. Updated to latest references including 2518bis.
- b. Added principal property CALDAV:calendar-user-address-set.
- c. Major changes to schedule method, including addition of
- preconditions.
- d. New principal properties added.
- e. Text related to alternative ways of doing scheduling (some
- speculative) removed.
- f. Added Security Considerations text.
- g. Added IANA consideration text.
-
-Authors' Addresses
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- EMail: cyrus at 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 at oracle.com
- URI: http://www.oracle.com/
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 41]
-
-Internet-Draft CalDAV January 2007
-
-
- Lisa Dusseault
- CommerceNet
- 169 University Ave.
- Palo Alto, CA 94301
- USA
-
- EMail: ldusseault at commerce.net
- URI: http://commerce.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 42]
-
-Internet-Draft CalDAV January 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 at ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Daboo, et al. Expires July 30, 2007 [Page 43]
-
+
+
+
+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 at 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 at 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 at example.com
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:lisa at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
+ Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
+ uisseaux:mailto:bernard at 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 at 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 at 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 at example.com
+ DTSTART:20040902T000000Z
+ DTEND:20040903T000000Z
+ UID:34222-232 at example.com
+ ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
+ example.com
+ ATTENDEE;CN=Cyrus Daboo:mailto:cyrus at 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 at 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 at example.com
+ DTSTART:20040902T000000Z
+ DTEND:20040903T000000Z
+ UID:34222-232 at 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 at 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 at example.com
+ DTSTART:20040902T000000Z
+ DTEND:20040903T000000Z
+ UID:34222-232 at example.com
+ ATTENDEE;CN=Cyrus Daboo:mailto:cyrus at 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 at example.com and
+ mailto:cyrus at 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 at example.com</D:href>
+ <D:href>mailto:bernard.desruisseaux at 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 at 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 at 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 at ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires March 23, 2009 [Page 55]
+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20080924/37ced913/attachment-0001.html
More information about the calendarserver-changes
mailing list