7.  Calendaring Reports

   This section defines the reports that CalDAV servers MUST support on
   calendar collections and calendar object resources.

   CalDAV servers MUST advertise support for these reports on all
   calendar collections and calendar object resources with the DAV:
   supported-report-set property, defined in Section 3.1.5 of [RFC3253].
   CalDAV servers MAY also advertise support for these reports on
   ordinary collections.

   Some of these reports allow calendar data (from possibly multiple
   resources) to be returned.

7.1.  REPORT Method

   The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
   extensible mechanism for obtaining information about one or more
   resources.  Unlike the PROPFIND method, which returns the value of
   one or more named properties, the REPORT method can involve more
   complex processing.  REPORT is valuable in cases where the server has
   access to all of the information needed to perform the complex
   request (such as a query), and where it would require multiple
   requests for the client to retrieve the information needed to perform
   the same request.

   CalDAV servers MUST support the DAV:expand-property REPORT defined in
   Section 3.8 of [RFC3253].

7.2.  Ordinary Collections

   Servers MAY support the reports defined in this document on ordinary
   collections (collections that are not calendar collections), in
   addition to calendar collections or calendar object resources.  In
   computing responses to the reports on ordinary collections, servers
   MUST only consider calendar object resources contained in calendar
   collections that are targeted by the REPORT request, based on the
   value of the Depth request header.

7.3.  Date and Floating Time

   iCalendar provides a way to specify DATE and DATE-TIME values that
   are not bound to any time zone in particular, hereafter called
   "floating date" and "floating time", respectively.  These values are
   used to represent the same day, hour, minute, and second value,
   regardless of which time zone is being observed.  For instance, the
   DATE value "20051111", represents November 11, 2005 in no specific
   time zone, while the DATE-TIME value "20051111T111100" represents
   November 11, 2005, at 11:11 A.M. in no specific time zone.

   CalDAV servers may need to convert "floating date" and "floating
   time" values in date with UTC time values in the processing of
   calendaring REPORT requests.

   For the CALDAV:calendar-query REPORT, CalDAV servers MUST rely on the
   value of the CALDAV:timezone XML element, if specified as part of the
   request body, to perform the proper conversion of "floating date" and
   "floating time" values to date with UTC time values.  If the CALDAV:
   timezone XML element is not specified in the request body, CalDAV
   servers MUST rely on the value of the CALDAV:calendar-timezone
   property, if defined, or else the CalDAV servers MAY rely on the time
   zone of their choice.

   For the CALDAV:free-busy-query REPORT, CalDAV servers MUST rely on
   the value of the CALDAV:calendar-timezone property, if defined, to
   compute the proper FREEBUSY time period value as date with UTC time
   for calendar components scheduled with "floating date" or "floating
   time".  If the CALDAV:calendar-timezone property is not defined,
   CalDAV servers MAY rely on the time zone of their choice.

7.4.  Time Range Filtering

   Some of the reports defined in this section can include a time range
   filter that is used to restrict the set of calendar object resources
   returned to just those that overlap the specified time range.  The
   time range filter can be applied to a calendar component as a whole,
   or to specific calendar component properties with DATE or DATE-TIME
   value types.

   To determine whether a calendar object resource matches the time
   range filter element, the start and end times for the targeted
   component or property are determined and then compared to the
   requested time range.  If there is an overlap with the requested time
   range, then the calendar object resource matches the filter element.
   The rules defined in [RFC2445] for determining the actual start and
   end times of calendar components MUST be used, and these are fully
   enumerated in Section 9.9 of this document.

   When such time range filtering is used, special consideration must be
   given to recurring calendar components, such as VEVENT and VTODO.
   The server MUST expand recurring components to determine whether any
   recurrence instances overlap the specified time range.  If one or
   more recurrence instances overlap the time range, then the calendar
   object resource matches the filter element.

7.5.  Searching Text: Collations

   Some of the reports defined in this section do text matches of
   character strings provided by the client and are compared to stored
   calendar data.  Since iCalendar data is, by default, encoded in the
   UTF-8 charset and may include characters outside the US-ASCII charset
   range in some property and parameter values, there is a need to
   ensure that text matching follows well-defined rules.

   To deal with this, this specification makes use of the IANA Collation
   Registry defined in [RFC4790] to specify collations that may be used
   to carry out the text comparison operations with a well-defined rule.

   The comparisons used in CalDAV are all "substring" matches, as per
   [RFC4790], Section 4.2.  Collations supported by the server MUST
   support "substring" match operations.

   CalDAV servers are REQUIRED to support the "i;ascii-casemap" and
   "i;octet" collations, as described in [RFC4790], and MAY support
   other collations.

   Servers MUST advertise the set of collations that they support via
   the CALDAV:supported-collation-set property defined on any resource
   that supports reports that use collations.

   Clients MUST only use collations from the list advertised by the
   server.

   In the absence of a collation explicitly specified by the client, or
   if the client specifies the "default" collation identifier (as
   defined in [RFC4790], Section 3.1), the server MUST default to using
   "i;ascii-casemap" as the collation.

   Wildcards (as defined in [RFC4790], Section 3.2) MUST NOT be used in
   the collation identifier.

   If the client chooses a collation not supported by the server, the
   server MUST respond with a CALDAV:supported-collation precondition
   error response.

7.5.1.  CALDAV:supported-collation-set Property

   Name:  supported-collation-set

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

   Purpose:  Identifies the set of collations supported by the server
      for text matching operations.

   Conformance:  This property MUST be defined on any resource that
      supports a report that does text matching.  If defined, it MUST be
      protected and SHOULD NOT be returned by a PROPFIND DAV:allprop
      request (as defined in Section 12.14.1 of [RFC2518]).

   Description:  The CALDAV:supported-collation-set property contains
      zero or more CALDAV:supported-collation elements, which specify
      the collection identifiers of the collations supported by the
      server.

   Definition:

         <!ELEMENT supported-collation-set (supported-collation*)>

         <!ELEMENT supported-collation (#PCDATA)>

   Example:

       <C:supported-collation-set
           xmlns:C="urn:ietf:params:xml:ns:caldav">
         <C:supported-collation>i;ascii-casemap</C:supported-collation>
         <C:supported-collation>i;octet</C:supported-collation>
       </C:supported-collation-set>

7.6.  Partial Retrieval

   Some calendaring reports defined in this document allow partial
   retrieval of calendar object resources.  A CalDAV client can specify
   what information to return in the body of a calendaring REPORT
   request.

   A CalDAV client can request particular WebDAV property values, all
   WebDAV property values, or a list of the names of the resource's
   WebDAV properties.  A CalDAV client can also request calendar data to
   be returned and specify whether all calendar components and
   properties should be returned, or only particular ones.  See CALDAV:
   calendar-data in Section 9.6.

   By default, the returned calendar data will include the component
   that defines the recurrence set, referred to as the "master
   component", as well as the components that define exceptions to the
   recurrence set, referred to as the "overridden components".

   A CalDAV client that is only interested in the recurrence instances
   that overlap a specified time range can request to receive only the
   "master component", along with the "overridden components" that
   impact the specified time range, and thus, limit the data returned by
   the server (see CALDAV:limit-recurrence-set in Section 9.6.6).  An
   overridden component impacts a time range if its current start and
   end times overlap the time range, or if the original start and end
   times -- the ones that would have been used if the instance were not
   overridden -- overlap the time range, or if it affects other
   instances that overlap the time range.

   A CalDAV client with no support for recurrence properties (i.e.,
   EXDATE, EXRULE, RDATE, and RRULE) and possibly VTIMEZONE components,
   or a client unwilling to perform recurrence expansion because of
   limited processing capability, can request to receive only the
   recurrence instances that overlap a specified time range as separate
   calendar components that each define exactly one recurrence instance
   (see CALDAV:expand in Section 9.6.5.)

   Finally, in the case of VFREEBUSY components, a CalDAV client can
   request to receive only the FREEBUSY property values that overlap a
   specified time range (see CALDAV:limit-freebusy-set in
   Section 9.6.7.)

7.7.  Non-Standard Components, Properties, and Parameters

   Servers MUST support the use of non-standard component, property, or
   parameter names in the CALDAV:calendar-data XML element in
   calendaring REPORT requests to allow clients to request that non-
   standard components, properties, and parameters be returned in the
   calendar data provided in the response.

   Servers MAY support the use of non-standard component, property, or
   parameter names in the CALDAV:comp-filter, CALDAV:prop-filter, and
   CALDAV:param-filter XML elements specified in the CALDAV:filter XML
   element of calendaring REPORT requests.

   Servers MUST fail with the CALDAV:supported-filter precondition if a
   calendaring REPORT request uses a CALDAV:comp-filter, CALDAV:prop-
   filter, or CALDAV:param-filter XML element that makes reference to a
   non-standard component, property, or parameter name on which the
   server does not support queries.

7.8.  CALDAV:calendar-query REPORT

   The CALDAV:calendar-query REPORT performs a search for all calendar
   object resources that match a specified filter.  The response of this
   report will contain all the WebDAV properties and calendar object
   resource data specified in the request.  In the case of the CALDAV:
   calendar-data XML element, one can explicitly specify the calendar
   components and properties that should be returned in the calendar
   object resource data that matches the filter.

   The format of this report is modeled on the PROPFIND method.  The
   request and response bodies of the CALDAV:calendar-query REPORT use
   XML elements that are also used by PROPFIND.  In particular, the
   request can include XML elements to request WebDAV properties to be
   returned.  When that occurs, the response should follow the same
   behavior as PROPFIND with respect to the DAV:multistatus response
   elements used to return specific property results.  For instance, a
   request to retrieve the value of a property that does not exist is an
   error and MUST be noted with a response XML element that contains a
   404 (Not Found) status value.

   Support for the CALDAV:calendar-query REPORT is REQUIRED.

   Marshalling:

      The request body MUST be a CALDAV:calendar-query XML element, as
      defined in Section 9.5.

      The request MAY include a Depth header.  If no Depth header is
      included, Depth:0 is assumed.

      The response body for a successful request MUST be a DAV:
      multistatus XML element (i.e., the response uses the same format
      as the response for PROPFIND).  In the case where there are no
      response elements, the returned DAV:multistatus XML element is
      empty.

      The response body for a successful CALDAV:calendar-query REPORT
      request MUST contain a DAV:response element for each iCalendar
      object that matched the search filter.  Calendar data is being
      returned in the CALDAV:calendar-data XML element inside the DAV:
      propstat XML element.

   Preconditions:

      (CALDAV:supported-calendar-data): The attributes "content-type"
      and "version" of the CALDAV:calendar-data XML element (see

      Section 9.6) specify a media type supported by the server for
      calendar object resources.

      (CALDAV:valid-filter): The CALDAV:filter XML element (see
      Section 9.7) specified in the REPORT request MUST be valid.  For
      instance, a CALDAV:filter cannot nest a <C:comp name="VEVENT">
      element in a <C:comp name="VTODO"> element, and a CALDAV:filter
      cannot nest a <C:time-range start="..." end="..."> element in a
      <C:prop name="SUMMARY"> element.

      (CALDAV:supported-filter): The CALDAV:comp-filter (see
      Section 9.7.1), CALDAV:prop-filter (see Section 9.7.2), and
      CALDAV:param-filter (see Section 9.7.3) XML elements used in the
      CALDAV:filter XML element (see Section 9.7) in the REPORT request
      only make reference to components, properties, and parameters for
      which queries are supported by the server, i.e., if the CALDAV:
      filter element attempts to reference an unsupported component,
      property, or parameter, this precondition is violated.  Servers
      SHOULD report the CALDAV:comp-filter, CALDAV:prop-filter, or
      CALDAV:param-filter for which it does not provide support.

            <!ELEMENT supported-filter (comp-filter*,
                                        prop-filter*,
                                        param-filter*)>

      (CALDAV:valid-calendar-data): The time zone specified in the
      REPORT request MUST be a valid iCalendar object containing a
      single valid VTIMEZONE component.

      (CALDAV:min-date-time): Any XML element specifying a range of time
      MUST have its start or end DATE or DATE-TIME values greater than
      or equal to the value of the CALDAV:min-date-time property value
      (Section 5.2.6) on the calendar collections being targeted by the
      REPORT request;

      (CALDAV:max-date-time): Any XML element specifying a range of time
      MUST have its start or end DATE or DATE-TIME values less than or
      equal to the value of the CALDAV:max-date-time property value
      (Section 5.2.7) on the calendar collections being targeted by the
      REPORT request;

      (CALDAV:supported-collation): Any XML attribute specifying a
      collation MUST specify a collation supported by the server as
      described in Section 7.5.

   Postconditions:

      (DAV:number-of-matches-within-limits): The number of matching
      calendar object resources must fall within server-specific,
      predefined limits.  For example, this condition might be triggered
      if a search specification would cause the return of an extremely
      large number of responses.

7.8.1.  Example: Partial Retrieval of Events by Time Range

   In this example, the client requests the server to return specific
   components and properties of the VEVENT components that overlap the
   time range from January 4, 2006, at 00:00:00 A.M. UTC to January 5,
   2006, at 00:00:00 A.M. UTC.  In addition, the DAV:getetag property is
   also requested and returned as part of the response.  Note that the
   first calendar object returned is a recurring event whose first
   instance lies outside the requested time range, but whose third
   instance does overlap the time range.  Note that due to the CALDAV:
   calendar-data element restrictions, the DTSTAMP property in VEVENT
   components has not been returned, and the only property returned in
   the VCALENDAR object is VERSION.

   See Appendix B for the calendar data being targeted by this example.

   >> Request <<

   REPORT /bernard/work/ HTTP/1.1
   Host: cal.example.com
   Depth: 1
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:calendar-query xmlns:D="DAV:"
                 xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop>
       <D:getetag/>
       <C:calendar-data>
         <C:comp name="VCALENDAR">
           <C:prop name="VERSION"/>
           <C:comp name="VEVENT">
             <C:prop name="SUMMARY"/>
             <C:prop name="UID"/>
             <C:prop name="DTSTART"/>
             <C:prop name="DTEND"/>
             <C:prop name="DURATION"/>
             <C:prop name="RRULE"/>
             <C:prop name="RDATE"/>
             <C:prop name="EXRULE"/>
             <C:prop name="EXDATE"/>
             <C:prop name="RECURRENCE-ID"/>
           </C:comp>
           <C:comp name="VTIMEZONE"/>
         </C:comp>
       </C:calendar-data>
     </D:prop>
     <C:filter>
       <C:comp-filter name="VCALENDAR">
         <C:comp-filter name="VEVENT">
           <C:time-range start="20060104T000000Z"
                         end="20060105T000000Z"/>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
   </C:calendar-query>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: application/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>http://cal.example.com/bernard/work/abcd2.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd2"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060102T120000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=5
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060104T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060106T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060106T120000
   SUMMARY:Event #2 bis bis
   UID:00959BC664CA650E933C892C@example.com

   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd3"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   DTSTART;TZID=US/Eastern:20060104T100000
   DURATION:PT1H
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>

7.8.2.  Example: Partial Retrieval of Recurring Events

   In this example, the client requests the server to return VEVENT
   components that overlap the time range from January 3, 2006, at 00:
   00:00 A.M. UTC to January 5, 2006, at 00:00:00 A.M. UTC.  Use of the
   CALDAV:limit-recurrence-set element causes the server to only return
   overridden recurrence components that overlap the time range
   specified in that element or that affect other instances that overlap
   the time range (e.g., in the case of a THISANDFUTURE behavior).  In
   this example, the first overridden component in the matching resource
   is returned, but the second one is not.

   See Appendix B for the calendar data being targeted by this example.

   >> Request <<

   REPORT /bernard/work/ HTTP/1.1
   Host: cal.example.com
   Depth: 1
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:calendar-query xmlns:D="DAV:"
                     xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop>
       <C:calendar-data>
         <C:limit-recurrence-set start="20060103T000000Z"
                                 end="20060105T000000Z"/>
       </C:calendar-data>
     </D:prop>
     <C:filter>
       <C:comp-filter name="VCALENDAR">
         <C:comp-filter name="VEVENT">
           <C:time-range start="20060103T000000Z"
                         end="20060105T000000Z"/>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
   </C:calendar-query>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: application/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>http://cal.example.com/bernard/work/abcd2.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd2"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART;TZID=US/Eastern:20060102T120000
   DURATION:PT1H
   RRULE:FREQ=DAILY;COUNT=5
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART;TZID=US/Eastern:20060104T140000
   DURATION:PT1H
   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>

         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd3"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTIMEZONE
   LAST-MODIFIED:20040110T032845Z
   TZID:US/Eastern
   BEGIN:DAYLIGHT
   DTSTART:20000404T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZNAME:EDT
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0400
   END:DAYLIGHT
   BEGIN:STANDARD
   DTSTART:20001026T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZNAME:EST
   TZOFFSETFROM:-0400
   TZOFFSETTO:-0500
   END:STANDARD
   END:VTIMEZONE
   BEGIN:VEVENT
   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
   DTSTAMP:20060206T001220Z
   DTSTART;TZID=US/Eastern:20060104T100000
   DURATION:PT1H
   LAST-MODIFIED:20060206T001330Z
   ORGANIZER:mailto:cyrus@example.com
   SEQUENCE:1
   STATUS:TENTATIVE
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>

     </D:response>
   </D:multistatus>

7.8.3.  Example: Expanded Retrieval of Recurring Events

   In this example, the client requests the server to return VEVENT
   components that overlap the time range from January 2, 2006, at 00:
   00:00 A.M. UTC to January 5, 2006, at 00:00:00 A.M. UTC and to return
   recurring calendar components expanded into individual recurrence
   instance calendar components.  Use of the CALDAV:expand element
   causes the server to only return overridden recurrence instances that
   overlap the time range specified in that element.

   See Appendix B for the calendar data being targeted by this example.

   >> Request <<

   REPORT /bernard/work/ HTTP/1.1
   Host: cal.example.com
   Depth: 1
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:calendar-query xmlns:D="DAV:"
                     xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop>
       <C:calendar-data>
         <C:expand start="20060103T000000Z"
                   end="20060105T000000Z"/>
       </C:calendar-data>
     </D:prop>
     <C:filter>
       <C:comp-filter name="VCALENDAR">
         <C:comp-filter name="VEVENT">
           <C:time-range start="20060103T000000Z"
                         end="20060105T000000Z"/>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
   </C:calendar-query>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: application/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>http://cal.example.com/bernard/work/abcd2.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd2"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060103T170000
   DURATION:PT1H
   RECURRENCE-ID:20060103T170000
   SUMMARY:Event #2
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   BEGIN:VEVENT
   DTSTAMP:20060206T001121Z
   DTSTART:20060104T190000
   DURATION:PT1H
   RECURRENCE-ID:20060104T170000
   SUMMARY:Event #2 bis
   UID:00959BC664CA650E933C892C@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
     <D:response>
       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd3"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VEVENT
   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
   DTSTAMP:20060206T001220Z
   DTSTART:20060104T150000
   DURATION:PT1H
   LAST-MODIFIED:20060206T001330Z

   ORGANIZER:mailto:cyrus@example.com
   SEQUENCE:1
   STATUS:TENTATIVE
   SUMMARY:Event #3
   UID:DC6C50A017428C5216A2F1CD@example.com
   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
   END:VEVENT
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>

7.8.4.  Example: Partial Retrieval of Stored Free Busy Components

   In this example, the client requests the server to return the
   VFREEBUSY components that have free busy information that overlap the
   time range from January 2, 2006, at 00:00:00 A.M. UTC (inclusively)
   to January 3, 2006, at 00:00:00 A.M. UTC (exclusively).  Use of the
   CALDAV:limit-freebusy-set element causes the server to only return
   the FREEBUSY property values that overlap the time range specified in
   that element.  Note that this is not an example of discovering when
   the calendar owner is busy.

   See Appendix B for the calendar data being targeted by this example.

   >> Request <<

   REPORT /bernard/work/ HTTP/1.1
   Host: cal.example.com
   Depth: 1
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:calendar-query xmlns:D="DAV:"
                 xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop>
       <C:calendar-data>
         <C:limit-freebusy-set start="20060102T000000Z"
                                 end="20060103T000000Z"/>
       </C:calendar-data>
     </D:prop>
     <C:filter>
       <C:comp-filter name="VCALENDAR">
         <C:comp-filter name="VFREEBUSY">
           <C:time-range start="20060102T000000Z"
                           end="20060103T000000Z"/>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
   </C:calendar-query>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: application/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>http://cal.example.com/bernard/work/abcd8.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd8"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VFREEBUSY
   ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
   UID:76ef34-54a3d2@example.com
   DTSTAMP:20050530T123421Z
   DTSTART:20060101T100000Z
   DTEND:20060108T100000Z
   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
   END:VFREEBUSY
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>

7.8.5.  Example: Retrieval of To-Dos by Alarm Time Range

   In this example, the client requests the server to return the VTODO
   components that have an alarm trigger scheduled in the specified time
   range.

   See Appendix B for the calendar data being targeted by this example.

   >> Request <<

   REPORT /bernard/work/ HTTP/1.1
   Host: cal.example.com
   Depth: 1
   Content-Type: application/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop xmlns:D="DAV:">
       <D:getetag/>
       <C:calendar-data/>
     </D:prop>
     <C:filter>
       <C:comp-filter name="VCALENDAR">
         <C:comp-filter name="VTODO">
           <C:comp-filter name="VALARM">
             <C:time-range start="20060106T100000Z"
                             end="20060107T100000Z"/>
           </C:comp-filter>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
   </C:calendar-query>

   >> Response <<

   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: application/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>http://cal.example.com/bernard/work/abcd4.ics</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"fffff-abcd4"</D:getetag>
           <C:calendar-data>BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Example Corp.//CalDAV Client//EN
   BEGIN:VTODO
   DTSTAMP:20060205T235300Z
   DUE;TZID=US/Eastern:20060106T120000
   LAST-MODIFIED:20060205T235308Z
   SEQUENCE:1
   STATUS:NEEDS-ACTION
   SUMMARY:Task #2
   UID:E10BA47467C5C69BB74E8720@example.com
   BEGIN:VALARM
   ACTION:AUDIO
   TRIGGER;RELATED=START:-PT10M
   END:VALARM
   END:VTODO
   END:VCALENDAR
   </C:calendar-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>