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) 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)
Section 9.7) specified in the REPORT request MUST be valid. For
instance, a CALDAV:filter cannot nest a
(CALDAV
supported-filter) 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.
(CALDAV
valid-calendar-data) REPORT request MUST be a valid iCalendar object containing a single valid VTIMEZONE component.
(CALDAV
min-date-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) 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) collation MUST specify a collation supported by the server as described in Section 7.5.
Postconditions:
(DAV
number-of-matches-within-limits) 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.