Network Working Group                                           C. Daboo
Internet-Draft
Expires: November 24, 2006                               B. Desruisseaux
                                                                  Oracle
                                                            L. Dusseault
                                                                    OSAF
                                                            May 23, 2006


                    Scheduling Extensions to CalDAV
                   draft-desruisseaux-caldav-sched-01

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 November 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies a set of methods, headers and resource types
   that define the scheduling extension to the CalDAV protocol.  CalDAV
   itself extends WebDAV, which extends HTTP.  The new protocol elements
   defined here allow interoperable scheduling operations on a CalDAV
   repository.



Daboo, et al.           Expires November 24, 2006               [Page 1]


Internet-Draft                   CalDAV                         May 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  XML Namespaces . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Notational Conventions . . . . . . . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Required Scheduling features . . . . . . . . . . . . . . . . .  5
   3.  CalDAV Scheduling Support Discovery  . . . . . . . . . . . . .  5
     3.1.  Example: Using OPTIONS for the Discovery of Support
           for CalDAV . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Scheduling Process . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Scheduling Collections . . . . . . . . . . . . . . . . . .  7
     4.2.  Scheduling Transactions  . . . . . . . . . . . . . . . . .  8
   5.  New Resource Types and Properties  . . . . . . . . . . . . . .  9
     5.1.  Scheduling Inbox Collection  . . . . . . . . . . . . . . .  9
     5.2.  Scheduling Outbox Collection . . . . . . . . . . . . . . . 10
     5.3.  Scheduling Inbox Properties  . . . . . . . . . . . . . . . 11
       5.3.1.  CALDAV:calendar-free-busy-set Property . . . . . . . . 11
     5.4.  Calendar Object Resource Properties  . . . . . . . . . . . 11
       5.4.1.  CALDAV:originator Property . . . . . . . . . . . . . . 12
       5.4.2.  CALDAV:recipient Property  . . . . . . . . . . . . . . 12
       5.4.3.  CALDAV:schedule-state Property . . . . . . . . . . . . 13
   6.  Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  SCHEDULE Method  . . . . . . . . . . . . . . . . . . . . . 14
       6.1.1.  Originator request header  . . . . . . . . . . . . . . 15
       6.1.2.  ORGANIZER Property . . . . . . . . . . . . . . . . . . 16
       6.1.3.  Recipient request header . . . . . . . . . . . . . . . 16
       6.1.4.  Response to a SCHEDULE request . . . . . . . . . . . . 17
       6.1.5.  Status Codes for use with the SCHEDULE method  . . . . 17
       6.1.6.  Example - Simple meeting invitation  . . . . . . . . . 19
       6.1.7.  Example - Free-Busy lookup . . . . . . . . . . . . . . 20
     6.2.  Retrieving incoming scheduling messages  . . . . . . . . . 21
       6.2.1.  Example - Retrieve incoming scheduling message . . . . 21
     6.3.  Acting on incoming scheduling messages . . . . . . . . . . 22
   7.  HTTP Request Headers for CalDAV  . . . . . . . . . . . . . . . 22
     7.1.  Originator Request Header  . . . . . . . . . . . . . . . . 22
     7.2.  Recipient Request Header . . . . . . . . . . . . . . . . . 23
   8.  Scheduling Access Control  . . . . . . . . . . . . . . . . . . 23
     8.1.  Scheduling Privileges  . . . . . . . . . . . . . . . . . . 23
       8.1.1.  CALDAV:schedule Privilege  . . . . . . . . . . . . . . 23
       8.1.2.  Privilege aggregation and the
               DAV:supported-privilege-set property . . . . . . . . . 25
     8.2.  Additional Principal Properties  . . . . . . . . . . . . . 25
       8.2.1.  CALDAV:schedule-inbox-URL Property . . . . . . . . . . 25
       8.2.2.  CALDAV:schedule-outbox-URL Property  . . . . . . . . . 26
       8.2.3.  CALDAV:calendar-user-address-set Property  . . . . . . 26
       8.2.4.  Example: Searching for calendars belonging to a
               user based on a calendar user address  . . . . . . . . 27



Daboo, et al.           Expires November 24, 2006               [Page 2]


Internet-Draft                   CalDAV                         May 2006


       8.2.5.  Example: Finding the scheduling Inbox and Outbox
               belonging to the currently authenticated user  . . . . 29
   9.  Using CalDAV Reports . . . . . . . . . . . . . . . . . . . . . 29
   10. XML Element Definitions  . . . . . . . . . . . . . . . . . . . 29
     10.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 29
     10.2. CALDAV:response XML Element  . . . . . . . . . . . . . . . 29
     10.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 30
     10.4. CALDAV:request-status XML Element  . . . . . . . . . . . . 30
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 31
     11.1. Verifying scheduling requests  . . . . . . . . . . . . . . 31
   12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 31
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   14. Normative References . . . . . . . . . . . . . . . . . . . . . 32
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 33
     A.1.  Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 35


































Daboo, et al.           Expires November 24, 2006               [Page 3]


Internet-Draft                   CalDAV                         May 2006


1.  Introduction

   This document specifies a set of methods, headers, properties and
   privileges that define the CalDAV [I-D.dusseault-caldav] scheduling
   extensions to the WebDAV [I-D.ietf-webdav-rfc2518bis] protocol.  This
   document also provides the transport specific information necessary
   to convey iCalendar [RFC2445] Transport-independent Interoperability
   Protocol iTIP [RFC2446] over WebDAV which enables transactions such
   as publish, schedule, reschedule, respond to scheduling requests,
   negotiation of changes or cancel iCalendar-based calendar components,
   as well as search for available busy time information.

   Discussion of this Internet-Draft is taking place on the mailing list
   <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

1.1.  XML Namespaces

   Definitions of XML elements in this document use XML element type
   declarations (as found in XML Document Type Declarations), described
   in Section 3.2 of [W3C.REC-xml-20040204].

   The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
   elements defined in this specification, or in other Standards Track
   IETF RFCs written to extend CalDAV.  It MUST NOT be used for
   proprietary extensions.

   Note that the XML declarations used in this document are incomplete,
   in that they do not include namespace information.  Thus, the reader
   MUST NOT use these declarations as the only way to create valid
   CalDAV properties or to validate CalDAV XML element types.  Some of
   the declarations refer to XML elements defined by WebDAV which use
   the "DAV:" namespace.  Wherever such elements appear, they are
   explicitly given the "DAV:" prefix to help avoid confusion.
   Additionally, some of the elements used here are defined in CalDAV
   [I-D.dusseault-caldav].

   Also note that some CalDAV XML element names are identical to WebDAV
   XML element names, though their namespace differs.  Care MUST be
   taken not to confuse the two sets of names.

1.2.  Notational Conventions

   The augmented BNF used by this document to describe protocol elements
   is described in Section 2.1 of [RFC2616].  Because this augmented BNF
   uses the basic production rules provided in Section 2.2 of [RFC2616],
   those rules apply to this document as well.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",



Daboo, et al.           Expires November 24, 2006               [Page 4]


Internet-Draft                   CalDAV                         May 2006


   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   When XML element types in the namespaces "DAV:" and
   "urn:ietf:params:xml:ns:caldav" are referenced in this document
   outside of the context of an XML fragment, the string "DAV:" and
   "CALDAV:" will be prefixed to the element types respectively.

1.3.  Terminology

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

   Free busy message: A message that describes a transaction such as
      publish unsolicited busy time information, request busy time
      information, or respond to a busy time request.


2.  Required Scheduling features

   This section lists what functionality is required of a CalDAV
   scheduling server.  To advertise support for this specification a
   server:

   o  MUST support the CalDAV calendar-access feature [I-D.dusseault-
      caldav].

   o  MUST support the CALDAV:schedule privilege.

   o  MUST support the CALDAV:schedule-inbox and CALDAV:schedule-outbox
      collection resource types.

   o  MUST support the SCHEDULE method and the Recipient and Originator
      request headers.

   o  MUST support iTIP [RFC2446].


3.  CalDAV Scheduling Support Discovery

   If the server supports the calendar scheduling features described in
   this document it MUST include "calendar-schedule" as a field in the
   DAV response header from an OPTIONS request on any resource that
   supports any scheduling properties, privileges or methods.






Daboo, et al.           Expires November 24, 2006               [Page 5]


Internet-Draft                   CalDAV                         May 2006


3.1.  Example: Using OPTIONS for the Discovery of Support for CalDAV

   >> Request <<

   OPTIONS /lisa/calendar/outbox/ HTTP/1.1
   Host: cal.example.com

   >> Response <<

   HTTP/1.1 200 OK
   Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
   Allow: MKCOL, PROPFIND, PROPPATCH, REPORT, SCHEDULE, ACL
   DAV: 1, 3, access-control, calendar-access, calendar-schedule
   Content-Length: 0

   In this example, the OPTIONS response indicates that the server
   supports both the calendar-access and calendar-schedule features and
   that /lisa/calendar/outbox/ can be specified as a Request-URI to the
   SCHEDULE method.


4.  Scheduling Process

   The process of scheduling a meeting between different parties often
   involves a series of steps with different "actors" playing particular
   roles during the whole process.  Typically there is a meeting
   "Organizer" whose role is to setup a meeting between one or more
   meeting "Attendees", and this is done by sending out invitations and
   handling responses from each Attendee.

   This process can typically be broken down into two phases.

   In the first phase the "Organizer" tries to determine a time for the
   meeting that ought to be the most acceptable to each Attendee.  This
   involves finding out when each Attendee is available during the
   period of time in which the meeting needs to occur, and determining
   when the most appropriate time is for which each Attendee is free.
   This process is called a "free-busy" lookup.

   In the second phase the "Organizer" sends out invitations to each
   Attendee using the time determined from the free-busy lookup - or a
   suitable guess as to an appropriate time based on other factors if
   free-busy lookup is not feasible.  There then follows a process of
   negotiation between "Organizer" and "Attendees" regarding the
   invitation.  Some Attendees may choose to attend at the original time
   provided by the Organizer, others may decline to attend at that time,
   but suggest another time, others may decline to attend at any time.
   The "Organizer" needs to process each of the replies from the



Daboo, et al.           Expires November 24, 2006               [Page 6]


Internet-Draft                   CalDAV                         May 2006


   Attendees and take appropriate action to confirm the meeting,
   reschedule it or perhaps cancel it depending on those replies.

   The user "expectation" as to how a calendaring and scheduling system
   should respond in each of these two phases is somewhat different.  In
   the case of a free-busy lookup, users expect to get back results
   immediately so that they can then move on to the invitation phase as
   quickly as possible.  In the case of invitations, its expected that
   each Attendee will reply in his or her own time, so delays in
   receiving replies are anticipated.  Thus calendaring and scheduling
   systems should treat these two operational phases in different ways
   to accommodate the user expectations, and this specification does
   that.

4.1.  Scheduling Collections

   It is useful for each participant in a scheduling transaction to
   maintain their own "history" of invitations sent and received during
   the process and after to keep track of what was done, and to properly
   handle updates to invitations as they may change over time.  This
   history is usually kept separate from the actual "booked" event,
   to-do, or daily journal entry, which would normally be placed in a
   user's calendar collection.

   In addition, it is useful to keep outgoing invitations separate from
   incoming ones for organizational purposes.

   Also, a calendar user may have multiple calendars representing
   different spheres of activity, but scheduling requests are targeted
   at calendar user addresses, and there is no formal way to have those
   indicate which sphere of activity they might apply to.  By storing
   all incoming scheduling requests in a separate collection, clients
   can process the requests in that collection and choose what calendar
   the request belongs to and make its own arrangements to place the
   relevant calendar object in that calendar to "book" it.

   This specification introduces two new collection resource types that
   are used for keeping incoming and outgoing scheduling messages
   separate from other calendar object resources.  These can also be
   used to control who is able to send scheduling messages on behalf of
   a user, and who is allowed to send scheduling messages to other users
   by the use of new WebDAV ACL [RFC3744] privileges.  Note that these
   collections only contains scheduling messages that pertains to the
   scheduling of events, to-dos and daily journal entries.  Scheduling
   messages that describes requests for available busy time information,
   or replies to such request, are not contained in these collections.

   The scheduling "Inbox" collection contains received scheduling



Daboo, et al.           Expires November 24, 2006               [Page 7]


Internet-Draft                   CalDAV                         May 2006


   messages.  Scheduling messages are contained in calendar object
   resources.  Each calendar object resource has a WebDAV property that
   indicates whether the scheduling message has already been processed
   or not so that multiple clients do not repeat the processing actions
   already done.

   The scheduling "Outbox" collection contains scheduling message that
   have been sent, which need to be tracked both to help synchronize
   between multiple clients and to support delegation use cases.  A
   single user with multiple clients can use this collection to
   synchronize the outbound request history.  Two users coordinating
   scheduling with one calendar (e.g., a calendar user and her
   assistant) can see what scheduling messages the other user has sent.
   The calendar owner would then typically have permission to DELETE the
   scheduling messages but the assistant might not.

4.2.  Scheduling Transactions

   The iCalendar Transport-independent Interoperability Protocol (iTIP)
   [RFC2446] outlines a model for scheduling and free-busy message
   exchanges to perform scheduling transactions.  This specification
   makes use of scheduling free-busy messages to handle scheduling
   transactions on the server by having such messages passed between
   different users on the server depending on their role in the
   scheduling process.

   To that end each scheduling message is modeled as a calendar object
   resource which contains the iCalendar object that conforms to the
   iTIP requirements for the type of transaction being requested.

   This specification defines the SCHEDULE method, acting on an
   Organizer's scheduling Outbox, to trigger schedule processing by the
   server.  This can take one of two forms: for free-busy messages the
   SCHEDULE request returns immediately with free busy results; for
   scheduling messages, a copy of the scheduling message specified in
   the request body is deposited into each recipient's scheduling Inbox.

   The server may support delivery of scheduling messages to other
   CalDAV servers, and the client may attempt to get the server to do
   this by specifying remote addresses for the recipients, but the
   server is not bound to support or complete remote delivery operations
   even if it advertises support for the "calendar-schedule" feature.
   Note that remote delivery mechanisms are not defined in this
   specification.  This specification does not define a server-to-server
   or server-to-client protocol to deliver scheduling messages.
   Implementations may do this in a proprietary way, with iMIP
   [RFC2447], or with iTIP bindings as yet unspecified.




Daboo, et al.           Expires November 24, 2006               [Page 8]


Internet-Draft                   CalDAV                         May 2006


   After the delivery is completed, CalDAV clients will see the
   scheduling message the next time they synchronize or query a
   scheduling Inbox collection.  To reply to a scheduling REQUEST, the
   client uses the SCHEDULE method to send another scheduling message
   (this time, a REPLY) back to the Organizer.  If the user has decided
   to accept the REQUEST, the client can create a suitable calendar
   object resource in the appropriate calendar collection for the
   recipient.  The step of putting the calendar object resource in the
   calendar is left up to the client, so that the client can make
   appropriate choices about where to put the calendar object resource,
   and with what alarms, etc.  However, the server MAY be configured to
   automatically accept or reject invitations, and if the server auto-
   accepts invitations then the server is responsible for creating
   calendar object resources in a calendar collection specified by the
   user.


5.  New Resource Types and Properties

   The CalDAV scheduling extension defines the following new resource
   types for use with CalDAV.

5.1.  Scheduling Inbox Collection

   A scheduling Inbox collection contains incoming scheduling messages.
   These may be requests sent by an Organizer, or replies sent by an
   Attendee in response to a request.

   A scheduling Inbox collection MUST report the DAV:collection and
   CALDAV:schedule-inbox XML elements in the value of the DAV:
   resourcetype property.  The element type declaration for CALDAV:
   schedule-inbox is:

      <!ELEMENT schedule-inbox EMPTY>

   Example:

      <resourcetype xmlns="DAV:">
        <collection/>
        <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
      </resourcetype>

   Every non-collection resource in the scheduling Inbox collection MUST
   be a valid calendar object resource that defines a scheduling message
   (e.g., an iCalendar object that follows the iTIP semantic).  Note,
   that unlike calendar collections defined by the calendar-access
   feature, there are no restrictions on the nature of the resources
   stored (e.g., there is no need to verify that the UIDs in each



Daboo, et al.           Expires November 24, 2006               [Page 9]


Internet-Draft                   CalDAV                         May 2006


   resource are unique) beyond the restrictions of iTIP itself.  The
   removal of the UID restriction, in particular, is needed because
   multiple scheduling messages may be sent for one particular calendar
   component, and each of those will have the same UID property in the
   calendar object resource.

   A new access control privilege can be defined on the scheduling Inbox
   collection and can be used to control who is allowed to send
   scheduling messages to the owner of the scheduling Inbox.  See
   Section 8.1 for more details.

5.2.  Scheduling Outbox Collection

   A scheduling Outbox collection contains outgoing scheduling messages.
   These may be requests initiated by or on behalf of the owner of the
   scheduling Outbox, or responses to requests received by the owner of
   the scheduling Outbox.

   A scheduling Outbox collection MUST report the DAV:collection and
   CALDAV:schedule-outbox XML elements in the value of the DAV:
   resourcetype property.  The element type declaration for CALDAV:
   schedule-outbox is:

      <!ELEMENT schedule-outbox EMPTY>

   Example:

      <resourcetype xmlns="DAV:">
        <collection/>
        <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
      </resourcetype>

   Every non-collection resource in the scheduling Outbox collection
   MUST be a valid calendar object resource that defines a scheduling
   message (e.g., an iCalendar object that follows the iTIP semantic).
   When a client targets the SCHEDULE method at a scheduling Outbox, the
   server MUST create a copy of the scheduling message in that
   scheduling Outbox, unless the SCHEDULE method corresponds to a free-
   busy message, in which case the server MUST NOT store a copy of the
   free-busy message.  Copies that are created serve as a record of
   outgoing scheduling messages.

   The server MAY auto-delete calendar object resources in the
   scheduling Outbox (e.g., after a period of time or to keep within a
   quota).  The server SHOULD allow deletion of calendar object
   resources in the scheduling Outbox.

   A new access control privilege can be defined on the scheduling



Daboo, et al.           Expires November 24, 2006              [Page 10]


Internet-Draft                   CalDAV                         May 2006


   Outbox collection and can be used to control who is allowed to send
   scheduling messages on behalf of the owner of the scheduling Outbox.
   See Section 8.1 for more details.

5.3.  Scheduling Inbox Properties

   This section describes new WebDAV properties on scheduling Inbox
   collection resources.

5.3.1.  CALDAV:calendar-free-busy-set Property

   Name: calendar-free-busy-set

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

   Purpose: Identify the calendars that contribute to the free-busy
      information for the owner of the scheduling Inbox.

   Conformance: This property MAY be protected and SHOULD NOT be
      returned by a PROPFIND allprop request (as defined in Section
      12.14.1 of [I-D.ietf-webdav-rfc2518bis]).  Support for this
      property is REQUIRED.

   Description: This property is required to allow a SCHEDULE request to
      automatically determine the free busy information for each
      specified Recipient for immediate return in the response.  A
      server with a fixed set of calendars per user can make this
      property protected.  A server that allows users to create their
      own calendars SHOULD allow users to change their own property
      value.

   Definition:

      <!ELEMENT calendar-free-busy-set (DAV:href*) >

   Example:

      <C:calendar-free-busy-set xmlns:D="DAV:"
                            xmlns:C="urn:ietf:params:xml:ns:caldav">
        <D:href>/calendars/bernard/work/</D:href>
        <D:href>/calendars/bernard/home/</D:href>
        <D:href>/public/holidays/CA/</D:href>
      </C:calendar-free-busy-set>

5.4.  Calendar Object Resource Properties

   This section describes new WebDAV properties for calendar object
   resources stored in scheduling Inbox or Outbox collections.



Daboo, et al.           Expires November 24, 2006              [Page 11]


Internet-Draft                   CalDAV                         May 2006


5.4.1.  CALDAV:originator Property

   Name: originator

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

   Purpose: Indicates the Originator of the scheduling message contained
      in a scheduling Inbox or Outbox collection.

   Conformance: This property MUST be protected and SHOULD NOT be
      returned by a PROPFIND DAV:allprop request (as defined in Section
      14.2 of [I-D.ietf-webdav-rfc2518bis]).

   Description: The CALDAV:originator property MUST be defined on
      calendar object resources stored in an Inbox or Outbox collection
      as the result of a SCHEDULE request.  The value of the property
      MUST be the value of the Originator request header in the SCHEDULE
      request that caused the resource to be created in the collection.

   Definition:

      <!ELEMENT originator (DAV:href)>
      DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])

   Example:

      <C:originator xmlns:D="DAV:"
                    xmlns:C="urn:ietf:params:xml:ns:caldav">
        <D:href>mailto:bernard@example.com</D:href>
      </C:originator>

5.4.2.  CALDAV:recipient Property

   Name: recipient

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

   Purpose: On a calendar object resource contained in a scheduling
      Outbox collection, this indicates the list of Recipients to whom
      the scheduling message was sent.  On a calendar object resource in
      a scheduling Inbox collection, this indicates the recipient
      calendar user address that caused the scheduling message to be
      delivered into the scheduling Inbox.

   Conformance: This property MUST be protected and SHOULD NOT be
      returned by a PROPFIND DAV:allprop request (as defined in Section
      14.2 of [I-D.ietf-webdav-rfc2518bis]).




Daboo, et al.           Expires November 24, 2006              [Page 12]


Internet-Draft                   CalDAV                         May 2006


   Description: The CALDAV:recipient property MUST be defined on
      calendar object resources stored in a scheduling Outbox or Inbox
      collection as the result of a SCHEDULE request.  For calendar
      object resources in a scheduling Outbox, the value of the property
      MUST be a list of calendar user addresses formed from all the
      addresses in any Recipient request headers in the SCHEDULE request
      that caused the resource to be created in the collection.  For
      calendar object resources in a scheduling Inbox, the value of the
      property MUST be the calendar user address from the Recipient
      request header in the SCHEDULE request that caused the resource to
      be created in the collection.  Typically this address will be one
      of those listed in the CALDAV:calendar-user-address-set (see
      Section 8.2.3) property for the principal that owns the scheduling
      Inbox.  However, it could, for example, be a calendar user address
      of a group that includes the owner of the scheduling Inbox.

   Definition:


      <!ELEMENT recipient (DAV:href+)>
      DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])


   Example:

      <C:recipient xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:caldav">
        <D:href>mailto:cyrus@example.com</D:href>
        <D:href>mailto:lisa@example.com</D:href>
      </C:recipient>

5.4.3.  CALDAV:schedule-state Property

   Name: schedule-state

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

   Purpose: Indicates the state of a scheduling message in a scheduling
      Inbox.

   Conformance: This property MAY be protected and SHOULD NOT be
      returned by a PROPFIND DAV:allprop request (as defined in Section
      14.2 of [I-D.ietf-webdav-rfc2518bis]).

   Description: The CALDAV:schedule-state property MUST be defined on
      any calendar object resource in a scheduling Inbox collection.  If
      present, the property indicates whether the scheduling message has
      been processed or not.  Processing might have occurred as a result



Daboo, et al.           Expires November 24, 2006              [Page 13]


Internet-Draft                   CalDAV                         May 2006


      of some form of automatic processing by the server or through a
      client action.  Clients MUST ensure that they set this property
      value to indicate a processed state when they have processed the
      scheduling message.  This ensures that other clients with access
      to the same resource don't attempt to repeat the actions required
      to reply.  Clients MUST NOT process a scheduling message that has
      this property indicates the scheduling message has been processed.
      When the scheduling message is delivered into the scheduling Inbox
      the server MUST set this property value to indicate that the
      scheduling message has not been processed.

   Definition:

      <!ELEMENT schedule-state (not-processed|processed)>

      <!ELEMENT not-processed EMPTY>
      <!ELEMENT processed EMPTY>

   Example:

      <C:schedule-state xmlns:C="urn:ietf:params:xml:ns:caldav">
        <C:processed/>
      </C:schedule-state>


6.  Scheduling

6.1.  SCHEDULE Method

   The SCHEDULE method submits a scheduling or free-busy message to one
   or more recipients by targeting the request at the URI of a
   scheduling Outbox collection.  The request body of a SCHEDULE method
   MUST contain a scheduling message or free-busy message (e.g., an
   iCalendar object that follows the iTIP semantic).  The resource
   identified by the Request-URI MUST be a resource collection of type
   CALDAV:schedule-outbox (Section 5.2).

   A submitted scheduling message will be delivered to the calendar user
   addresses specified in the Recipient request header.  A submitted
   free-busy message will be immediatly excecuted and a free-busy
   response returned.

   Preconditions:

      (CALDAV:supported-collection): The Request-URI MUST identify the
      location of a scheduling Outbox collection;





Daboo, et al.           Expires November 24, 2006              [Page 14]


Internet-Draft                   CalDAV                         May 2006


      (CALDAV:supported-calendar-data): The resource submitted in the
      SCHEDULE request MUST be a supported media type (i.e., text/
      calendar) for scheduling or free-busy messages;

      (CALDAV:valid-calendar-data): The resource submitted in the
      SCHEDULE request MUST be valid data for the media type being
      specified (i.e., valid iCalendar object);

      (CALDAV:valid-scheduling-message): The resource submitted in the
      SCHEDULE request MUST obey all restrictions specified for the
      SCHEDULE request (e.g., scheduling message follows the restriction
      of iTIP);

      (CALDAV:originator-specified): The SCHEDULE request MUST include a
      valid Originator request header specifying a calendar user address
      of the currently authenticated user;

      (CALDAV:originator-allowed): The calendar user identified by the
      Originator request header in the SCHEDULE request MUST be granted
      the CALDAV:schedule privilege on the scheduling Outbox collection
      being targeted by the request;

      (CALDAV:organizer-allowed): The calendar user identified by the
      ORGANIZER property in the SCHEDULE request's scheduling message
      MUST be the owner (or one of the owners) of the scheduling Outbox
      being targeted by the request;

      (CALDAV:recipient-specified): The SCHEDULE request MUST include
      one or more valid Recipient request headers specifying the
      calendar user address of users to whom the scheduling message will
      be delivered.

   Postconditions: None

6.1.1.  Originator request header

   Every SCHEDULE request MUST include an Originator request header that
   specifies the calendar user address of the originator of a given
   scheduling message.  The value specified in this request header MUST
   be a calendar user address specified in the CALDAV:calendar-user-
   address-set property defined on the principal resource of the
   currently authenticated user.  Also, the currently authenticated user
   MUST have the CALDAV:schedule privilege granted on the targetted
   scheduling Outbox collection.

   Typically the Originator request header's value will correspond to
   the Organizer of the calendar component and to the owner of the
   Outbox being targeted by the request.  However, the Organizer may



Daboo, et al.           Expires November 24, 2006              [Page 15]


Internet-Draft                   CalDAV                         May 2006


   choose to allow another user to act on his behalf to send scheduling
   messages.  To allow for this a new privilege has been defined to
   allow the owner of a scheduling Outbox to grant to other users the
   right to execute SCHEDULE requests on that Outbox.

   The value of the Originator request header is kept in the CALDAV:
   originator property on any resources saved as a result of the
   schedule request.  This includes the copy of the scheduling message
   saved in the scheduling Outbox, and scheduling messages delivered to
   any scheduling Inbox.

6.1.2.  ORGANIZER Property

   iTIP requires that every scheduling message contains an ORGANIZER
   property identifying the calendar user address of the Organizer of
   the calendar object.  To prevent 'spoofing' (forgeries) of scheduling
   messages, CalDAV servers MUST verify that the calendar user address
   identified by the ORGANIZER property in the scheduling message data
   corresponds to the principal owning the scheduling Outbox targeted by
   the SCHEDULE request.  This MUST be done during the processing of the
   SCHEDULE request.

6.1.3.  Recipient request header

   Every SCHEDULE request MUST include one or more Recipient request
   headers in the headers.  The value of this header is a list of one or
   more calendar user addresses and corresponds to the set of calendar
   users who will be delivered the scheduling message.  The owner of the
   scheduling Outbox being targeted by the SCHEDULE method MUST have the
   CALDAV:schedule privilege granted on the scheduling Inbox collection
   of each recipient.

   Typically the list of recipients would correspond to any ATTENDEE
   property values listed in the scheduling message data.  However,
   there are cases when an ATTENDEE is not listed as a Recipient, or
   when a Recipient is not one of the ATTENDEE's.

   For example, if the Organizer of an event wishes to attend the event
   themselves, they must list themselves as one of the ATTENDEE's, as
   the ORGANIZER of an event does not implicitly attend.  However, the
   Organizer does not need to receive an invitation as they know their
   own participation status, so there is no need to be listed as a
   Recipient of the scheduling message.

   Alternatively, a client may have determined participation status of
   some ATTENDEE's out-of-band and has no need to send another request
   via CalDAV.




Daboo, et al.           Expires November 24, 2006              [Page 16]


Internet-Draft                   CalDAV                         May 2006


   In some cases it is handy to be able to send information about a
   meeting to someone who is not an ATTENDEE.  In that case, there would
   be a Recipient in the request without a corresponding ATTENDEE
   property in the scheduling message data.

   Note that the recipient of a CalDAV scheduling message has no
   knowledge of who the other recipients were - they only get to see the
   ATTENDEE information listed in the scheduling message data.  So
   listing a calendar user as a Recipient and not an ATTENDEE is the
   equivalent of a 'Bcc' (blind-carbon-copy) operation in email.

6.1.4.  Response to a SCHEDULE request

   A SCHEDULE request may deliver a scheduling message to one or more
   calendar users specified in the Recipient request header.  Since the
   behavior of each recipient may vary, it is useful to get response
   status information for each recipient in the overall SCHEDULE
   response.  This specification defines a new XML response to convey
   multiple recipient status.

   A response to a SCHEDULE method that indicates status for one or more
   recipients MUST be a CALDAV:schedule-response XML element.  This MUST
   contain one or more CALDAV:response elements for each recipient, with
   each of those containing elements that indicate which recipient they
   correspond to, the scheduling status of the request for that
   recipient, any error codes and an optional description.  See
   Section 10.1.

   In the case of a free-busy request, the CALDAV:response elements can
   also contain CALDAV:calendar-data elements which contain free busy
   information (e.g., an iCalenedar VFREEBUSY component) indicating the
   busy state of the corresponding recipient, assuming that the free-
   busy request for that recipient succeeded.

6.1.5.  Status Codes for use with the SCHEDULE method

   The following are examples of response codes one would expect to be
   used for this method.  Note, however, that unless explicitly
   prohibited any 2/3/4/5xx series response code may be used in a
   response.

   200 (OK) - The command succeeded.

   400 (Bad Request) - The client has provided an invalid scheduling
   message.

   403 (Forbidden) - The client, for reasons the server chooses not to
   specify, cannot submit a scheduling message to the specified Request-



Daboo, et al.           Expires November 24, 2006              [Page 17]


Internet-Draft                   CalDAV                         May 2006


   URI.

   404 (Not Found) - The URL in the Request-URI, the Originator, or the
   Recipient request headers were not present.

   423 (Locked) - The specified resource is locked and the client either
   is not a lock owner or the lock type requires a lock token to be
   submitted and the client did not submit it.

   502 (Bad Gateway) - The Recipient request header contained a URL
   which the server considers to be in another domain, which it cannot
   forward scheduling messages to.

   507 (Insufficient Storage) - The server did not have sufficient space
   to record the scheduling message in a recipient's scheduling inbox.




































Daboo, et al.           Expires November 24, 2006              [Page 18]


Internet-Draft                   CalDAV                         May 2006


6.1.6.  Example - Simple meeting invitation

   >> Request <<


   SCHEDULE /lisa/calendar/outbox/ HTTP/1.1
   Host: cal.example.com
   Originator: mailto:lisa@example.com
   Recipient: mailto:bernard@example.com
   Recipient: mailto:cyrus@example.com
   Content-Type: text/calendar
   Content-Length: xxxx

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   METHOD:REQUEST
   BEGIN:VEVENT
   DTSTAMP:20040901T200200Z
   ORGANIZER:mailto:lisa@example.com
   DTSTART:20040902T130000Z
   DTEND:20040902T140000Z
   SUMMARY:Design meeting
   UID:34222-232@example.com
   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
    IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.c
    om
   ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
    Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
    uisseaux:mailto:bernard@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
    Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
    mailto:cyrus@example.com
   END:VEVENT
   END:VCALENDAR
















Daboo, et al.           Expires November 24, 2006              [Page 19]


Internet-Draft                   CalDAV                         May 2006


   >> Response <<


   HTTP/1.1 200 OK
   Date: Thu, 02 Sep 2004 16:53:32 GMT
   Content-Type: text/xml
   Content-Length: xxxx

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


   In this example, the client requests the server to deliver a meeting
   invitation (scheduling REQUEST) to the calendar users
   mailto:bernard@example.com and mailto:cyrus@example.com.  The
   response indicates that delivery to the relevant scheduling Inboxes
   of each recipient was accomplished successfully.

   Note that the Originator and Organizer calendar user addresses were
   both set to mailto:lisa@example.com.  In order to indicate that she
   is also attending the meeting, mailto:lisa@example.com also included
   an ATTENDEE property in the iCalendar data corresponding to her
   calendar user address, however she did not include a Recipient
   request header for that calendar user address since she already has
   here own copy of the meeting stored in a calendar collection.

6.1.7.  Example - Free-Busy lookup

   TODO:

   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



Daboo, et al.           Expires November 24, 2006              [Page 20]


Internet-Draft                   CalDAV                         May 2006


   VFREEBUSY components for each of those calendar users with their busy
   time indicated.

6.2.  Retrieving incoming scheduling messages

   Incoming scheduling messages will be stored in a scheduling Inbox
   collection.  The same reports work on scheduling collections, so the
   client can use REPORT to get partial information on scheduling
   messages in the scheduling inbox.

6.2.1.  Example - Retrieve incoming scheduling message

   >> Request <<


   GET /bernard/calendar/inbox/mtg456.ics HTTP/1.1
   Host: cal.example.com


































Daboo, et al.           Expires November 24, 2006              [Page 21]


Internet-Draft                   CalDAV                         May 2006


   >> Response <<


   HTTP/1.1 200 OK
   Date: Thu, 02 Sep 2004 17:05:23 GMT
   Content-Type: text/calendar
   Content-Length: xxxx

   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Server//EN
   METHOD:REQUEST
   BEGIN:VEVENT
   DTSTAMP:20040901T200200Z
   CATEGORIES:APPOINTMENT
   ORGANIZER:mailto:lisa@example.com
   DTSTART:20040902T130000Z
   DTEND:20040902T140000Z
   SUMMARY:CalDAV draft review
   UID:34222-232@example.com
   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
    IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
    ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:
    mailto:bernard@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
    ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:mailto:cyr
    us@example.com
   END:VEVENT
   END:VCALENDAR


6.3.  Acting on incoming scheduling messages

   TODO: Need to explain here how to handle incoming scheduling
   messages.  If the client wants to accept a message, it needs to
   create an event and mark the calendar object resource as "processed".
   If the client wants to reject it, it simply changes a property.  Need
   to define that property.  Also recommend locking the Inbox resource
   to avoid race conditions with other clients -- or use ETags to
   verify.


7.  HTTP Request Headers for CalDAV

7.1.  Originator Request Header





Daboo, et al.           Expires November 24, 2006              [Page 22]


Internet-Draft                   CalDAV                         May 2006


      Originator = "Originator" ":" absoluteURI


   The Originator request header value is a URI which specifies the
   calendar user address of the originator of the scheduling message.
   Note that the absoluteURI production is defined in RFC2396 [RFC2396].

7.2.  Recipient Request Header


      Recipient = "Recipient" ":" 1#absoluteURI


   The Recipient request header value is a URI which specifies the
   calendar user address of the recipients to which the SCHEDULE method
   should deliver the submitted scheduling message.  Note that the
   absoluteURI production is defined in RFC2396 [RFC2396]


8.  Scheduling Access Control

8.1.  Scheduling Privileges

   A CalDAV server MUST support the WebDAV ACLs standard [RFC3744].
   That standard provides a framework for an extensible list of
   privileges on WebDAV collections and ordinary resources.  A CalDAV
   server MUST also support the set of calendar-specific privileges
   defined in this section.

8.1.1.  CALDAV:schedule Privilege

   The CALDAV:schedule privilege can be applied to either a scheduling
   Outbox or Inbox.  Its effect depends on the type of collection it is
   applied to.

   When used on a scheduling Outbox, the CALDAV:schedule privilege
   controls the use of the SCHEDULE method to submit a scheduling
   message via a scheduling Outbox collection.  A calendar owner will
   generally have the CALDAV:schedule privilege granted on their own
   outbox and never grant that privilege to anybody else.  If the
   privilege is granted to somebody other than the calendar owner, that
   person is effectively somebody who can issue invitations or replies
   on behalf of the calendar owner.  Thus, if a server receives a
   SCHEDULE request where the authenticated sender does not have the
   CALDAV:schedule privilege granted on the Request-URI, the server MUST
   reject the request.

   When used on a scheduling Inbox, the CALDAV:schedule privilege



Daboo, et al.           Expires November 24, 2006              [Page 23]


Internet-Draft                   CalDAV                         May 2006


   governs whether a user may cause new calendar object resources
   (scheduling messages) to be created in the collection as a result of
   a SCHEDULE request on that user's own scheduling Outbox.  It is
   similar to the WebDAV DAV:bind privilege but more restricted, because
   it only allows the user to create new resources as a side-effect of
   the SCHEDULE method fanout process.  Thus, the CALDAV:schedule
   privilege determines whether an event Organizer is allowed to send an
   invitation to an Attendee and have it appear in that Attendee's
   scheduling Inbox.

   <!ELEMENT schedule EMPTY >

   For example, the following ACE, on Bernard's scheduling Outbox, would
   only grant the privilege to Bernard to schedule on behalf of himself:


   <D:ace xmlns:D="DAV:"
        xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:principal>
         <D:href>http://cal.example.com/users/bernard</D:href>
     </D:principal>
     <D:grant>
       <D:privilege><C:schedule/></D:privilege>
     </D:grant>
   </D:ace>


   Whereas, the following ACE's, on Cyrus's scheduling Outbox, would
   grant the privilege to Cyrus and his assistant Kim to schedule on
   behalf of Cyrus:


   <D:ace xmlns:D="DAV:"
        xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:principal>
         <D:href>http://cal.example.com/users/cyrus</D:href>
     </D:principal>
     <D:grant>
       <D:privilege><C:schedule/></D:privilege>
     </D:grant>
   </D:ace>
   <D:ace xmlns:D="DAV:"
        xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:principal>
         <D:href>http://cal.example.com/users/kim</D:href>
     </D:principal>
     <D:grant>
       <D:privilege><C:schedule/></D:privilege>



Daboo, et al.           Expires November 24, 2006              [Page 24]


Internet-Draft                   CalDAV                         May 2006


     </D:grant>
   </D:ace>


   For example, the following ACE's, on Bernard's scheduling Inbox,
   would grant the privilege to Lisa to send an invitation to Bernard:


   <D:ace xmlns:D="DAV:"
        xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:principal>
         <D:href>http://cal.example.com/users/lisa</D:href>
     </D:principal>
     <D:grant>
       <D:privilege><C:schedule/></D:privilege>
     </D:grant>
   </D:ace>


8.1.2.  Privilege aggregation and the DAV:supported-privilege-set
        property

   The CALDAV:schedule privilege MUST be non-abstract, and MUST be
   aggregated under the DAV:bind privilege.  The CALDAV:schedule
   privilege MUST appear in the DAV:supported-privilege-set property of
   scheduling Inbox and Outbox collections.

8.2.  Additional Principal Properties

   This section defines new properties for WebDAV principal resources as
   defined in RFC3744 [RFC3744].  These properties are likely to be
   protected but the server MAY allow them to be written by appropriate
   users.

8.2.1.  CALDAV:schedule-inbox-URL Property

   Name: schedule-inbox-URL

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

   Purpose: Identify the URL of the scheduling Inbox collection owned by
      the associated principal resource.

   Conformance: This property MAY be protected and SHOULD NOT be
      returned by a PROPFIND allprop request (as defined in Section
      12.14.1 of [I-D.ietf-webdav-rfc2518bis]).





Daboo, et al.           Expires November 24, 2006              [Page 25]


Internet-Draft                   CalDAV                         May 2006


   Description: This property is needed for a client to determine where
      the scheduling Inbox of the current user is located so that
      processing of scheduling messages can occur.

   Definition:

      <!ELEMENT schedule-inbox-URL (href)>

8.2.2.  CALDAV:schedule-outbox-URL Property

   Name: schedule-outbox-URL

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

   Purpose: Identify the URL of the scheduling Outbox collection owned
      by the associated principal resource.

   Conformance: This property MAY be protected and SHOULD NOT be
      returned by a PROPFIND allprop request (as defined in Section
      12.14.1 of [I-D.ietf-webdav-rfc2518bis]).

   Description: This property is needed for a client to determine where
      the scheduling Outbox of the current user is located so that
      sending of scheduling messages can occur.

   Definition:

      <!ELEMENT schedule-outbox-URL href>

8.2.3.  CALDAV:calendar-user-address-set Property

   Name: calendar-user-address-set

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

   Purpose: Identify the calendar addresses of the associated principal
      resource.

   Conformance: This property MAY be protected and SHOULD NOT be
      returned by a PROPFIND allprop request (as defined in Section
      12.14.1 of [I-D.ietf-webdav-rfc2518bis] ).  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.







Daboo, et al.           Expires November 24, 2006              [Page 26]


Internet-Draft                   CalDAV                         May 2006


   Description: This property is needed to map Originator and Recipient
      values in a SCHEDULE request to principal resources and their
      associated scheduling Inbox and Outbox.  In the event that a user
      has no well defined identifier for their calendar user address,
      the URI of their principal resource can be used.

   Definition:


      <!ELEMENT calendar-user-address-set (DAV:href*)>


   Example:


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


8.2.4.  Example: Searching for calendars belonging to a user based on a
        calendar user address

   In this example, the client requests the CALDAV:calendar-home-URL of
   the principal resources whose CALDAV:calendar-user-address-set
   property contains the substring "mailto:bernard@example.com".  In
   addition, the client requests the DAV:displayname of each principal
   to also be returned for the matching principals.

   The response shows that only one principal resource meets the search
   specification, "mailto:bernard@example.com".


















Daboo, et al.           Expires November 24, 2006              [Page 27]


Internet-Draft                   CalDAV                         May 2006


   >> Request <<


   REPORT /users/ HTTP/1.1
   Host: cal.example.com
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx
   Depth: 0

   <?xml version="1.0" encoding="utf-8" ?>
   <D:principal-property-search xmlns:D="DAV:"
               xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:property-search>
       <D:prop>
         <C:calendar-user-address-set/>
       </D:prop>
       <D:match>mailto:bernard@example.com</D:match>
     </D:property-search>
     <D:prop>
       <C:calendar-home-URL/>
       <D:displayname/>
     </D:prop>
   </D:principal-property-search>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset=utf-8
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:"
            xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:response>
       <D:href>/users/bernard</D:href>
       <D:propstat>
         <D:prop>
           <C:calendar-home-URL>
             <D:href>/home/bernard/</D:href>
           </C:calendar-home-URL>
           <D:displayname>Bernard Desruisseaux</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>





Daboo, et al.           Expires November 24, 2006              [Page 28]


Internet-Draft                   CalDAV                         May 2006


8.2.5.  Example: Finding the scheduling Inbox and Outbox belonging to
        the currently authenticated user

   In this example, the client requests the CALDAV:schedule-inbox-URL
   and CALDAV:schedule-outbox-URL of the currently authenticated user.

   TODO: principal-match report


9.  Using CalDAV Reports

   This specification extends the CALDAV:calendar-query and CALDAV:
   calendar-multiget reports to return results for calendar object
   resources in scheduling Inbox and Outbox collections when the report
   directly targets such a collection. i.e. the Request-URI for a REPORT
   MUST be the URI of the scheduling Inbox or Outbox or of a child
   resource within a scheduling Inbox or Outbox collection.  A report
   run on a regular collection that includes a scheduling Inbox or
   Outbox as a child resource at any depth MUST NOT examine or return
   any calendar object resources from within any scheduling Inbox or
   Outbox collections.

   Note that the CALDAV:free-busy-query report is NOT supported on
   scheduling Inbox or Outbox collections.


10.  XML Element Definitions

10.1.  CALDAV:schedule-response XML Element

   Name: schedule-response

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

   Purpose: Contains the set of responses for a SCHEDULE method request.

   Description: See Section 6.1.4.

   Definition:


       <!ELEMENT schedule-response (response*)>


10.2.  CALDAV:response XML Element






Daboo, et al.           Expires November 24, 2006              [Page 29]


Internet-Draft                   CalDAV                         May 2006


   Name: response

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

   Purpose: Contains a single response for a SCHEDULE method request.

   Description: See Section 6.1.4.

   Definition:

   <!ELEMENT response (recipient,
                       request-status,
                       calendar-data?,
                       DAV:error?,
                       DAV:responsedescription?)>

10.3.  CALDAV:recipient XML Element

   Name: recipient

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

   Purpose: The calendar user address (recipient header value) that the
      enclosing response for a SCHEDULE method request is for.

   Description: See Section 6.1.4.

   Definition:


       <!ELEMENT recipient (#PCDATA)>


10.4.  CALDAV:request-status XML Element

   Name: request-status

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

   Purpose: The iTIP REQUEST-STATUS property value for this response.

   Description: See Section 6.1.4.

   Definition:


       <!ELEMENT request-status (#PCDATA)>




Daboo, et al.           Expires November 24, 2006              [Page 30]


Internet-Draft                   CalDAV                         May 2006


11.  Security Considerations

   The process of scheduling involves the sending and receiving of
   scheduling messages.  As a result, the security problems related to
   messaging in general are relevant here.  In particular the
   authenticity of the scheduling messages needs to be verified
   absolutely.  Servers and clients MUST use an HTTP connection
   protected with TLS as defined in [RFC2818] for all scheduling
   transactions.

11.1.  Verifying scheduling requests

   When handling a SCHEDULE request on a scheduling Outbox:

      Servers MUST verify that the principal associated with the
      calendar user address specified in the Originator request header
      in the request matches the currently authenticated user.

      Servers MUST verify that the currently authenticated user has the
      CALDAV:schedule privilege on the scheduling Outbox targeted by the
      request.

      Servers MUST verify that the principal associated with the
      calendar user address specified in the ORGANIZER property of the
      scheduling message data in the request contains a CALDAV:schedule-
      outbox-URL property value that matches the scheduling Outbox
      targeted by the request.

      Servers MUST verify that the principal associated with the
      calendar user address specified in the ORGANIZER property of the
      scheduling message data in the request has the CALDAV:schedule
      privilege on all of the scheduling Inbox collections for the
      principals associated with all of the calendar user addresses
      specified in any Recipient request headers in the request.

      The CALDAV:calendar-free-busy-set property on principal resources
      SHOULD only be accessible when that principal is authenticated
      (i.e., the property SHOULD be hidden from other principals).


12.  IANA Consideration

   This specification does not require any IANA actions.


13.  Acknowledgements

   The authors would like to thank the following individuals for



Daboo, et al.           Expires November 24, 2006              [Page 31]


Internet-Draft                   CalDAV                         May 2006


   contributing their ideas and support for writing this specification:
   Julian F. Reschke and Jim Whitehead.

14.  Normative References

   [I-D.dusseault-caldav]
              Dusseault, L., "Calendaring Extensions to WebDAV
              (CalDAV)", draft-dusseault-caldav-12 (work in progress),
              April 2006.

   [I-D.ietf-webdav-rfc2518bis]
              Dusseault, L., "HTTP Extensions for Distributed Authoring
              - WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in
              progress), May 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC2445]  Dawson, F. and Stenerson, D., "Internet Calendaring and
              Scheduling Core Object Specification (iCalendar)",
              RFC 2445, November 1998.

   [RFC2446]  Silverberg, S., Mansour, S., Dawson, F., and R. Hopson,
              "iCalendar Transport-Independent Interoperability Protocol
              (iTIP) Scheduling Events, BusyTime, To-dos and Journal
              Entries", RFC 2446, November 1998.

   [RFC2447]  Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
              Message-Based Interoperability Protocol (iMIP)", RFC 2447,
              November 1998.

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

   [W3C.REC-xml-20040204]
              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third



Daboo, et al.           Expires November 24, 2006              [Page 32]


Internet-Draft                   CalDAV                         May 2006


              Edition)", W3C REC REC-xml-20040204, February 2004.


Appendix A.  Changes

A.1.  Changes in -01

   a.  Updated to latest references including 2518bis.

   b.  Added principal property CALDAV:calendar-user-address-set.

   c.  Major changes to schedule method, including addition of
       preconditions.

   d.  New principal properties added.

   e.  Text related to alternative ways of doing scheduling (some
       speculative) removed.

   f.  Added Security Considerations text.

   g.  Added IANA consideration text.





























Daboo, et al.           Expires November 24, 2006              [Page 33]


Internet-Draft                   CalDAV                         May 2006


Authors' Addresses

   Cyrus Daboo

   Email: cyrus@daboo.name


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

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


   Lisa Dusseault
   Open Source Application Foundation
   2064 Edgewood Dr.
   Palo Alto, CA  94303
   US

   Email: lisa@osafoundation.org
   URI:   http://www.osafoundation.org/

























Daboo, et al.           Expires November 24, 2006              [Page 34]


Internet-Draft                   CalDAV                         May 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Daboo, et al.           Expires November 24, 2006              [Page 35]