[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