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 . 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 Example: 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: Example: 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: Example: /calendars/bernard/work/ /calendars/bernard/home/ /public/holidays/CA/ 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: DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445]) Example: mailto:bernard@example.com 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: DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445]) Example: mailto:cyrus@example.com mailto:lisa@example.com 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@example.com Recipient: mailto:bernard@example.com Recipient: mailto:cyrus@example.com Content-Type: text/calendar Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN METHOD:REQUEST BEGIN:VEVENT DTSTAMP:20040901T200200Z ORGANIZER:mailto:lisa@example.com DTSTART:20040902T130000Z DTEND:20040902T140000Z SUMMARY:Design meeting UID:34222-232@example.com ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.c om ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr uisseaux:mailto:bernard@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: mailto:cyrus@example.com END:VEVENT END:VCALENDAR Daboo, et al. Expires 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 mailto:bernard@example.com 2.0;Success Delivered to recipient scheduling inbox mailto:cyrus@example.com 2.0;Success Delivered to recipient scheduling inbox In this example, the client requests the server to deliver a meeting invitation (scheduling REQUEST) to the calendar users mailto:bernard@example.com and mailto:cyrus@example.com. The response indicates that delivery to the relevant scheduling Inboxes of each recipient was accomplished successfully. Note that the Originator and Organizer calendar user addresses were both set to mailto:lisa@example.com. In order to indicate that she is also attending the meeting, mailto:lisa@example.com also included an ATTENDEE property in the iCalendar data corresponding to her calendar user address, however she did not include a Recipient request header for that calendar user address since she already has here own copy of the meeting stored in a calendar collection. 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@example.com Recipient: mailto:bernard@example.com Recipient: mailto:cyrus@example.com Content-Type: text/calendar Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN METHOD:REQUEST BEGIN:VFREEBUSY DTSTAMP:20040901T200200Z ORGANIZER:mailto:lisa@example.com DTSTART:20040902T000000Z DTEND:20040903T000000Z UID:34222-232@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr uisseaux:mailto:bernard@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: mailto:cyrus@example.com END: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 mailto:bernard@example.com 2.0;Success 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@example.com DTSTART:20040902T000000Z DTEND:20040903T000000Z UID:34222-232@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr uisseaux:mailto:bernard@example.com FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 20040902T090000Z,20040902T170000Z/20040903T000000Z END:VFREEBUSY END:VCALENDAR Immediate response from recipient mailto:cyrus@example.com 2.0;Success BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN METHOD:REPLY BEGIN:VFREEBUSY DTSTAMP:20040901T200200Z ORGANIZER:mailto:lisa@example.com DTSTART:20040902T000000Z DTEND:20040903T000000Z UID:34222-232@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo: mailto:cyrus@example.com FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/ 20040902T090000Z,20040902T170000Z/20040903T000000Z FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z END:VFREEBUSY END:VCALENDAR Immediate response from recipient 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@example.com and mailto:cyrus@example.com, over the time range specified by the scheduling message sent in the request. The response includes VFREEBUSY components for each of those calendar users with their busy time indicated. 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@example.com DTSTART:20040902T130000Z DTEND:20040902T140000Z SUMMARY:CalDAV draft review UID:34222-232@example.com ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux: mailto:bernard@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:mailto:cyr us@example.com END:VEVENT END:VCALENDAR 6.3. Acting on incoming scheduling messages Scheduling messages are delivered into a 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. 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: http://cal.example.com/users/bernard Daboo, et al. Expires July 30, 2007 [Page 25] Internet-Draft CalDAV January 2007 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: http://cal.example.com/users/cyrus http://cal.example.com/users/kim 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: http://cal.example.com/users/lisa 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. 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: http://cal.example.com/users/bernard Daboo, et al. Expires July 30, 2007 [Page 27] Internet-Draft CalDAV January 2007 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: http://cal.example.com/users/cyrus http://cal.example.com/users/kim 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: http://cal.example.com/users/lisa 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. 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: http://cal.example.com/users/bernard Daboo, et al. Expires July 30, 2007 [Page 29] Internet-Draft CalDAV January 2007 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: http://cal.example.com/users/cyrus http://cal.example.com/users/kim For example, the following ACE's, on Bernard's scheduling Inbox, would grant the privilege to Lisa to retrieve free-busy information for Bernard: http://cal.example.com/users/lisa 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. 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: http://cal.example.com/users/bernard 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: http://cal.example.com/users/cyrus http://cal.example.com/users/kim Daboo, et al. Expires July 30, 2007 [Page 31] Internet-Draft CalDAV January 2007 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: http://cal.example.com/users/lisa 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: 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: 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: Example: mailto:bernard@example.com mailto:bernard.desruisseaux@example.com 8.2.4. Example: Searching for calendars belonging to a user based on a calendar user address In this example, the client requests the CALDAV:calendar-home-URL of the principal resources whose CALDAV:calendar-user-address-set property contains the substring "mailto:bernard@example.com". In addition, the client requests the DAV:displayname of each principal to also be returned for the matching principals. The response shows that only one principal resource meets the search specification, "mailto:bernard@example.com". Daboo, et al. Expires 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 mailto:bernard@example.com >> Response << HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset=utf-8 Content-Length: xxxx /users/bernard /home/bernard/ Bernard Desruisseaux HTTP/1.1 200 OK 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: 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: 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: 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: 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, . 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@daboo.name URI: http://www.apple.com/ Bernard Desruisseaux Oracle Corporation 600 Blvd. de Maisonneuve West Suite 1900 Montreal, QC H3A 3J2 CANADA EMail: bernard.desruisseaux@oracle.com URI: http://www.oracle.com/ Daboo, 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@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@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]