[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 6638

Network Working Group                                           C. Daboo
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                         B. Desruisseaux
Expires: May 7, 2009                                              Oracle
                                                        November 3, 2008


                 CalDAV Scheduling Extensions to WebDAV
                   draft-desruisseaux-caldav-sched-06

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 May 7, 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 May 7, 2009                  [Page 1]

Internet-Draft               CalDAV Schedule               November 2008


     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     1.5.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  CalDAV Scheduling Support  . . . . . . . . . . . . . . . . . .  7
   3.  Scheduling Process . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Scheduling Collections . . . . . . . . . . . . . . . . . .  9
       3.1.1.  Scheduling Outbox Collection . . . . . . . . . . . . .  9
       3.1.2.  Scheduling Inbox Collection  . . . . . . . . . . . . . 10
     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 . . . . . . . . 21
         3.3.1.1.  Processing an Attendee reply . . . . . . . . . . . 21
         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  . . . . . . . 22
         3.3.2.2.  Processing a scheduling message update . . . . . . 22
       3.3.3.  Processing by the client . . . . . . . . . . . . . . . 22
     3.4.  Explicit Scheduling Request  . . . . . . . . . . . . . . . 23
     3.5.  Other Considerations . . . . . . . . . . . . . . . . . . . 23
       3.5.1.  Handling recurring items . . . . . . . . . . . . . . . 23
         3.5.1.1.  Restricting what is sent . . . . . . . . . . . . . 23
         3.5.1.2.  Attendee overrides . . . . . . . . . . . . . . . . 23
       3.5.2.  Handling the Default Calendar  . . . . . . . . . . . . 24
       3.5.3.  DTSTAMP and SEQUENCE properties  . . . . . . . . . . . 24
       3.5.4.  Schedule Status Values . . . . . . . . . . . . . . . . 25
       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 Headers . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 31
   7.  New Preconditions  . . . . . . . . . . . . . . . . . . . . . . 32
     7.1.  Additional Preconditions for PUT, COPY and MOVE  . . . . . 32
     7.2.  Additional Preconditions for PUT . . . . . . . . . . . . . 32
     7.3.  Additional Precondition for DELETE . . . . . . . . . . . . 33
     7.4.  Additional Precondition for PROPPATCH  . . . . . . . . . . 33
   8.  Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     8.1.  POST Method  . . . . . . . . . . . . . . . . . . . . . . . 34



Daboo & Desruisseaux       Expires May 7, 2009                  [Page 2]

Internet-Draft               CalDAV Schedule               November 2008


       8.1.1.  Handling a REFRESH . . . . . . . . . . . . . . . . . . 35
       8.1.2.  Response to a POST request . . . . . . . . . . . . . . 35
       8.1.3.  Status Codes for use with the POST method  . . . . . . 36
       8.1.4.  Example - Simple meeting invitation refresh  . . . . . 37
       8.1.5.  Example - Freebusy lookup  . . . . . . . . . . . . . . 38
     8.2.  Retrieving incoming scheduling messages  . . . . . . . . . 39
   9.  Scheduling Access Control  . . . . . . . . . . . . . . . . . . 40
     9.1.  Scheduling Privileges  . . . . . . . . . . . . . . . . . . 40
       9.1.1.  Privileges on Scheduling Inbox Collections . . . . . . 40
         9.1.1.1.  CALDAV:schedule-deliver Privilege  . . . . . . . . 40
         9.1.1.2.  CALDAV:schedule-deliver-invite Privilege . . . . . 40
         9.1.1.3.  CALDAV:schedule-deliver-reply Privilege  . . . . . 41
         9.1.1.4.  CALDAV:schedule-query-freebusy Privilege . . . . . 41
       9.1.2.  Privileges on Scheduling Outbox Collections  . . . . . 41
         9.1.2.1.  CALDAV:schedule-send Privilege . . . . . . . . . . 41
         9.1.2.2.  CALDAV:schedule-send-invite Privilege  . . . . . . 41
         9.1.2.3.  CALDAV:schedule-send-reply Privilege . . . . . . . 42
         9.1.2.4.  CALDAV:schedule-send-freebusy Privilege  . . . . . 42
       9.1.3.  Aggregation of Scheduling Privileges . . . . . . . . . 42
     9.2.  Additional Principal Properties  . . . . . . . . . . . . . 43
       9.2.1.  CALDAV:schedule-inbox-URL Property . . . . . . . . . . 43
       9.2.2.  CALDAV:schedule-outbox-URL Property  . . . . . . . . . 43
       9.2.3.  CALDAV:calendar-user-address-set Property  . . . . . . 44
       9.2.4.  CALDAV:calendar-user-type Property . . . . . . . . . . 45
   10. Reports  . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
   11. XML Element Definitions  . . . . . . . . . . . . . . . . . . . 46
     11.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 46
     11.2. CALDAV:response XML Element  . . . . . . . . . . . . . . . 46
     11.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 47
     11.4. CALDAV:request-status XML Element  . . . . . . . . . . . . 47
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 47
     12.1. Verifying scheduling requests  . . . . . . . . . . . . . . 47
   13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 48
     13.1. HTTP header registration . . . . . . . . . . . . . . . . . 48
       13.1.1. Schedule-Reply Request Header Registration . . . . . . 49
     13.2. iCalendar Registrations  . . . . . . . . . . . . . . . . . 49
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 49
     15.2. Informative References . . . . . . . . . . . . . . . . . . 50
   Appendix A.  Scheduling Privileges Summary . . . . . . . . . . . . 50
     A.1.  Scheduling Inbox Privileges  . . . . . . . . . . . . . . . 50
     A.2.  Scheduling Outbox Privileges . . . . . . . . . . . . . . . 52
   Appendix B.  Changes (to be removed prior to publication as an
                RFC)  . . . . . . . . . . . . . . . . . . . . . . . . 54
     B.1.  Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 54
     B.2.  Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 55




Daboo & Desruisseaux       Expires May 7, 2009                  [Page 3]

Internet-Draft               CalDAV Schedule               November 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 a better consistency of the data in
   the users' calendars on the server.  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 May 7, 2009                  [Page 4]

Internet-Draft               CalDAV Schedule               November 2008


   o  Sending scheduling messages with the METHODs "PUBLISH", "COUNTER"
      and "DECLINE-COUNTER"

   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 [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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Daboo & Desruisseaux       Expires May 7, 2009                  [Page 5]

Internet-Draft               CalDAV Schedule               November 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 [RFC4791].

   Calendar object resource:  Same as [RFC4791].

   Scheduling object resource:  A calendar object resource contained in
      a calendar collection for which the server will take care of
      sending scheduling messages on behalf of the owner of the calendar
      collection.

   Organizer scheduling object resource:  A scheduling object resource
      owned by an Organizer.

   Attendee scheduling object resource:  A scheduling object resource
      owned by an Attendee.

   Automatic scheduling transaction:  Add, change or remove operations
      on a scheduling object resource for which the server will deliver
      scheduling messages to other users.

   Explicit scheduling request:  Scheduling requests targeted at a
      scheduling Outbox collection.

   Scheduling message:  A calendar object resource that describes a
      scheduling transaction such as publish, schedule, reschedule,
      respond to scheduling requests, or cancel calendar components.

   Scheduling Outbox collection:  A resource at which explicit
      scheduling requests are targeted.

   Scheduling Inbox collection:  A collection in which a recipient's
      incoming scheduling messages are delivered.

1.5.  Open Issues

   1.  Need to discuss in a limited fashion how group calendar user
       addresses might be handled.




Daboo & Desruisseaux       Expires May 7, 2009                  [Page 6]

Internet-Draft               CalDAV Schedule               November 2008


   2.  Need a mechanism to allow clients to be able to do "weak" If-
       Match updates to calendar data without the "strong" ETag
       behavior.

2.  CalDAV Scheduling Support

   In order for a server to support the scheduling extensions defined in
   this specification it MUST support all of the CalDAV calendar-access
   feature [RFC4791].

   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.

   In the first phase, the Organizer tries to determine a time for the
   meeting that ought to be acceptable to each Attendee.  This involves



Daboo & Desruisseaux       Expires May 7, 2009                  [Page 7]

Internet-Draft               CalDAV Schedule               November 2008


   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.  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.  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.

   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, iCalendar [RFC2445] also allows
   for sending "VTODO" and "VJOURNAL" components as described in iTIP
   [RFC2446].  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 operations defined in iTIP, except for "METHOD:
   COUNTER" and "METHOD:DECLINECOUNTER" which are not supported, are
   done via automatic scheduling transactions.





Daboo & Desruisseaux       Expires May 7, 2009                  [Page 8]

Internet-Draft               CalDAV Schedule               November 2008


3.1.  Scheduling Collections

   This specification introduces new collection resource types that are
   used for managing resources specific to scheduling, in addition to
   regular calendar object resources.

3.1.1.  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 "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:

          <resourcetype xmlns="DAV:">
            <collection/>
            <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
          </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 the following WebDAV
   properties defined (as per calendar collections in [RFC4791]):

      CALDAV:supported-calendar-component-set - when present this
      indicates the allowed calendar component types for scheduling
      messages submitted to the scheduling Outbox collection with the
      POST method.

      CALDAV:supported-calendar-data - when present this indicates the
      allowed media types for scheduling messages submitted to the
      scheduling Outbox collection with the POST method.





Daboo & Desruisseaux       Expires May 7, 2009                  [Page 9]

Internet-Draft               CalDAV Schedule               November 2008


      CALDAV:max-resource-size - when present this indicates the maximum
      size of a resource in octets that the server is willing to accept
      for scheduling messages submitted to the scheduling Outbox
      collection with the POST method.

      CALDAV:min-date-time - when present this indicates the earliest
      date and time (in UTC) that the server is willing to accept for
      any DATE or DATE-TIME value in scheduling messages submitted to
      the scheduling Outbox collection with the POST method.

      CALDAV:max-date-time - when present this indicates the latest date
      and time (in UTC) that the server is willing to accept for any
      DATE or DATE-TIME value in scheduling messages submitted to the
      scheduling Outbox collection with the POST method.

      CALDAV:max-instances - when present this indicates the maximum
      number of recurrence instances in scheduling messages submitted to
      the scheduling Outbox collection with the POST method.

      CALDAV:max-attendees-per-instance - when present this indicates
      the maximum number of ATTENDEE properties in any instance of
      scheduling messages submitted to the scheduling Outbox collection
      with the POST method.

3.1.2.  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:

          <resourcetype xmlns="DAV:">
            <collection/>
            <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
          </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,



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 10]

Internet-Draft               CalDAV Schedule               November 2008


   there are no restrictions on the nature of the resources stored
   (e.g., there is no need to verify that the "UID"s of 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.  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 the following WebDAV
   properties defined (as per calendar collections in [RFC4791]):

      CALDAV:calendar-timezone - 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.

      CALDAV:supported-calendar-component-set - when present this
      indicates the allowed calendar component types for scheduling
      messages delivered to the scheduling Inbox collection.

      CALDAV:supported-calendar-data - when present this indicates the
      allowed media types for scheduling messages delivered to the
      scheduling Inbox collection.

      CALDAV:max-resource-size - when present this indicates the maximum
      size of a resource in octets that the server is willing to accept
      for scheduling messages delivered to the scheduling Inbox
      collection.

      CALDAV:min-date-time - when present this indicates the earliest
      date and time (in UTC) that the server is willing to accept for
      any DATE or DATE-TIME value in scheduling messages delivered to
      the scheduling Inbox collection.

      CALDAV:max-date-time - when present this indicates the latest date
      and time (in UTC) that the server is willing to accept for any
      DATE or DATE-TIME value in scheduling messages delivered to the
      scheduling Inbox collection.




Daboo & Desruisseaux       Expires May 7, 2009                 [Page 11]

Internet-Draft               CalDAV Schedule               November 2008


      CALDAV:max-instances - when present this indicates the maximum
      number of recurrence instances in scheduling messages delivered to
      the scheduling Inbox collection.

      CALDAV:max-attendees-per-instance - when present this indicates
      the maximum number of ATTENDEE properties in any instance of
      scheduling messages delivered to the scheduling Inbox collection.

3.2.  Automatic Scheduling Transactions

3.2.1.  Introduction

   When a calendar object resource is created, modified or removed from
   a 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
   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
   calendar collection, and that at least one of the "ATTENDEE"
   iCalendar property values match one of the calendar user addresses of
   the owner of the calendar collection.

   The creation of attendee scheduling object resources will typically



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 12]

Internet-Draft               CalDAV Schedule               November 2008


   be done by the server in cases where a default calendar collection is
   defined (see Section 3.5.2.  In cases where no default 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 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
   fail.  In all cases, the server MUST add a "SCHEDULE-STATUS"
   iCalendar property parameter to the "ATTENDEE" iCalendar property in



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 13]

Internet-Draft               CalDAV Schedule               November 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 MAY 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 MAY 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".  To maintain
       consistency for organizers and attendees hosted on the server
       itself, a server will typically choose to enforce the requirement
       that only an Attendee can change their own "PARTSTAT" to a value
       other than "NEEDS-ACTION".

   2.  The server MUST reject any attempt to create a duplicate
       scheduling object resource in any of the 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.

   4.  Restrictions from [RFC4791] MUST also be enforced.

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 deliver a scheduling message to
   the Attendee.  The following table determines whether the server
   needs to deliver a scheduling message, and if so which iTIP
   scheduling method to use.  The values "SERVER", "CLIENT" and "NONE"



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 14]

Internet-Draft               CalDAV Schedule               November 2008


   in the top and left titles of the table refer to the "SCHEDULE-AGENT"
   parameter value of the "ATTENDEE" property, and the values "<Absent>"
   and "<Removed>" are used to cover the cases where the "ATTENDEE"
   property is not present (Old) or is being removed (New).

   +---------------+-----------------------------------------------+
   |               |                     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 MAY 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 server MAY 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".  To maintain
       consistency for organizers and attendees hosted on the server
       itself, a server will typically choose to enforce the requirement
       that only an Attendee can change their own "PARTSTAT" to a value
       other than "NEEDS-ACTION".

   2.  The server MUST take into account scheduling privileges when
       handling the modification of a scheduling object resources as



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 15]

Internet-Draft               CalDAV Schedule               November 2008


       described in Section Section 9.1.

   3.  Restrictions from [RFC4791] MUST also be enforced.

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.

   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.

3.2.3.2.1.  Actions on a Scheduling Object Resource

3.2.3.2.1.1.  Allowed Attendee Changes

   Attendees are allowed to make some changes to a scheduling object
   resource, though the key scheduling properties such as start, end,



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 16]

Internet-Draft               CalDAV Schedule               November 2008


   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.  modify the "PRODID" iCalendar property within the top-level
       "VCALENDAR" component.

   7.  add, modify or remove "CALSCALE" or "X-" iCalendar properties
       within the top-level "VCALENDAR" component.

   8.  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
   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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 17]

Internet-Draft               CalDAV Schedule               November 2008


   request.  As a result clients MAY 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 May 7, 2009                 [Page 18]

Internet-Draft               CalDAV Schedule               November 2008


   +--------------------------+--------------------------+-------------+
   | Existing Destination     | Resulting Destination    | Server      |
   | Resource                 | Resource                 | Action      |
   +--------------------------+--------------------------+-------------+
   | None                     | Calendar object resource | None (1)    |
   | None                     | Scheduling object        | Create (2)  |
   |                          | resource                 |             |
   | Calendar object resource | Calendar object resource | None        |
   | Calendar object resource | Scheduling object        | Create (1)  |
   |                          | resource                 |             |
   | Scheduling object        | Calendar object resource | Remove      |
   | resource                 |                          |             |
   | Scheduling object        | Scheduling object        | Modify      |
   | resource                 | resource                 |             |
   +--------------------------+--------------------------+-------------+

   Note 1.  The server MUST verify that no scheduling object resource
   exists in any other of the owner's calendar collections with the same
   UID as the resource being created.

   Note 2.  The server MUST verify that no calendar object resource
   exists in any other of the owner's calendar collections with the same
   UID as the resource being created.

3.2.3.3.2.  COPY

   When a COPY method request is received, the server will execute the
   following actions based on the source and destination collections in
   the request:

   +-------------------------+-------------------------+---------------+
   | Source Collection       | Destination Collection  | Server Action |
   +-------------------------+-------------------------+---------------+
   | Non-calendar collection | Non-calendar collection | None          |
   | Non-calendar collection | Calendar collection     | (1)           |
   | Calendar collection     | Non-calendar collection | None          |
   | Calendar collection     | Calendar collection     | (2)           |
   +-------------------------+-------------------------+---------------+

   Note 1.  The same rules as used for PUT above are applied for the
   destination of the COPY request.

   Note 2.  If the resource being copied is a scheduling object resource
   the server MUST generate an error as scheduling object resources
   cannot be duplicated.  If the resource being copied is not a
   scheduling object resource no server action occurs.





Daboo & Desruisseaux       Expires May 7, 2009                 [Page 19]

Internet-Draft               CalDAV Schedule               November 2008


3.2.3.3.3.  MOVE

   When a MOVE method request is received, the server will execute the
   following actions based on the source and destination collections in
   the request:

   +-------------------------+-------------------------+---------------+
   | Source Collection       | Destination Collection  | Server Action |
   +-------------------------+-------------------------+---------------+
   | Non-calendar collection | Non-calendar collection | None          |
   | Non-calendar collection | Calendar collection     | (1)           |
   | Calendar collection     | Non-calendar collection | (2)           |
   | Calendar collection     | Calendar collection     | (3)           |
   +-------------------------+-------------------------+---------------+

   Note 1.  The same rules as used for PUT above are applied for the
   destination of the MOVE request.

   Note 2.  The same rules as used for DELETE below are applied for the
   source of the MOVE request.

   Note 3.  If the destination resource does not exist the server action
   is None.  If the source and destination resources are not scheduling
   object resources then the server action is None.  In all other cases
   the server MUST generate an error as scheduling object resources
   cannot be duplicated or overwritten by different scheduling object
   resources.

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 calendar collection the server
   will execute the Remove action on all scheduling object resources
   contained in the 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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 20]

Internet-Draft               CalDAV Schedule               November 2008


   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.

   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.







Daboo & Desruisseaux       Expires May 7, 2009                 [Page 21]

Internet-Draft               CalDAV Schedule               November 2008


3.3.2.1.  Processing a new scheduling message

   When a scheduling message containing 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.

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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 22]

Internet-Draft               CalDAV Schedule               November 2008


       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 object
   resource contained in the Organizer's 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.

   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 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 in 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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 23]

Internet-Draft               CalDAV Schedule               November 2008


   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" calendar
   collection.  If a valid default 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 calendar collection chosen by the calendar user.
   Servers MAY prevent deletion of the default calendar.

   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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 24]

Internet-Draft               CalDAV Schedule               November 2008


   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:

   +----------+--------------------------------------------------------+
   | Delivery | Description                                            |
   | Status   |                                                        |
   | Code     |                                                        |
   +----------+--------------------------------------------------------+
   | 1.0      | The scheduling message is pending. i.e. 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 can 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.                |



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 25]

Internet-Draft               CalDAV Schedule               November 2008


   |          |                                                        |
   | 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
   [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 event may also be an Attendee of that
   event.  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







Daboo & Desruisseaux       Expires May 7, 2009                 [Page 26]

Internet-Draft               CalDAV Schedule               November 2008


   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
      user itself.  When "NONE" is specified, no scheduling messages are
      being sent to the calendar user.

      Servers MUST NOT include this parameter in any scheduling messages
      sent as the result of an automatic scheduling transaction.

      Clients SHOULD NOT include this parameter in any scheduling
      messages that they themselves send.

   Example:

      ATTENDEE;SCHEDULE-AGENT=SERVER:mailto:cyrus@example.org

4.2.  Schedule Status

   Parameter Name:  SCHEDULE-STATUS

   Purpose:  Indicates the status code returned from processing of the
      most recent scheduling message sent to the corresponding Attendee,
      or received from the corresponding Organizer.






Daboo & Desruisseaux       Expires May 7, 2009                 [Page 27]

Internet-Draft               CalDAV Schedule               November 2008


   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.

      Servers MUST NOT include this parameter in any scheduling messages
      sent as the result of an automatic scheduling transaction.

      Clients SHOULD NOT include this parameter in any scheduling
      messages that they themselves send.

      Suitable values for this property parameter are described in
      Section 3.5.4.

   Example:

      ATTENDEE;SCHEDULE-STATUS="2.0":mailto:cyrus@example.org

5.  New WebDAV Request Headers

   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 Attendee executes an HTTP DELETE request on a scheduling



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 28]

Internet-Draft               CalDAV Schedule               November 2008


   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 "REPLY" scheduling message with the Attendee's "PARTSTAT"
   iCalendar property parameter value set to "DECLINED" as part of its
   normal automatic scheduling transaction processing.

   When 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 "REPLY" 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.

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
      [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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 29]

Internet-Draft               CalDAV Schedule               November 2008


      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.

      If this property is not present on a calendar collection, then the
      default value of 'opaque' MUST be assumed.

   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>

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 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 calendar collection that is used as the default
      calendar.  When no DAV:href element is present, it indicates that



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 30]

Internet-Draft               CalDAV Schedule               November 2008


      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.

   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:








Daboo & Desruisseaux       Expires May 7, 2009                 [Page 31]

Internet-Draft               CalDAV Schedule               November 2008


   <!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 resource 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 MUST contain the same
      "ORGANIZER" 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 MAY
          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", or no "SCHEDULE-AGENT"
          parameter is present.

      2.  when modifying a scheduling object resource the Organizer MAY
          NOT change the "PARTSTAT" iCalendar parameter value to
          anything other than "NEEDS-ACTION" if the corresponding



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 32]

Internet-Draft               CalDAV Schedule               November 2008


          "ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar
          parameter with its value set to "SERVER", or no "SCHEDULE-
          AGENT" parameter is present.

      (CALDAV:allowed-attendee-scheduling-object-change): When creating
      or modifying a scheduling object resource 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.  change 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

      The Attendee MUST NOT make any other type of change.

7.3.  Additional Precondition for DELETE

   This specification require an additional Preconditions for the PUT
   method.  The preconditions are:

      (CALDAV:default-calendar-delete-allowed): The server MAY allow
      deletion of the default calendar collection.

7.4.  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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 33]

Internet-Draft               CalDAV Schedule               November 2008


      in any DAV:href element MUST reference a 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.1).

   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 versions of this
   specification, servers MAY return a valid schedule response result
   indicating success for the iTIP operation being executed.

   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 freebusy 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);



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 34]

Internet-Draft               CalDAV Schedule               November 2008


      (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;

   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
   submitted to the scheduling Outbox collection with the POST method.

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



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 35]

Internet-Draft               CalDAV Schedule               November 2008


   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
      collection being targeted by the POST request.



















Daboo & Desruisseaux       Expires May 7, 2009                 [Page 36]

Internet-Draft               CalDAV Schedule               November 2008


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
   DTSTAMP:20040901T200200Z
   ORGANIZER:mailto:lisa@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
    Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
    uisseaux:mailto:bernard@example.com
   END:VEVENT
   END:VCALENDAR

   >> Response <<

   HTTP/1.1 200 OK
   Date: Thu, 02 Sep 2004 16:53:32 GMT
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:schedule-response xmlns:D="DAV:"
                xmlns:C="urn:ietf:params:xml:ns:caldav">
   <C:response>
     <C:recipient>
       <D:href>mailto:lisa@example.com</D:href>
     </C:recipient>
     <C:request-status>2.0;Success</C:request-status>
     <D:responsedescription>Delivered to recipient
     scheduling inbox</D:responsedescription>
   </C:response>
   </C:schedule-response>

   In this example, the client requests the server to deliver a
   "REFRESH" scheduling message to the Organizer of the meeting
   mailto:lisa@example.com.  The response indicates that delivery to the
   relevant scheduling Inbox collection of the Organizer was
   accomplished successfully.




Daboo & Desruisseaux       Expires May 7, 2009                 [Page 37]

Internet-Draft               CalDAV Schedule               November 2008


8.1.5.  Example - Freebusy lookup

   >> Request <<

   POST /lisa/calendar/outbox/ HTTP/1.1
   Host: cal.example.com
   Content-Type: text/calendar
   Content-Length: xxxx

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   METHOD:REQUEST
   BEGIN:VFREEBUSY
   DTSTAMP:20040901T200200Z
   ORGANIZER:mailto:lisa@example.com
   DTSTART:20040902T000000Z
   DTEND:20040903T000000Z
   UID:34222-232@example.com
   ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
    example.com
   ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com
   END:VFREEBUSY
   END:VCALENDAR

   >> Response <<

   HTTP/1.1 200 OK
   Date: Thu, 02 Sep 2004 16:53:32 GMT
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:schedule-response xmlns:D="DAV:"
                xmlns:C="urn:ietf:params:xml:ns:caldav">
   <C:response>
     <C:recipient>
       <D:href>mailto:bernard@example.com<D:href>
     </C:recipient>
     <C:request-status>2.0;Success</C:request-status>
     <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   METHOD:REPLY
   BEGIN:VFREEBUSY
   DTSTAMP:20040901T200200Z
   ORGANIZER:mailto:lisa@example.com
   DTSTART:20040902T000000Z



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 38]

Internet-Draft               CalDAV Schedule               November 2008


   DTEND:20040903T000000Z
   UID:34222-232@example.com
   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>
       <D:href>mailto:cyrus@example.com<D:href>
     </C:recipient>
     <C:request-status>2.0;Success</C:request-status>
     <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   METHOD:REPLY
   BEGIN:VFREEBUSY
   DTSTAMP:20040901T200200Z
   ORGANIZER:mailto:lisa@example.com
   DTSTART:20040902T000000Z
   DTEND:20040903T000000Z
   UID:34222-232@example.com
   ATTENDEE;CN=Cyrus Daboo:mailto:cyrus@example.com
   FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
    20040902T090000Z,20040902T170000Z/20040903T000000Z
   FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z
   END:VFREEBUSY
   END:VCALENDAR
   </C:calendar-data>
   </C:response>
   </C:schedule-response>

   In this example, the client requests the server to determine the busy
   information of the calendar users mailto:bernard@example.com and
   mailto:cyrus@example.com, over the time range specified by the
   scheduling message sent in the request.  The response includes
   "VFREEBUSY" components for each of those calendar users with their
   busy time indicated.

8.2.  Retrieving incoming scheduling messages

   Incoming scheduling messages will be stored in a scheduling Inbox
   collection.  As per Section 10, CalDAV calendar-access reports work
   on scheduling collections, so the client can use those to get partial
   information on scheduling messages in the scheduling Inbox



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 39]

Internet-Draft               CalDAV Schedule               November 2008


   collection.

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 May 7, 2009                 [Page 40]

Internet-Draft               CalDAV Schedule               November 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 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 calendar collection or
   scheduling object resource in order to be allowed to create, modify



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 41]

Internet-Draft               CalDAV Schedule               November 2008


   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 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 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 May 7, 2009                 [Page 42]

Internet-Draft               CalDAV Schedule               November 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 [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 May 7, 2009                 [Page 43]

Internet-Draft               CalDAV Schedule               November 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 [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 [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 May 7, 2009                 [Page 44]

Internet-Draft               CalDAV Schedule               November 2008


   Example:

      <C:calendar-user-address-set xmlns:D="DAV:"
                            xmlns:C="urn:ietf:params:xml:ns:caldav">
        <D:href>mailto:bernard@example.com</D:href>
        <D:href>mailto:bernard.desruisseaux@example.com</D:href>
      </C:calendar-user-address-set>

9.2.4.  CALDAV:calendar-user-type Property

   Name:  calendar-user-type

   Namespace:  urn:ietf:params:xml:ns:caldav

   Purpose:  Identifies the calendar user type of the associated
      principal resource.

   Conformance:  This property MAY be protected and SHOULD NOT be
      returned by a PROPFIND allprop request (as defined in Section 14.2
      of [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 May 7, 2009                 [Page 45]

Internet-Draft               CalDAV Schedule               November 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 May 7, 2009                 [Page 46]

Internet-Draft               CalDAV Schedule               November 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 calendar
      collection in which a scheduling object resource is being
      manipulated.



Daboo & Desruisseaux       Expires May 7, 2009                 [Page 47]

Internet-Draft               CalDAV Schedule               November 2008


      Servers MUST verify that the principal associated with the DAV:
      owner of the 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 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 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 May 7, 2009                 [Page 48]

Internet-Draft               CalDAV Schedule               November 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 XXX.

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 May 7, 2009                 [Page 49]

Internet-Draft               CalDAV Schedule               November 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]  Bray, T., Paoli, J., Sperberg-McQueen, C.,
                           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 May 7, 2009                 [Page 50]

Internet-Draft               CalDAV Schedule               November 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 May 7, 2009                 [Page 51]

Internet-Draft               CalDAV Schedule               November 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 May 7, 2009                 [Page 52]

Internet-Draft               CalDAV Schedule               November 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 May 7, 2009                 [Page 53]

Internet-Draft               CalDAV Schedule               November 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.  Changes (to be removed prior to publication as an RFC)

B.1.  Changes in -06

   a.  Removed distinction between scheduling calendar collections and
       basic calendar collections - now just have calendar collections.

   b.  Clients now "MAY" reload data rather than "SHOULD" reload data.

   c.  Fixed <C:recipient> in examples.





Daboo & Desruisseaux       Expires May 7, 2009                 [Page 54]

Internet-Draft               CalDAV Schedule               November 2008


   d.  Removed CALDAV:attachments-allowed pre-condition on POST to
       Outbox as that is no longer relevant.

   e.  Added CALDAV:default-calendar-delete-allowed precondition for
       DELETE.

   f.  Relaxed MUST->MAY for Organizer setting PARTSTAT value.

   g.  Tweaked restrictions on Create/Modify to emphasize that 4791
       restrictions also apply.

   h.  Added comment that 'opaque' is the default when the CALDAV:
       schedule-calendar-transp property is not present.

   i.  Description of Schedule-Reply header changed to reflect that it
       is only relevant for Attendees.

   j.  Minor typos fixed.

B.2.  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
   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.












Daboo & Desruisseaux       Expires May 7, 2009                 [Page 55]

Internet-Draft               CalDAV Schedule               November 2008


Authors' Addresses

   Cyrus Daboo
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   EMail: cyrus@daboo.name
   URI:   http://www.apple.com/


   Bernard Desruisseaux
   Oracle Corporation
   600 Blvd. de Maisonneuve West
   Suite 1900
   Montreal, QC  H3A 3J2
   CANADA

   EMail: bernard.desruisseaux@oracle.com
   URI:   http://www.oracle.com/






























Daboo & Desruisseaux       Expires May 7, 2009                 [Page 56]

Internet-Draft               CalDAV Schedule               November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












Daboo & Desruisseaux       Expires May 7, 2009                 [Page 57]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/