Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4791

Calendaring Extensions to WebDAV (CalDAV)

Pages: 107
Proposed Standard
Errata
Updated by:  56896638676478097953
Part 3 of 5 – Pages 31 to 51
First   Prev   Next

Top   ToC   RFC4791 - Page 31   prevText

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.
Top   ToC   RFC4791 - Page 32

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.
Top   ToC   RFC4791 - Page 33
   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.
Top   ToC   RFC4791 - Page 34

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.
Top   ToC   RFC4791 - Page 35
   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.
Top   ToC   RFC4791 - Page 36

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
Top   ToC   RFC4791 - Page 37
      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.
Top   ToC   RFC4791 - Page 38
   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.
Top   ToC   RFC4791 - Page 39
   >> 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
Top   ToC   RFC4791 - Page 40
   <?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
Top   ToC   RFC4791 - Page 41
   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>
Top   ToC   RFC4791 - Page 42

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
Top   ToC   RFC4791 - Page 43
   <?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>
Top   ToC   RFC4791 - Page 44
         <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>
Top   ToC   RFC4791 - Page 45
     </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
Top   ToC   RFC4791 - Page 46
   <?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
Top   ToC   RFC4791 - Page 47
   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>
Top   ToC   RFC4791 - Page 48

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>
Top   ToC   RFC4791 - Page 49
   >> 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>
Top   ToC   RFC4791 - Page 50

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>
Top   ToC   RFC4791 - Page 51
   >> 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>



(page 51 continued on part 4)

Next Section