diff options
Diffstat (limited to 'rfcs/RFC 4791 - Calendaring Extensions to WebDAV (CalDAV).html')
| -rw-r--r-- | rfcs/RFC 4791 - Calendaring Extensions to WebDAV (CalDAV).html | 6064 |
1 files changed, 6064 insertions, 0 deletions
diff --git a/rfcs/RFC 4791 - Calendaring Extensions to WebDAV (CalDAV).html b/rfcs/RFC 4791 - Calendaring Extensions to WebDAV (CalDAV).html new file mode 100644 index 0000000..a0a7c98 --- /dev/null +++ b/rfcs/RFC 4791 - Calendaring Extensions to WebDAV (CalDAV).html @@ -0,0 +1,6064 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> +<meta http-equiv="content-type" content="text/html; charset=UTF-8"> + <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> + <meta name="robots" content="index,follow"> + <meta name="creator" content="rfcmarkup version 1.111"> + <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> +<meta name="DC.Identifier" content="urn:ietf:rfc:4791"> +<meta name="DC.Description.Abstract" content="This document defines extensions to the Web Distributed Authoring and +Versioning (WebDAV) protocol to specify a standard way of accessing, +managing, and sharing calendaring and scheduling information based on +the iCalendar format. This document defines the " calendar-access feature of caldav.> +<meta name="DC.Creator" content="Dusseault, Lisa"> +<meta name="DC.Creator" content="Desruisseaux, Bernard"> +<meta name="DC.Creator" content="Daboo, Cyrus"> +<meta name="DC.Date.Issued" content="March, 2007"> +<meta name="DC.Title" content="Calendaring Extensions to WebDAV (CalDAV)"> + + <link rel="icon" href="index_files/rfc.png" type="image/png"> + <link rel="shortcut icon" href="index_files/rfc.png" type="image/png"> + <title>RFC 4791 - Calendaring Extensions to WebDAV (CalDAV)</title> + + + <style type="text/css"><!--
+/* Effective stylesheet produced by snapshot save */
+body { margin: 0px 8px; font-size: 1em; }
+h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { line-height: 0pt; display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; }
+pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; }
+.pre { white-space: pre; font-family: monospace; }
+.newpage { page-break-before: always; }
+.invisible { text-decoration: none; color: white; }
+a.selflink { color: black; text-decoration: none; }
+@media print {
+ body { font-family: monospace; font-size: 10.5pt; }
+ h1, h2, h3, h4, h5, h6 { font-size: 1em; }
+ a:link, a:visited { color: inherit; text-decoration: none; }
+ .noprint { display: none; }
+}
+@media screen {
+ .grey, .grey a:link, .grey a:visited { color: rgb(119, 119, 119); }
+ .docinfo { background-color: rgb(238, 238, 238); }
+ .top { border-top: 7px solid rgb(238, 238, 238); }
+ .bgblue { background-color: rgb(102, 102, 255); }
+ .legend { font-size: 90%; }
+}
+--></style> + <!--[if IE]> + <style> + body { + font-size: 13px; + margin: 10px 10px; + } + </style> + <![endif]--> + + <script type="text/javascript"><!--
+/* Script removed by snapshot save */
+--></script> +</head> +<body onload=""> + <div style="height: 13px;"> + <div onmouseover="" onclick="" onmouseout="" style="height: 6px; position: absolute;" class="pre noprint docinfo bgblue" title="Click for colour legend."> </div> + <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="" onmouseout=""> + </div> + </div> +<span class="pre noprint docinfo top">[<a href="http://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="http://tools.ietf.org/rfc/rfc4791.txt" title="Plaintext version of this document">txt</a>|<a href="http://tools.ietf.org/pdf/rfc4791" title="PDF version of this document">pdf</a>] [<a href="http://tools.ietf.org/html/draft-dusseault-caldav" title="draft-dusseault-caldav">draft-dusseault-c...</a>] [<a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc4791" title="Inline diff (wdiff)">Diff1</a>] [<a href="http://tools.ietf.org/rfcdiff?url2=rfc4791" title="Side-by-side diff">Diff2</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=4791">Errata</a>] </span><br> +<span class="pre noprint docinfo"> </span><br> +<span class="pre noprint docinfo">Updated by: <a href="http://tools.ietf.org/html/rfc5689">5689</a>, <a href="http://tools.ietf.org/html/rfc6638">6638</a>, <a href="http://tools.ietf.org/html/rfc6764">6764</a> PROPOSED STANDARD</span><br> +<span class="pre noprint docinfo"> <span style="color: #C00;">Errata Exist</span></span><br> +<pre>Network Working Group C. Daboo +Request for Comments: 4791 Apple +Category: Standards Track B. Desruisseaux + Oracle + L. Dusseault + CommerceNet + March 2007 + + + <span class="h1"><h1>Calendaring Extensions to WebDAV (CalDAV)</h1></span> + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document defines extensions to the Web Distributed Authoring and + Versioning (WebDAV) protocol to specify a standard way of accessing, + managing, and sharing calendaring and scheduling information based on + the iCalendar format. This document defines the "calendar-access" + feature of CalDAV. + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 1]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +Table of Contents + + <a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a> + <a href="#section-1.1">1.1</a>. Notational Conventions . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a> + <a href="#section-1.2">1.2</a>. XML Namespaces and Processing . . . . . . . . . . . . . . <a href="#page-5">5</a> + <a href="#section-1.3">1.3</a>. Method Preconditions and Postconditions . . . . . . . . . <a href="#page-6">6</a> + <a href="#section-2">2</a>. Requirements Overview . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a> + <a href="#section-3">3</a>. Calendaring Data Model . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a> + <a href="#section-3.1">3.1</a>. Calendar Server . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a> + <a href="#section-3.2">3.2</a>. Recurrence and the Data Model . . . . . . . . . . . . . . <a href="#page-8">8</a> + <a href="#section-4">4</a>. Calendar Resources . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a> + <a href="#section-4.1">4.1</a>. Calendar Object Resources . . . . . . . . . . . . . . . . <a href="#page-9">9</a> + <a href="#section-4.2">4.2</a>. Calendar Collection . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a> + <a href="#section-5">5</a>. Calendar Access Feature . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a> + <a href="#section-5.1">5.1</a>. Calendar Access Support . . . . . . . . . . . . . . . . . <a href="#page-11">11</a> + 5.1.1. Example: Using OPTIONS for the Discovery of + Calendar Access Support . . . . . . . . . . . . . . . <a href="#page-12">12</a> + <a href="#section-5.2">5.2</a>. Calendar Collection Properties . . . . . . . . . . . . . . <a href="#page-12">12</a> + <a href="#section-5.2.1">5.2.1</a>. CALDAV:calendar-description Property . . . . . . . . . <a href="#page-12">12</a> + <a href="#section-5.2.2">5.2.2</a>. CALDAV:calendar-timezone Property . . . . . . . . . . <a href="#page-13">13</a> + <a href="#section-5.2.3">5.2.3</a>. CALDAV:supported-calendar-component-set Property . . . <a href="#page-14">14</a> + <a href="#section-5.2.4">5.2.4</a>. CALDAV:supported-calendar-data Property . . . . . . . <a href="#page-15">15</a> + <a href="#section-5.2.5">5.2.5</a>. CALDAV:max-resource-size Property . . . . . . . . . . <a href="#page-16">16</a> + <a href="#section-5.2.6">5.2.6</a>. CALDAV:min-date-time Property . . . . . . . . . . . . <a href="#page-17">17</a> + <a href="#section-5.2.7">5.2.7</a>. CALDAV:max-date-time Property . . . . . . . . . . . . <a href="#page-18">18</a> + <a href="#section-5.2.8">5.2.8</a>. CALDAV:max-instances Property . . . . . . . . . . . . <a href="#page-19">19</a> + <a href="#section-5.2.9">5.2.9</a>. CALDAV:max-attendees-per-instance Property . . . . . . <a href="#page-19">19</a> + <a href="#section-5.2.10">5.2.10</a>. Additional Precondition for PROPPATCH . . . . . . . . <a href="#page-20">20</a> + <a href="#section-5.3">5.3</a>. Creating Resources . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a> + <a href="#section-5.3.1">5.3.1</a>. MKCALENDAR Method . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a> + <a href="#section-5.3.1.1">5.3.1.1</a>. Status Codes . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a> + <a href="#section-5.3.1.2">5.3.1.2</a>. Example: Successful MKCALENDAR Request . . . . . . <a href="#page-23">23</a> + <a href="#section-5.3.2">5.3.2</a>. Creating Calendar Object Resources . . . . . . . . . . <a href="#page-25">25</a> + 5.3.2.1. Additional Preconditions for PUT, COPY, and + MOVE . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a> + 5.3.3. Non-Standard Components, Properties, and Parameters . 28 + <a href="#section-5.3.4">5.3.4</a>. Calendar Object Resource Entity Tag . . . . . . . . . <a href="#page-28">28</a> + <a href="#section-6">6</a>. Calendaring Access Control . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a> + <a href="#section-6.1">6.1</a>. Calendaring Privilege . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a> + <a href="#section-6.1.1">6.1.1</a>. CALDAV:read-free-busy Privilege . . . . . . . . . . . <a href="#page-29">29</a> + <a href="#section-6.2">6.2</a>. Additional Principal Property . . . . . . . . . . . . . . <a href="#page-30">30</a> + <a href="#section-6.2.1">6.2.1</a>. CALDAV:calendar-home-set Property . . . . . . . . . . <a href="#page-30">30</a> + <a href="#section-7">7</a>. Calendaring Reports . . . . . . . . . . . . . . . . . . . . . <a href="#page-31">31</a> + <a href="#section-7.1">7.1</a>. REPORT Method . . . . . . . . . . . . . . . . . . . . . . <a href="#page-31">31</a> + <a href="#section-7.2">7.2</a>. Ordinary Collections . . . . . . . . . . . . . . . . . . . <a href="#page-31">31</a> + <a href="#section-7.3">7.3</a>. Date and Floating Time . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a> + <a href="#section-7.4">7.4</a>. Time Range Filtering . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a> + <a href="#section-7.5">7.5</a>. Searching Text: Collations . . . . . . . . . . . . . . . . <a href="#page-33">33</a> + + + +<span class="grey">Daboo, et al. Standards Track [Page 2]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <a href="#section-7.5.1">7.5.1</a>. CALDAV:supported-collation-set Property . . . . . . . <a href="#page-34">34</a> + <a href="#section-7.6">7.6</a>. Partial Retrieval . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a> + <a href="#section-7.7">7.7</a>. Non-Standard Components, Properties, and Parameters . . . <a href="#page-35">35</a> + <a href="#section-7.8">7.8</a>. CALDAV:calendar-query REPORT . . . . . . . . . . . . . . . <a href="#page-36">36</a> + <a href="#section-7.8.1">7.8.1</a>. Example: Partial Retrieval of Events by Time Range . . <a href="#page-38">38</a> + <a href="#section-7.8.2">7.8.2</a>. Example: Partial Retrieval of Recurring Events . . . . <a href="#page-42">42</a> + <a href="#section-7.8.3">7.8.3</a>. Example: Expanded Retrieval of Recurring Events . . . <a href="#page-45">45</a> + 7.8.4. Example: Partial Retrieval of Stored Free Busy + Components . . . . . . . . . . . . . . . . . . . . . . <a href="#page-48">48</a> + <a href="#section-7.8.5">7.8.5</a>. Example: Retrieval of To-Dos by Alarm Time Range . . . <a href="#page-50">50</a> + <a href="#section-7.8.6">7.8.6</a>. Example: Retrieval of Event by UID . . . . . . . . . . <a href="#page-51">51</a> + <a href="#section-7.8.7">7.8.7</a>. Example: Retrieval of Events by PARTSTAT . . . . . . . <a href="#page-53">53</a> + <a href="#section-7.8.8">7.8.8</a>. Example: Retrieval of Events Only . . . . . . . . . . <a href="#page-55">55</a> + <a href="#section-7.8.9">7.8.9</a>. Example: Retrieval of All Pending To-Dos . . . . . . . <a href="#page-59">59</a> + <a href="#section-7.8.10">7.8.10</a>. Example: Attempt to Query Unsupported Property . . . . <a href="#page-62">62</a> + <a href="#section-7.9">7.9</a>. CALDAV:calendar-multiget REPORT . . . . . . . . . . . . . <a href="#page-63">63</a> + 7.9.1. Example: Successful CALDAV:calendar-multiget REPORT . 64 + <a href="#section-7.10">7.10</a>. CALDAV:free-busy-query REPORT . . . . . . . . . . . . . . <a href="#page-66">66</a> + <a href="#section-7.10.1">7.10.1</a>. Example: Successful CALDAV:free-busy-query REPORT . . <a href="#page-68">68</a> + <a href="#section-8">8</a>. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-69">69</a> + <a href="#section-8.1">8.1</a>. Client-to-Client Interoperability . . . . . . . . . . . . <a href="#page-69">69</a> + <a href="#section-8.2">8.2</a>. Synchronization Operations . . . . . . . . . . . . . . . . <a href="#page-69">69</a> + <a href="#section-8.2.1">8.2.1</a>. Use of Reports . . . . . . . . . . . . . . . . . . . . <a href="#page-69">69</a> + <a href="#section-8.2.1.1">8.2.1.1</a>. Restrict the Time Range . . . . . . . . . . . . . <a href="#page-69">69</a> + <a href="#section-8.2.1.2">8.2.1.2</a>. Synchronize by Time Range . . . . . . . . . . . . <a href="#page-70">70</a> + <a href="#section-8.2.1.3">8.2.1.3</a>. Synchronization Process . . . . . . . . . . . . . <a href="#page-70">70</a> + <a href="#section-8.2.2">8.2.2</a>. Restrict the Properties Returned . . . . . . . . . . . <a href="#page-72">72</a> + <a href="#section-8.3">8.3</a>. Use of Locking . . . . . . . . . . . . . . . . . . . . . . <a href="#page-72">72</a> + <a href="#section-8.4">8.4</a>. Finding Calendars . . . . . . . . . . . . . . . . . . . . <a href="#page-72">72</a> + <a href="#section-8.5">8.5</a>. Storing and Using Attachments . . . . . . . . . . . . . . <a href="#page-74">74</a> + <a href="#section-8.5.1">8.5.1</a>. Inline Attachments . . . . . . . . . . . . . . . . . . <a href="#page-74">74</a> + <a href="#section-8.5.2">8.5.2</a>. External Attachments . . . . . . . . . . . . . . . . . <a href="#page-75">75</a> + <a href="#section-8.6">8.6</a>. Storing and Using Alarms . . . . . . . . . . . . . . . . . <a href="#page-76">76</a> + <a href="#section-9">9</a>. XML Element Definitions . . . . . . . . . . . . . . . . . . . <a href="#page-77">77</a> + <a href="#section-9.1">9.1</a>. CALDAV:calendar XML Element . . . . . . . . . . . . . . . <a href="#page-77">77</a> + <a href="#section-9.2">9.2</a>. CALDAV:mkcalendar XML Element . . . . . . . . . . . . . . <a href="#page-77">77</a> + <a href="#section-9.3">9.3</a>. CALDAV:mkcalendar-response XML Element . . . . . . . . . . <a href="#page-78">78</a> + <a href="#section-9.4">9.4</a>. CALDAV:supported-collation XML Element . . . . . . . . . . <a href="#page-78">78</a> + <a href="#section-9.5">9.5</a>. CALDAV:calendar-query XML Element . . . . . . . . . . . . <a href="#page-78">78</a> + <a href="#section-9.6">9.6</a>. CALDAV:calendar-data XML Element . . . . . . . . . . . . . <a href="#page-79">79</a> + <a href="#section-9.6.1">9.6.1</a>. CALDAV:comp XML Element . . . . . . . . . . . . . . . <a href="#page-80">80</a> + <a href="#section-9.6.2">9.6.2</a>. CALDAV:allcomp XML Element . . . . . . . . . . . . . . <a href="#page-81">81</a> + <a href="#section-9.6.3">9.6.3</a>. CALDAV:allprop XML Element . . . . . . . . . . . . . . <a href="#page-81">81</a> + <a href="#section-9.6.4">9.6.4</a>. CALDAV:prop XML Element . . . . . . . . . . . . . . . <a href="#page-82">82</a> + <a href="#section-9.6.5">9.6.5</a>. CALDAV:expand XML Element . . . . . . . . . . . . . . <a href="#page-82">82</a> + <a href="#section-9.6.6">9.6.6</a>. CALDAV:limit-recurrence-set XML Element . . . . . . . <a href="#page-83">83</a> + <a href="#section-9.6.7">9.6.7</a>. CALDAV:limit-freebusy-set XML Element . . . . . . . . <a href="#page-84">84</a> + <a href="#section-9.7">9.7</a>. CALDAV:filter XML Element . . . . . . . . . . . . . . . . <a href="#page-85">85</a> + + + +<span class="grey">Daboo, et al. Standards Track [Page 3]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <a href="#section-9.7.1">9.7.1</a>. CALDAV:comp-filter XML Element . . . . . . . . . . . . <a href="#page-85">85</a> + <a href="#section-9.7.2">9.7.2</a>. CALDAV:prop-filter XML Element . . . . . . . . . . . . <a href="#page-86">86</a> + <a href="#section-9.7.3">9.7.3</a>. CALDAV:param-filter XML Element . . . . . . . . . . . <a href="#page-87">87</a> + <a href="#section-9.7.4">9.7.4</a>. CALDAV:is-not-defined XML Element . . . . . . . . . . <a href="#page-88">88</a> + <a href="#section-9.7.5">9.7.5</a>. CALDAV:text-match XML Element . . . . . . . . . . . . <a href="#page-88">88</a> + <a href="#section-9.8">9.8</a>. CALDAV:timezone XML Element . . . . . . . . . . . . . . . <a href="#page-89">89</a> + <a href="#section-9.9">9.9</a>. CALDAV:time-range XML Element . . . . . . . . . . . . . . <a href="#page-90">90</a> + <a href="#section-9.10">9.10</a>. CALDAV:calendar-multiget XML Element . . . . . . . . . . . <a href="#page-94">94</a> + <a href="#section-9.11">9.11</a>. CALDAV:free-busy-query XML Element . . . . . . . . . . . . <a href="#page-95">95</a> + <a href="#section-10">10</a>. Internationalization Considerations . . . . . . . . . . . . . <a href="#page-95">95</a> + <a href="#section-11">11</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-95">95</a> + <a href="#section-12">12</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-96">96</a> + <a href="#section-12.1">12.1</a>. Namespace Registration . . . . . . . . . . . . . . . . . . <a href="#page-96">96</a> + <a href="#section-13">13</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-96">96</a> + <a href="#section-14">14</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-97">97</a> + <a href="#section-14.1">14.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-97">97</a> + <a href="#section-14.2">14.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-98">98</a> + <a href="#appendix-A">Appendix A</a>. CalDAV Method Privilege Table (Normative) . . . . . . <a href="#page-99">99</a> + <a href="#appendix-B">Appendix B</a>. Calendar Collections Used in the Examples . . . . . . <a href="#page-99">99</a> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 4]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span> + + The concept of using HTTP [<a href="http://tools.ietf.org/html/rfc2616" title="" hypertext transfer protocol http>RFC2616</a>] and WebDAV [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>] as a basis + for a calendar access protocol is by no means a new concept: it was + discussed in the IETF CALSCH working group as early as 1997 or 1998. + Several companies have implemented calendar access protocols using + HTTP to upload and download iCalendar [<a href="http://tools.ietf.org/html/rfc2445" title="" internet calendaring and scheduling core object specification>RFC2445</a>] objects, and using + WebDAV to get listings of resources. However, those implementations + do not interoperate because there are many small and big decisions to + be made in how to model calendaring data as WebDAV resources, as well + as how to implement required features that aren't already part of + WebDAV. This document proposes a way to model calendar data in + WebDAV, with additional features to make an interoperable calendar + access protocol. + +<span class="h3"><h3><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Notational Conventions</h3></span> + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [<a href="http://tools.ietf.org/html/rfc2119" title="" key words for use in rfcs to indicate requirement levels>RFC2119</a>]. + + The term "protected" is used in the Conformance field of property + definitions as defined in <a href="http://tools.ietf.org/html/rfc3253#section-1.4.2">Section 1.4.2 of [RFC3253]</a>. + + 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 type names, respectively. + +<span class="h3"><h3><a class="selflink" name="section-1.2" href="#section-1.2">1.2</a>. XML Namespaces and Processing</h3></span> + + 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 [<a href="#ref-W3C.REC-xml-20060816" title="" extensible markup language edition>W3C.REC-xml-20060816</a>]. + + The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML + elements defined in this specification, its revisions, and related + CalDAV specifications. XML elements defined by individual + implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav" + namespace, and instead should use a namespace that they control. + + The XML declarations used in this document do not include namespace + information. Thus, implementers 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 [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>], which use the "DAV:" namespace. + Wherever such XML elements appear, they are explicitly prefixed with + "DAV:" to avoid confusion. + + + +<span class="grey">Daboo, et al. Standards Track [Page 5]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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. + + Processing of XML by CalDAV clients and servers MUST follow the rules + described in [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]; in particular, <a href="#section-14">Section 14</a>, and Appendix 3 of + that specification. + +<span class="h3"><h3><a class="selflink" name="section-1.3" href="#section-1.3">1.3</a>. Method Preconditions and Postconditions</h3></span> + + A "precondition" of a method describes the state of the server that + must be true for that method to be performed. A "postcondition" of a + method describes the state of the server that must be true after that + method has been completed. If a method precondition or postcondition + for a request is not satisfied, the response status of the request + MUST either be 403 (Forbidden), if the request should not be repeated + because it will always fail, or 409 (Conflict), if it is expected + that the user might be able to resolve the conflict and resubmit the + request. + + In order to allow better client handling of 403 and 409 responses, a + distinct XML element type is associated with each method precondition + and postcondition of a request. When a particular precondition is + not satisfied or a particular postcondition cannot be achieved, the + appropriate XML element MUST be returned as the child of a top-level + DAV:error element in the response body, unless otherwise negotiated + by the request. + +<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. Requirements Overview</h2></span> + + This section lists what functionality is required of a CalDAV server. + To advertise support for CalDAV, a server: + + o MUST support iCalendar [<a href="http://tools.ietf.org/html/rfc2445" title="" internet calendaring and scheduling core object specification>RFC2445</a>] as a media type for the calendar + object resource format; + + o MUST support WebDAV Class 1 [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>] (note that [<a href="#ref-rfc2518bis" title="" http extensions for distributed authoring webdav>rfc2518bis</a>] + describes clarifications to [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>] that aid interoperability); + + o MUST support WebDAV ACL [<a href="http://tools.ietf.org/html/rfc3744" title="" web distributed authoring and versioning access control protocol>RFC3744</a>] with the additional privilege + defined in <a href="#section-6.1">Section 6.1</a> of this document; + + o MUST support transport over TLS [<a href="http://tools.ietf.org/html/rfc2246" title="" the tls protocol version>RFC2246</a>] as defined in [<a href="http://tools.ietf.org/html/rfc2818" title="" http over tls>RFC2818</a>] + (note that [<a href="http://tools.ietf.org/html/rfc2246" title="" the tls protocol version>RFC2246</a>] has been obsoleted by [<a href="http://tools.ietf.org/html/rfc4346" title="" the transport layer security protocol version>RFC4346</a>]); + + o MUST support ETags [<a href="http://tools.ietf.org/html/rfc2616" title="" hypertext transfer protocol http>RFC2616</a>] with additional requirements + specified in <a href="#section-5.3.4">Section 5.3.4</a> of this document; + + + + +<span class="grey">Daboo, et al. Standards Track [Page 6]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + o MUST support all calendaring reports defined in <a href="#section-7">Section 7</a> of this + document; and + + o MUST advertise support on all calendar collections and calendar + object resources for the calendaring reports in the DAV:supported- + report-set property, as defined in Versioning Extensions to WebDAV + [<a href="http://tools.ietf.org/html/rfc3253" title="" versioning extensions to webdav distributed authoring and>RFC3253</a>]. + + In addition, a server: + + o SHOULD support the MKCALENDAR method defined in <a href="#section-5.3.1">Section 5.3.1</a> of + this document. + +<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. Calendaring Data Model</h2></span> + + One of the features that has made WebDAV a successful protocol is its + firm data model. This makes it a useful framework for other + applications such as calendaring. This specification follows the + same pattern by developing all features based on a well-described + data model. + + As a brief overview, a CalDAV calendar is modeled as a WebDAV + collection with a defined structure; each calendar collection + contains a number of resources representing calendar objects as its + direct child resource. Each resource representing a calendar object + (event, to-do, journal entry, or other calendar components) is called + a "calendar object resource". Each calendar object resource and each + calendar collection can be individually locked and have individual + WebDAV properties. Requirements derived from this model are provided + in <a href="#section-4.1">Section 4.1</a> and <a href="#section-4.2">Section 4.2</a>. + +<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. Calendar Server</h3></span> + + A CalDAV server is a calendaring-aware engine combined with a WebDAV + repository. A WebDAV repository is a set of WebDAV collections, + containing other WebDAV resources, within a unified URL namespace. + For example, the repository "http://www.example.com/webdav/" may + contain WebDAV collections and resources, all of which have URLs + beginning with "http://www.example.com/webdav/". Note that the root + URL, "http://www.example.com/", may not itself be a WebDAV repository + (for example, if the WebDAV support is implemented through a servlet + or other Web server extension). + + A WebDAV repository MAY include calendar data in some parts of its + URL namespace, and non-calendaring data in other parts. + + A WebDAV repository can advertise itself as a CalDAV server if it + supports the functionality defined in this specification at any point + + + +<span class="grey">Daboo, et al. Standards Track [Page 7]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + within the root of the repository. That might mean that calendaring + data is spread throughout the repository and mixed with non-calendar + data in nearby collections (e.g., calendar data may be found in + /home/lisa/calendars/ as well as in /home/bernard/calendars/, and + non-calendar data in /home/lisa/contacts/). Or, it might mean that + calendar data can be found only in certain sections of the repository + (e.g., /calendar/). Calendaring features are only required in the + repository sections that are or contain calendar object resources. + Therefore, a repository confining calendar data to the /calendar/ + collection would only need to support the CalDAV required features + within that collection. + + The CalDAV server or repository is the canonical location for + calendar data and state information. Clients may submit requests to + change data or download data. Clients may store calendar objects + offline and attempt to synchronize at a later time. However, clients + MUST be prepared for calendar data on the server to change between + the time of last synchronization and when attempting an update, as + calendar collections may be shared and accessible via multiple + clients. Entity tags and other features make this possible. + +<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. Recurrence and the Data Model</h3></span> + + Recurrence is an important part of the data model because it governs + how many resources are expected to exist. This specification models + a recurring calendar component and its recurrence exceptions as a + single resource. In this model, recurrence rules, recurrence dates, + exception rules, and exception dates are all part of the data in a + single calendar object resource. This model avoids problems of + limiting how many recurrence instances to store in the repository, + how to keep recurrence instances in sync with the recurring calendar + component, and how to link recurrence exceptions with the recurring + calendar component. It also results in less data to synchronize + between client and server, and makes it easier to make changes to all + recurrence instances or to a recurrence rule. It makes it easier to + create a recurring calendar component and to delete all recurrence + instances. + + Clients are not forced to retrieve information about all recurrence + instances of a recurring component. The CALDAV:calendar-query and + CALDAV:calendar-multiget reports defined in this document allow + clients to retrieve only recurrence instances that overlap a given + time range. + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 8]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. Calendar Resources</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. Calendar Object Resources</h3></span> + + Calendar object resources contained in calendar collections MUST NOT + contain more than one type of calendar component (e.g., VEVENT, + VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE + components, which MUST be specified for each unique TZID parameter + value specified in the iCalendar object. For instance, a calendar + object resource can contain one VEVENT component and one VTIMEZONE + component, but it cannot contain one VEVENT component and one VTODO + component. Instead, the VEVENT and VTODO components would have to be + stored in separate calendar object resources in the same collection. + + Calendar object resources contained in calendar collections MUST NOT + specify the iCalendar METHOD property. + + The UID property value of the calendar components contained in a + calendar object resource MUST be unique in the scope of the calendar + collection in which they are stored. + + Calendar components in a calendar collection that have different UID + property values MUST be stored in separate calendar object resources. + + Calendar components with the same UID property value, in a given + calendar collection, MUST be contained in the same calendar object + resource. This ensures that all components in a recurrence "set" are + contained in the same calendar object resource. It is possible for a + calendar object resource to just contain components that represent + "overridden" instances (ones that modify the behavior of a regular + instance, and thus include a RECURRENCE-ID property) without also + including the "master" recurring component (the one that defines the + recurrence "set" and does not contain any RECURRENCE-ID property). + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 9]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + For example, given the following iCalendar object: + + BEGIN:VCALENDAR + PRODID:-//Example Corp.//CalDAV Client//EN + VERSION:2.0 + BEGIN:VEVENT + UID:1@example.com + SUMMARY:One-off Meeting + DTSTAMP:20041210T183904Z + DTSTART:20041207T120000Z + DTEND:20041207T130000Z + END:VEVENT + BEGIN:VEVENT + UID:2@example.com + SUMMARY:Weekly Meeting + DTSTAMP:20041210T183838Z + DTSTART:20041206T120000Z + DTEND:20041206T130000Z + RRULE:FREQ=WEEKLY + END:VEVENT + BEGIN:VEVENT + UID:2@example.com + SUMMARY:Weekly Meeting + RECURRENCE-ID:20041213T120000Z + DTSTAMP:20041210T183838Z + DTSTART:20041213T130000Z + DTEND:20041213T140000Z + END:VEVENT + END:VCALENDAR + + The VEVENT component with the UID value "1@example.com" would be + stored in its own calendar object resource. The two VEVENT + components with the UID value "2@example.com", which represent a + recurring event where one recurrence instance has been overridden, + would be stored in the same calendar object resource. + +<span class="h3"><h3><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. Calendar Collection</h3></span> + + A calendar collection contains calendar object resources that + represent calendar components within a calendar. A calendar + collection is manifested to clients as a WebDAV resource collection + identified by a URL. A calendar collection MUST report the DAV: + collection and CALDAV:calendar XML elements in the value of the DAV: + resourcetype property. The element type declaration for CALDAV: + calendar is: + + <!ELEMENT calendar EMPTY> + + + + +<span class="grey">Daboo, et al. Standards Track [Page 10]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + A calendar collection can be created through provisioning (i.e., + automatically created when a user's account is provisioned), or it + can be created with the MKCALENDAR method (see <a href="#section-5.3.1">Section 5.3.1</a>). This + method can be useful for a user to create additional calendars (e.g., + soccer schedule) or for users to share a calendar (e.g., team events + or conference rooms). However, note that this document doesn't + define the purpose of extra calendar collections. Users must rely on + non-standard cues to find out what a calendar collection is for, or + use the CALDAV:calendar-description property defined in <a href="#section-5.2.1">Section 5.2.1</a> + to provide such a cue. + + The following restrictions are applied to the resources within a + calendar collection: + + a. Calendar collections MUST only contain calendar object resources + and collections that are not calendar collections, i.e., the only + "top-level" non-collection resources allowed in a calendar + collection are calendar object resources. This ensures that + calendar clients do not have to deal with non-calendar data in a + calendar collection, though they do have to distinguish between + calendar object resources and collections when using standard + WebDAV techniques to examine the contents of a collection. + + b. Collections contained in calendar collections MUST NOT contain + calendar collections at any depth, i.e., "nesting" of calendar + collections within other calendar collections at any depth is not + allowed. This specification does not define how collections + contained in a calendar collection are used or how they relate to + any calendar object resources contained in the calendar + collection. + + Multiple calendar collections MAY be children of the same collection. + +<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. Calendar Access Feature</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-5.1" href="#section-5.1">5.1</a>. Calendar Access Support</h3></span> + + A server supporting the features described in this document MUST + include "calendar-access" as a field in the DAV response header from + an OPTIONS request on any resource that supports any calendar + properties, reports, method, or privilege. A value of "calendar- + access" in the DAV response header MUST indicate that the server + supports all MUST level requirements specified in this document. + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 11]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Example: Using OPTIONS for the Discovery of Calendar Access</h4></span> +<span class="h4"><h4> Support</h4></span> + + >> Request << + + OPTIONS /home/bernard/calendars/ HTTP/1.1 + Host: cal.example.com + + >> Response << + + HTTP/1.1 200 OK + Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE + Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL + DAV: 1, 2, access-control, calendar-access + Date: Sat, 11 Nov 2006 09:32:12 GMT + Content-Length: 0 + + In this example, the OPTIONS method returns the value "calendar- + access" in the DAV response header to indicate that the collection + "/home/bernard/calendars/" supports the properties, reports, method, + or privilege defined in this specification. + +<span class="h3"><h3><a class="selflink" name="section-5.2" href="#section-5.2">5.2</a>. Calendar Collection Properties</h3></span> + + This section defines properties for calendar collections. + +<span class="h4"><h4><a class="selflink" name="section-5.2.1" href="#section-5.2.1">5.2.1</a>. CALDAV:calendar-description Property</h4></span> + + Name: calendar-description + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Provides a human-readable description of the calendar + collection. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MAY be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). An xml:lang attribute indicating the human + language of the description SHOULD be set for this property by + clients or through server provisioning. Servers MUST return any + xml:lang attribute if set for the property. + + Description: If present, the property contains a description of the + calendar collection that is suitable for presentation to a user. + If not present, the client should assume no description for the + calendar collection. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 12]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Definition: + + <!ELEMENT calendar-description (#PCDATA)> + PCDATA value: string + + Example: + + <C:calendar-description xml:lang="fr-CA" + xmlns:C="urn:ietf:params:xml:ns:caldav" + >Calendrier de Mathilde Desruisseaux</C:calendar-description> + +<span class="h4"><h4><a class="selflink" name="section-5.2.2" href="#section-5.2.2">5.2.2</a>. CALDAV:calendar-timezone Property</h4></span> + + Name: calendar-timezone + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a time zone on a calendar collection. + + Conformance: This property SHOULD be defined on all calendar + collections. If defined, it SHOULD NOT be returned by a PROPFIND + DAV:allprop request (as defined in <a href="http://tools.ietf.org/html/rfc2518#section-12.14.1">Section 12.14.1 of [RFC2518]</a>). + + Description: The CALDAV:calendar-timezone property is used to + specify the time zone the server should rely on to resolve "date" + values and "date with local time" values (i.e., floating time) to + "date with UTC time" values. The server will require this + information to determine if a calendar component scheduled with + "date" values or "date with local time" values overlaps a CALDAV: + time-range specified in a CALDAV:calendar-query REPORT. The + server will also require this information to compute the proper + FREEBUSY time period as "date with UTC time" in the VFREEBUSY + component returned in a response to a CALDAV:free-busy-query + REPORT request that takes into account calendar components + scheduled with "date" values or "date with local time" values. In + the absence of this property, the server MAY rely on the time zone + of their choice. + + Note: The iCalendar data embedded within the CALDAV:calendar- + timezone XML element MUST follow the standard XML character data + encoding rules, including use of &lt;, &gt;, &amp; etc. entity + encoding or the use of a <![CDATA[ ... ]]> construct. In the + later case, the iCalendar data cannot contain the character + sequence "]]>", which is the end delimiter for the CDATA section. + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 13]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Definition: + + <!ELEMENT calendar-timezone (#PCDATA)> + PCDATA value: an iCalendar object with exactly one VTIMEZONE + component. + + Example: + + <C:calendar-timezone + xmlns:C="urn:ietf:params:xml:ns:caldav">BEGIN:VCALENDAR + PRODID:-//Example Corp.//CalDAV Client//EN + VERSION:2.0 + BEGIN:VTIMEZONE + TZID:US-Eastern + LAST-MODIFIED:19870101T000000Z + BEGIN:STANDARD + DTSTART:19671029T020000 + RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + TZNAME:Eastern Standard Time (US &amp; Canada) + END:STANDARD + BEGIN:DAYLIGHT + DTSTART:19870405T020000 + RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:Eastern Daylight Time (US &amp; Canada) + END:DAYLIGHT + END:VTIMEZONE + END:VCALENDAR + </C:calendar-timezone> + +<span class="h4"><h4><a class="selflink" name="section-5.2.3" href="#section-5.2.3">5.2.3</a>. CALDAV:supported-calendar-component-set Property</h4></span> + + Name: supported-calendar-component-set + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies the calendar component types (e.g., VEVENT, + VTODO, etc.) that calendar object resources can contain in the + calendar collection. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MUST be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + + + +<span class="grey">Daboo, et al. Standards Track [Page 14]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Description: The CALDAV:supported-calendar-component-set property is + used to specify restrictions on the calendar component types that + calendar object resources may contain in a calendar collection. + Any attempt by the client to store calendar object resources with + component types not listed in this property, if it exists, MUST + result in an error, with the CALDAV:supported-calendar-component + precondition (<a href="#section-5.3.2.1">Section 5.3.2.1</a>) being violated. Since this + property is protected, it cannot be changed by clients using a + PROPPATCH request. However, clients can initialize the value of + this property when creating a new calendar collection with + MKCALENDAR. The empty-element tag <C:comp name="VTIMEZONE"/> MUST + only be specified if support for calendar object resources that + only contain VTIMEZONE components is provided or desired. Support + for VTIMEZONE components in calendar object resources that contain + VEVENT or VTODO components is always assumed. In the absence of + this property, the server MUST accept all component types, and the + client can assume that all component types are accepted. + + Definition: + + <!ELEMENT supported-calendar-component-set (comp+)> + + Example: + + <C:supported-calendar-component-set + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <C:comp name="VEVENT"/> + <C:comp name="VTODO"/> + </C:supported-calendar-component-set> + +<span class="h4"><h4><a class="selflink" name="section-5.2.4" href="#section-5.2.4">5.2.4</a>. CALDAV:supported-calendar-data Property</h4></span> + + Name: supported-calendar-data + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies what media types are allowed for calendar object + resources in a calendar collection. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MUST be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + Description: The CALDAV:supported-calendar-data property is used to + specify the media type supported for the calendar object resources + contained in a given calendar collection (e.g., iCalendar version + 2.0). Any attempt by the client to store calendar object + + + +<span class="grey">Daboo, et al. Standards Track [Page 15]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + resources with a media type not listed in this property MUST + result in an error, with the CALDAV:supported-calendar-data + precondition (<a href="#section-5.3.2.1">Section 5.3.2.1</a>) being violated. In the absence of + this property, the server MUST only accept data with the media + type "text/calendar" and iCalendar version 2.0, and clients can + assume that the server will only accept this data. + + Definition: + + <!ELEMENT supported-calendar-data (calendar-data+)> + + Example: + + <C:supported-calendar-data + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <C:calendar-data content-type="text/calendar" version="2.0"/> + </C:supported-calendar-data> + +<span class="h4"><h4><a class="selflink" name="section-5.2.5" href="#section-5.2.5">5.2.5</a>. CALDAV:max-resource-size Property</h4></span> + + Name: max-resource-size + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Provides a numeric value indicating the maximum size of a + resource in octets that the server is willing to accept when a + calendar object resource is stored in a calendar collection. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MUST be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + Description: The CALDAV:max-resource-size is used to specify a + numeric value that represents the maximum size in octets that the + server is willing to accept when a calendar object resource is + stored in a calendar collection. Any attempt to store a calendar + object resource exceeding this size MUST result in an error, with + the CALDAV:max-resource-size precondition (<a href="#section-5.3.2.1">Section 5.3.2.1</a>) being + violated. In the absence of this property, the client can assume + that the server will allow storing a resource of any reasonable + size. + + Definition: + + <!ELEMENT max-resource-size (#PCDATA)> + PCDATA value: a numeric value (positive integer) + + + + +<span class="grey">Daboo, et al. Standards Track [Page 16]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Example: + + <C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav" + >102400</C:max-resource-size> + +<span class="h4"><h4><a class="selflink" name="section-5.2.6" href="#section-5.2.6">5.2.6</a>. CALDAV:min-date-time Property</h4></span> + + Name: min-date-time + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Provides a DATE-TIME value indicating the earliest date and + time (in UTC) that the server is willing to accept for any DATE or + DATE-TIME value in a calendar object resource stored in a calendar + collection. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MUST be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + Description: The CALDAV:min-date-time is used to specify an + iCalendar DATE-TIME value in UTC that indicates the earliest + inclusive date that the server is willing to accept for any + explicit DATE or DATE-TIME value in a calendar object resource + stored in a calendar collection. Any attempt to store a calendar + object resource using a DATE or DATE-TIME value earlier than this + value MUST result in an error, with the CALDAV:min-date-time + precondition (<a href="#section-5.3.2.1">Section 5.3.2.1</a>) being violated. Note that servers + MUST accept recurring components that specify instances beyond + this limit, provided none of those instances have been overridden. + In that case, the server MAY simply ignore those instances outside + of the acceptable range when processing reports on the calendar + object resource. In the absence of this property, the client can + assume any valid iCalendar date may be used at least up to the + CALDAV:max-date-time value, if that is defined. + + Definition: + + <!ELEMENT min-date-time (#PCDATA)> + PCDATA value: an iCalendar format DATE-TIME value in UTC + + Example: + + <C:min-date-time xmlns:C="urn:ietf:params:xml:ns:caldav" + >19000101T000000Z</C:min-date-time> + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 17]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-5.2.7" href="#section-5.2.7">5.2.7</a>. CALDAV:max-date-time Property</h4></span> + + Name: max-date-time + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Provides a DATE-TIME value indicating the latest date and + time (in UTC) that the server is willing to accept for any DATE or + DATE-TIME value in a calendar object resource stored in a calendar + collection. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MUST be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + Description: The CALDAV:max-date-time is used to specify an + iCalendar DATE-TIME value in UTC that indicates the inclusive + latest date that the server is willing to accept for any date or + time value in a calendar object resource stored in a calendar + collection. Any attempt to store a calendar object resource using + a DATE or DATE-TIME value later than this value MUST result in an + error, with the CALDAV:max-date-time precondition + (<a href="#section-5.3.2.1">Section 5.3.2.1</a>) being violated. Note that servers MUST accept + recurring components that specify instances beyond this limit, + provided none of those instances have been overridden. In that + case, the server MAY simply ignore those instances outside of the + acceptable range when processing reports on the calendar object + resource. In the absence of this property, the client can assume + any valid iCalendar date may be used at least down to the CALDAV: + min-date-time value, if that is defined. + + Definition: + + <!ELEMENT max-date-time (#PCDATA)> + PCDATA value: an iCalendar format DATE-TIME value in UTC + + Example: + + <C:max-date-time xmlns:C="urn:ietf:params:xml:ns:caldav" + >20491231T235959Z</C:max-date-time> + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 18]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-5.2.8" href="#section-5.2.8">5.2.8</a>. CALDAV:max-instances Property</h4></span> + + Name: max-instances + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Provides a numeric value indicating the maximum number of + recurrence instances that a calendar object resource stored in a + calendar collection can generate. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MUST be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + Description: The CALDAV:max-instances is used to specify a numeric + value that indicates the maximum number of recurrence instances + that a calendar object resource stored in a calendar collection + can generate. Any attempt to store a calendar object resource + with a recurrence pattern that generates more instances than this + value MUST result in an error, with the CALDAV:max-instances + precondition (<a href="#section-5.3.2.1">Section 5.3.2.1</a>) being violated. In the absence of + this property, the client can assume that the server has no limits + on the number of recurrence instances it can handle or expand. + + Definition: + + <!ELEMENT max-instances (#PCDATA)> + PCDATA value: a numeric value (integer greater than zero) + + Example: + + <C:max-instances xmlns:C="urn:ietf:params:xml:ns:caldav" + >100</C:max-instances> + +<span class="h4"><h4><a class="selflink" name="section-5.2.9" href="#section-5.2.9">5.2.9</a>. CALDAV:max-attendees-per-instance Property</h4></span> + + Name: max-attendees-per-instance + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Provides a numeric value indicating the maximum number of + ATTENDEE properties in any instance of a calendar object resource + stored in a calendar collection. + + Conformance: This property MAY be defined on any calendar + collection. If defined, it MUST be protected and SHOULD NOT be + + + + +<span class="grey">Daboo, et al. Standards Track [Page 19]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + Description: The CALDAV:max-attendees-per-instance is used to + specify a numeric value that indicates the maximum number of + iCalendar ATTENDEE properties on any one instance of a calendar + object resource stored in a calendar collection. Any attempt to + store a calendar object resource with more ATTENDEE properties per + instance than this value MUST result in an error, with the CALDAV: + max-attendees-per-instance precondition (<a href="#section-5.3.2.1">Section 5.3.2.1</a>) being + violated. In the absence of this property, the client can assume + that the server can handle any number of ATTENDEE properties in a + calendar component. + + Definition: + + <!ELEMENT max-attendees-per-instance (#PCDATA)> + PCDATA value: a numeric value (integer greater than zero) + + Example: + + <C:max-attendees-per-instance + xmlns:C="urn:ietf:params:xml:ns:caldav" + >25</C:max-attendees-per-instance> + +<span class="h4"><h4><a class="selflink" name="section-5.2.10" href="#section-5.2.10">5.2.10</a>. Additional Precondition for PROPPATCH</h4></span> + + This specification requires an additional Precondition for the + PROPPATCH method. The precondition is: + + (CALDAV:valid-calendar-data): The time zone specified in CALDAV: + calendar-timezone property MUST be a valid iCalendar object + containing a single valid VTIMEZONE component. + +<span class="h3"><h3><a class="selflink" name="section-5.3" href="#section-5.3">5.3</a>. Creating Resources</h3></span> + + Calendar collections and calendar object resources may be created by + either a CalDAV client or by the CalDAV server. This specification + defines restrictions and a data model that both clients and servers + MUST adhere to when manipulating such calendar data. + +<span class="h4"><h4><a class="selflink" name="section-5.3.1" href="#section-5.3.1">5.3.1</a>. MKCALENDAR Method</h4></span> + + An HTTP request using the MKCALENDAR method creates a new calendar + collection resource. A server MAY restrict calendar collection + creation to particular collections. + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 20]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Support for MKCALENDAR on the server is only RECOMMENDED and not + REQUIRED because some calendar stores only support one calendar per + user (or principal), and those are typically pre-created for each + account. However, servers and clients are strongly encouraged to + support MKCALENDAR whenever possible to allow users to create + multiple calendar collections to help organize their data better. + + Clients SHOULD use the DAV:displayname property for a human-readable + name of the calendar. Clients can either specify the value of the + DAV:displayname property in the request body of the MKCALENDAR + request, or alternatively issue a PROPPATCH request to change the + DAV:displayname property to the appropriate value immediately after + issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: + displayname property to be the same as any other calendar collection + at the same URI "level". When displaying calendar collections to + users, clients SHOULD check the DAV:displayname property and use that + value as the name of the calendar. In the event that the DAV: + displayname property is empty, the client MAY use the last part of + the calendar collection URI as the name; however, that path segment + may be "opaque" and not represent any meaningful human-readable text. + + If a MKCALENDAR request fails, the server state preceding the request + MUST be restored. + + Marshalling: + If a request body is included, it MUST be a CALDAV:mkcalendar XML + element. Instruction processing MUST occur in the order + instructions are received (i.e., from top to bottom). + Instructions MUST either all be executed or none executed. Thus, + if any error occurs during processing, all executed instructions + MUST be undone and a proper error result returned. Instruction + processing details can be found in the definition of the DAV:set + instruction in <a href="http://tools.ietf.org/html/rfc2518#section-12.13.2">Section 12.13.2 of [RFC2518]</a>. + + <!ELEMENT mkcalendar (DAV:set)> + + If a response body for a successful request is included, it MUST + be a CALDAV:mkcalendar-response XML element. + + <!ELEMENT mkcalendar-response ANY> + + The response MUST include a Cache-Control:no-cache header. + + Preconditions: + + (DAV:resource-must-be-null): A resource MUST NOT exist at the + Request-URI; + + + + +<span class="grey">Daboo, et al. Standards Track [Page 21]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-22" id="page-22" href="#page-22" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + (CALDAV:calendar-collection-location-ok): The Request-URI MUST + identify a location where a calendar collection can be created; + + (CALDAV:valid-calendar-data): The time zone specified in the + CALDAV:calendar-timezone property MUST be a valid iCalendar object + containing a single valid VTIMEZONE component; + + (DAV:needs-privilege): The DAV:bind privilege MUST be granted to + the current user on the parent collection of the Request-URI. + + Postconditions: + + (CALDAV:initialize-calendar-collection): A new calendar collection + exists at the Request-URI. The DAV:resourcetype of the calendar + collection MUST contain both DAV:collection and CALDAV:calendar + XML elements. + +<span class="h5"><h5><a class="selflink" name="section-5.3.1.1" href="#section-5.3.1.1">5.3.1.1</a>. Status Codes</h5></span> + + The following are examples of response codes one would expect to get + in a response to a MKCALENDAR request. Note that this list is by no + means exhaustive. + + 201 (Created) - The calendar collection resource was created in + its entirety; + + 207 (Multi-Status) - The calendar collection resource was not + created since one or more DAV:set instructions specified in the + request body could not be processed successfully. The following + are examples of response codes one would expect to be used in a + 207 (Multi-Status) response in this situation: + + 403 (Forbidden) - The client, for reasons the server chooses + not to specify, cannot alter one of the properties; + + 409 (Conflict) - The client has provided a value whose + semantics are not appropriate for the property. This includes + trying to set read-only properties; + + 424 (Failed Dependency) - The DAV:set instruction on the + specified resource would have succeeded if it were not for the + failure of another DAV:set instruction specified in the request + body; + + 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; and + + + + +<span class="grey">Daboo, et al. Standards Track [Page 22]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-23" id="page-23" href="#page-23" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 507 (Insufficient Storage) - The server did not have sufficient + space to record the property; + + 403 (Forbidden) - This indicates at least one of two conditions: + 1) the server does not allow the creation of calendar collections + at the given location in its namespace, or 2) the parent + collection of the Request-URI exists but cannot accept members; + + 409 (Conflict) - A collection cannot be made at the Request-URI + until one or more intermediate collections have been created; + + 415 (Unsupported Media Type) - The server does not support the + request type of the body; and + + 507 (Insufficient Storage) - The resource does not have sufficient + space to record the state of the resource after the execution of + this method. + +<span class="h5"><h5><a class="selflink" name="section-5.3.1.2" href="#section-5.3.1.2">5.3.1.2</a>. Example: Successful MKCALENDAR Request</h5></span> + + This example creates a calendar collection called /home/lisa/ + calendars/events/ on the server cal.example.com with specific values + for the properties DAV:displayname, CALDAV:calendar-description, + CALDAV:supported-calendar-component-set, and CALDAV:calendar- + timezone. + + + + + + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 23]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-24" id="page-24" href="#page-24" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> Request << + + MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1 + Host: cal.example.com + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <C:mkcalendar xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <D:set> + <D:prop> + <D:displayname>Lisa's Events</D:displayname> + <C:calendar-description xml:lang="en" + >Calendar restricted to events.</C:calendar-description> + <C:supported-calendar-component-set> + <C:comp name="VEVENT"/> + </C:supported-calendar-component-set> + <C:calendar-timezone><![CDATA[BEGIN:VCALENDAR + PRODID:-//Example Corp.//CalDAV Client//EN + VERSION:2.0 + BEGIN:VTIMEZONE + TZID:US-Eastern + LAST-MODIFIED:19870101T000000Z + BEGIN:STANDARD + DTSTART:19671029T020000 + RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + TZNAME:Eastern Standard Time (US & Canada) + END:STANDARD + BEGIN:DAYLIGHT + DTSTART:19870405T020000 + RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:Eastern Daylight Time (US & Canada) + END:DAYLIGHT + END:VTIMEZONE + END:VCALENDAR + ]]></C:calendar-timezone> + </D:prop> + </D:set> + </C:mkcalendar> + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 24]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-25" id="page-25" href="#page-25" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> Response << + + HTTP/1.1 201 Created + Cache-Control: no-cache + Date: Sat, 11 Nov 2006 09:32:12 GMT + Content-Length: 0 + +<span class="h4"><h4><a class="selflink" name="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Creating Calendar Object Resources</h4></span> + + Clients populate calendar collections with calendar object resources. + The URL for each calendar object resource is entirely arbitrary and + does not need to bear a specific relationship to the calendar object + resource's iCalendar properties or other metadata. New calendar + object resources MUST be created with a PUT request targeted at an + unmapped URI. A PUT request targeted at a mapped URI updates an + existing calendar object resource. + + When servers create new resources, it's not hard for the server to + choose an unmapped URI. It's slightly tougher for clients, because a + client might not want to examine all resources in the collection and + might not want to lock the entire collection to ensure that a new + resource isn't created with a name collision. However, there is an + HTTP feature to mitigate this. If the client intends to create a new + non-collection resource, such as a new VEVENT, the client SHOULD use + the HTTP request header "If-None-Match: *" on the PUT request. The + Request-URI on the PUT request MUST include the target collection, + where the resource is to be created, plus the name of the resource in + the last path segment. The "If-None-Match: *" request header ensures + that the client will not inadvertently overwrite an existing resource + if the last path segment turned out to already be used. + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 25]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-26" id="page-26" href="#page-26" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> Request << + + PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1 + If-None-Match: * + Host: cal.example.com + Content-Type: text/calendar + Content-Length: xxxx + + BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//Example Corp.//CalDAV Client//EN + BEGIN:VEVENT + UID:20010712T182145Z-123401@example.com + DTSTAMP:20060712T182145Z + DTSTART:20060714T170000Z + DTEND:20060715T040000Z + SUMMARY:Bastille Day Party + END:VEVENT + END:VCALENDAR + + >> Response << + + HTTP/1.1 201 Created + Content-Length: 0 + Date: Sat, 11 Nov 2006 09:32:12 GMT + ETag: "123456789-000-111" + + The request to change an existing event is the same, but with a + specific ETag in the "If-Match" header, rather than the "If-None- + Match" header. + + As indicated in <a href="http://tools.ietf.org/html/rfc2445#section-3.10">Section 3.10 of [RFC2445]</a>, the URL of calendar object + resources containing (an arbitrary set of) calendaring and scheduling + information may be suffixed by ".ics", and the URL of calendar object + resources containing free or busy time information may be suffixed by + ".ifb". + +<span class="h5"><h5><a class="selflink" name="section-5.3.2.1" href="#section-5.3.2.1">5.3.2.1</a>. Additional Preconditions for PUT, COPY, and MOVE</h5></span> + + This specification creates additional Preconditions for PUT, COPY, + and MOVE methods. These preconditions apply when a PUT operation of + a calendar object resource into a calendar collection occurs, or when + a COPY or MOVE operation of a calendar object resource into a + calendar collection occurs, or when a COPY or MOVE operation occurs + on a calendar collection. + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 26]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-27" id="page-27" href="#page-27" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + The new preconditions are: + + (CALDAV:supported-calendar-data): The resource submitted in the + PUT request, or targeted by a COPY or MOVE request, MUST be a + supported media type (i.e., iCalendar) for calendar object + resources; + + (CALDAV:valid-calendar-data): The resource submitted in the PUT + request, or targeted by a COPY or MOVE request, MUST be valid data + for the media type being specified (i.e., MUST contain valid + iCalendar data); + + (CALDAV:valid-calendar-object-resource): The resource submitted in + the PUT request, or targeted by a COPY or MOVE request, MUST obey + all restrictions specified in <a href="#section-4.1">Section 4.1</a> (e.g., calendar object + resources MUST NOT contain more than one type of calendar + component, calendar object resources MUST NOT specify the + iCalendar METHOD property, etc.); + + (CALDAV:supported-calendar-component): The resource submitted in + the PUT request, or targeted by a COPY or MOVE request, MUST + contain a type of calendar component that is supported in the + targeted calendar collection; + + (CALDAV:no-uid-conflict): The resource submitted in the PUT + request, or targeted by a COPY or MOVE request, MUST NOT specify + an iCalendar UID property value already in use in the targeted + calendar collection or overwrite an existing calendar object + resource with one that has a different UID property value. + Servers SHOULD report the URL of the resource that is already + making use of the same UID property value in the DAV:href element; + + <!ELEMENT no-uid-conflict (DAV:href)> + + (CALDAV:calendar-collection-location-ok): In a COPY or MOVE + request, when the Request-URI is a calendar collection, the + Destination-URI MUST identify a location where a calendar + collection can be created; + + (CALDAV:max-resource-size): The resource submitted in the PUT + request, or targeted by a COPY or MOVE request, MUST have an octet + size less than or equal to the value of the CALDAV:max-resource- + size property value (<a href="#section-5.2.5">Section 5.2.5</a>) on the calendar collection + where the resource will be stored; + + (CALDAV:min-date-time): The resource submitted in the PUT request, + or targeted by a COPY or MOVE request, MUST have all of its + iCalendar DATE or DATE-TIME property values (for each recurring + + + +<span class="grey">Daboo, et al. Standards Track [Page 27]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-28" id="page-28" href="#page-28" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + instance) greater than or equal to the value of the CALDAV:min- + date-time property value (<a href="#section-5.2.6">Section 5.2.6</a>) on the calendar + collection where the resource will be stored; + + (CALDAV:max-date-time): The resource submitted in the PUT request, + or targeted by a COPY or MOVE request, MUST have all of its + iCalendar DATE or DATE-TIME property values (for each recurring + instance) less than the value of the CALDAV:max-date-time property + value (<a href="#section-5.2.7">Section 5.2.7</a>) on the calendar collection where the + resource will be stored; + + (CALDAV:max-instances): The resource submitted in the PUT request, + or targeted by a COPY or MOVE request, MUST generate a number of + recurring instances less than or equal to the value of the CALDAV: + max-instances property value (<a href="#section-5.2.8">Section 5.2.8</a>) on the calendar + collection where the resource will be stored; + + (CALDAV:max-attendees-per-instance): The resource submitted in the + PUT request, or targeted by a COPY or MOVE request, MUST have a + number of ATTENDEE properties on any one instance less than or + equal to the value of the CALDAV:max-attendees-per-instance + property value (<a href="#section-5.2.9">Section 5.2.9</a>) on the calendar collection where + the resource will be stored; + +<span class="h4"><h4><a class="selflink" name="section-5.3.3" href="#section-5.3.3">5.3.3</a>. Non-Standard Components, Properties, and Parameters</h4></span> + + iCalendar provides a "standard mechanism for doing non-standard + things". This extension support allows implementers to make use of + non-standard components, properties, and parameters whose names are + prefixed with the text "X-". + + Servers MUST support the use of non-standard components, properties, + and parameters in calendar object resources stored via the PUT + method. + + Servers may need to enforce rules for their own "private" components, + properties, or parameters, so servers MAY reject any attempt by the + client to change those or use values for those outside of any + restrictions the server may have. Servers SHOULD ensure that any + "private" components, properties, or parameters it uses follow the + convention of including a vendor id in the "X-" name, as described in + <a href="http://tools.ietf.org/html/rfc2445#section-4.2">Section 4.2 of [RFC2445]</a>, e.g., "X-ABC-PRIVATE". + +<span class="h4"><h4><a class="selflink" name="section-5.3.4" href="#section-5.3.4">5.3.4</a>. Calendar Object Resource Entity Tag</h4></span> + + The DAV:getetag property MUST be defined and set to a strong entity + tag on all calendar object resources. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 28]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-29" id="page-29" href="#page-29" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + A response to a GET request targeted at a calendar object resource + MUST contain an ETag response header field indicating the current + value of the strong entity tag of the calendar object resource. + + Servers SHOULD return a strong entity tag (ETag header) in a PUT + response when the stored calendar object resource is equivalent by + octet equality to the calendar object resource submitted in the body + of the PUT request. This allows clients to reliably use the returned + strong entity tag for data synchronization purposes. For instance, + the client can do a PROPFIND request on the stored calendar object + resource and have the DAV:getetag property returned, and compare that + value with the strong entity tag it received on the PUT response, and + know that if they are equal, then the calendar object resource on the + server has not been changed. + + In the case where the data stored by a server as a result of a PUT + request is not equivalent by octet equality to the submitted calendar + object resource, the behavior of the ETag response header is not + specified here, with the exception that a strong entity tag MUST NOT + be returned in the response. As a result, clients may need to + retrieve the modified calendar object resource (and ETag) as a basis + for further changes, rather than use the calendar object resource it + had sent with the PUT request. + +<span class="h2"><h2><a class="selflink" name="section-6" href="#section-6">6</a>. Calendaring Access Control</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-6.1" href="#section-6.1">6.1</a>. Calendaring Privilege</h3></span> + + CalDAV servers MUST support and adhere to the requirements of WebDAV + ACL [<a href="http://tools.ietf.org/html/rfc3744" title="" web distributed authoring and versioning access control protocol>RFC3744</a>]. WebDAV ACL provides a framework for an extensible set + of privileges that can be applied to WebDAV collections and ordinary + resources. CalDAV servers MUST also support the calendaring + privilege defined in this section. + +<span class="h4"><h4><a class="selflink" name="section-6.1.1" href="#section-6.1.1">6.1.1</a>. CALDAV:read-free-busy Privilege</h4></span> + + Calendar users often wish to allow other users to see their busy time + information, without viewing the other details of the calendar + components (e.g., location, summary, attendees). This allows a + significant amount of privacy while still allowing other users to + schedule meetings at times when the user is likely to be free. + + The CALDAV:read-free-busy privilege controls which calendar + collections, regular collections, and calendar object resources are + examined when a CALDAV:free-busy-query REPORT request is processed + (see <a href="#section-7.10">Section 7.10</a>). This privilege can be granted on calendar + collections, regular collections, or calendar object resources. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 29]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-30" id="page-30" href="#page-30" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Servers MUST support this privilege on all calendar collections, + regular collections, and calendar object resources. + + + <!ELEMENT read-free-busy EMPTY> + + The CALDAV:read-free-busy privilege MUST be aggregated in the DAV: + read privilege. Servers MUST allow the CALDAV:read-free-busy to be + granted without the DAV:read privilege being granted. + + Clients should note that when only the CALDAV:read-free-busy + privilege has been granted on a resource, access to GET, HEAD, + OPTIONS, and PROPFIND on the resource is not implied (those + operations are governed by the DAV:read privilege). + +<span class="h3"><h3><a class="selflink" name="section-6.2" href="#section-6.2">6.2</a>. Additional Principal Property</h3></span> + + This section defines an additional property for WebDAV principal + resources, as defined in [<a href="http://tools.ietf.org/html/rfc3744" title="" web distributed authoring and versioning access control protocol>RFC3744</a>]. + +<span class="h4"><h4><a class="selflink" name="section-6.2.1" href="#section-6.2.1">6.2.1</a>. CALDAV:calendar-home-set Property</h4></span> + + Name: calendar-home-set + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Identifies the URL of any WebDAV collections that contain + calendar collections owned by the associated principal resource. + + Conformance: This property SHOULD be defined on a principal + resource. If defined, it MAY be protected and SHOULD NOT be + returned by a PROPFIND DAV:allprop request (as defined in <a href="#section-12.14.1">Section</a> + <a href="#section-12.14.1">12.14.1</a> of [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]). + + Description: The CALDAV:calendar-home-set property is meant to allow + users to easily find the calendar collections owned by the + principal. Typically, users will group all the calendar + collections that they own under a common collection. This + property specifies the URL of collections that are either calendar + collections or ordinary collections that have child or descendant + calendar collections owned by the principal. + + Definition: + + <!ELEMENT calendar-home-set (DAV:href*)> + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 30]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-31" id="page-31" href="#page-31" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Example: + + <C:calendar-home-set xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <D:href>http://cal.example.com/home/bernard/calendars/</D:href> + </C:calendar-home-set> + +<span class="h2"><h2><a class="selflink" name="section-7" href="#section-7">7</a>. Calendaring Reports</h2></span> + + 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 <a href="http://tools.ietf.org/html/rfc3253#section-3.1.5">Section 3.1.5 of [RFC3253]</a>. + 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. + +<span class="h3"><h3><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>. REPORT Method</h3></span> + + The REPORT method (defined in <a href="http://tools.ietf.org/html/rfc3253#section-3.6">Section 3.6 of [RFC3253]</a>) 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 + <a href="http://tools.ietf.org/html/rfc3253#section-3.8">Section 3.8 of [RFC3253]</a>. + +<span class="h3"><h3><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>. Ordinary Collections</h3></span> + + 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. + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 31]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-32" id="page-32" href="#page-32" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h3"><h3><a class="selflink" name="section-7.3" href="#section-7.3">7.3</a>. Date and Floating Time</h3></span> + + 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. + +<span class="h3"><h3><a class="selflink" name="section-7.4" href="#section-7.4">7.4</a>. Time Range Filtering</h3></span> + + 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 [<a href="http://tools.ietf.org/html/rfc2445" title="" internet calendaring and scheduling core object specification>RFC2445</a>] for determining the actual start and + end times of calendar components MUST be used, and these are fully + enumerated in <a href="#section-9.9">Section 9.9</a> of this document. + + + +<span class="grey">Daboo, et al. Standards Track [Page 32]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-33" id="page-33" href="#page-33" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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. + +<span class="h3"><h3><a class="selflink" name="section-7.5" href="#section-7.5">7.5</a>. Searching Text: Collations</h3></span> + + 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 [<a href="http://tools.ietf.org/html/rfc4790" title="" internet application protocol collation registry>RFC4790</a>] 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 + <a href="http://tools.ietf.org/html/rfc4790#section-4.2">[RFC4790], Section 4.2</a>. 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 [<a href="http://tools.ietf.org/html/rfc4790" title="" internet application protocol collation registry>RFC4790</a>], 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 <a href="http://tools.ietf.org/html/rfc4790#section-3.1">[RFC4790], Section 3.1</a>), the server MUST default to using + "i;ascii-casemap" as the collation. + + Wildcards (as defined in <a href="http://tools.ietf.org/html/rfc4790#section-3.2">[RFC4790], Section 3.2</a>) 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. + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 33]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-34" id="page-34" href="#page-34" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.5.1" href="#section-7.5.1">7.5.1</a>. CALDAV:supported-collation-set Property</h4></span> + + 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 <a href="http://tools.ietf.org/html/rfc2518#section-12.14.1">Section 12.14.1 of [RFC2518]</a>). + + 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> + +<span class="h3"><h3><a class="selflink" name="section-7.6" href="#section-7.6">7.6</a>. Partial Retrieval</h3></span> + + 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 <a href="#section-9.6">Section 9.6</a>. + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 34]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-35" id="page-35" href="#page-35" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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 <a href="#section-9.6.6">Section 9.6.6</a>). 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 <a href="#section-9.6.5">Section 9.6.5</a>.) + + 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 + <a href="#section-9.6.7">Section 9.6.7</a>.) + +<span class="h3"><h3><a class="selflink" name="section-7.7" href="#section-7.7">7.7</a>. Non-Standard Components, Properties, and Parameters</h3></span> + + 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. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 35]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-36" id="page-36" href="#page-36" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h3"><h3><a class="selflink" name="section-7.8" href="#section-7.8">7.8</a>. CALDAV:calendar-query REPORT</h3></span> + + 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 <a href="#section-9.5">Section 9.5</a>. + + 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 + + + + +<span class="grey">Daboo, et al. Standards Track [Page 36]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-37" id="page-37" href="#page-37" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <a href="#section-9.6">Section 9.6</a>) specify a media type supported by the server for + calendar object resources. + + (CALDAV:valid-filter): The CALDAV:filter XML element (see + <a href="#section-9.7">Section 9.7</a>) 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 + <a href="#section-9.7.1">Section 9.7.1</a>), CALDAV:prop-filter (see <a href="#section-9.7.2">Section 9.7.2</a>), and + CALDAV:param-filter (see <a href="#section-9.7.3">Section 9.7.3</a>) XML elements used in the + CALDAV:filter XML element (see <a href="#section-9.7">Section 9.7</a>) 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 + (<a href="#section-5.2.6">Section 5.2.6</a>) 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 + (<a href="#section-5.2.7">Section 5.2.7</a>) 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 <a href="#section-7.5">Section 7.5</a>. + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 37]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-38" id="page-38" href="#page-38" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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. + +<span class="h4"><h4><a class="selflink" name="section-7.8.1" href="#section-7.8.1">7.8.1</a>. Example: Partial Retrieval of Events by Time Range</h4></span> + + 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 <a href="#appendix-B">Appendix B</a> for the calendar data being targeted by this example. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 38]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-39" id="page-39" href="#page-39" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> 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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 39]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-40" id="page-40" href="#page-40" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <?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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 40]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-41" id="page-41" href="#page-41" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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> + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 41]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-42" id="page-42" href="#page-42" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.8.2" href="#section-7.8.2">7.8.2</a>. Example: Partial Retrieval of Recurring Events</h4></span> + + 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 <a href="#appendix-B">Appendix B</a> 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 + + + + +<span class="grey">Daboo, et al. Standards Track [Page 42]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-43" id="page-43" href="#page-43" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <?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> + + + +<span class="grey">Daboo, et al. Standards Track [Page 43]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-44" id="page-44" href="#page-44" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <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> + + + +<span class="grey">Daboo, et al. Standards Track [Page 44]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-45" id="page-45" href="#page-45" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + </D:response> + </D:multistatus> + +<span class="h4"><h4><a class="selflink" name="section-7.8.3" href="#section-7.8.3">7.8.3</a>. Example: Expanded Retrieval of Recurring Events</h4></span> + + 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 <a href="#appendix-B">Appendix B</a> 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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 45]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-46" id="page-46" href="#page-46" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <?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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 46]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-47" id="page-47" href="#page-47" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 47]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-48" id="page-48" href="#page-48" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.8.4" href="#section-7.8.4">7.8.4</a>. Example: Partial Retrieval of Stored Free Busy Components</h4></span> + + 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 <a href="#appendix-B">Appendix B</a> 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> + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 48]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-49" id="page-49" href="#page-49" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> 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> + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 49]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-50" id="page-50" href="#page-50" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.8.5" href="#section-7.8.5">7.8.5</a>. Example: Retrieval of To-Dos by Alarm Time Range</h4></span> + + 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 <a href="#appendix-B">Appendix B</a> 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> + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 50]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-51" id="page-51" href="#page-51" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> 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> + +<span class="h4"><h4><a class="selflink" name="section-7.8.6" href="#section-7.8.6">7.8.6</a>. Example: Retrieval of Event by UID</h4></span> + + In this example, the client requests the server to return the VEVENT + component that has the UID property set to + "DC6C50A017428C5216A2F1CD@example.com". + + See <a href="#appendix-B">Appendix B</a> for the calendar data being targeted by this example. + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 51]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-52" id="page-52" href="#page-52" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> 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="VEVENT"> + <C:prop-filter name="UID"> + <C:text-match collation="i;octet" + >DC6C50A017428C5216A2F1CD@example.com</C:text-match> + </C:prop-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/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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 52]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-53" id="page-53" href="#page-53" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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> + +<span class="h4"><h4><a class="selflink" name="section-7.8.7" href="#section-7.8.7">7.8.7</a>. Example: Retrieval of Events by PARTSTAT</h4></span> + + In this example, the client requests the server to return the VEVENT + components that have the ATTENDEE property with the value + "mailto:lisa@example.com" and for which the PARTSTAT parameter is set + to NEEDS-ACTION. + + See <a href="#appendix-B">Appendix B</a> for the calendar data being targeted by this example. + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 53]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-54" id="page-54" href="#page-54" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> 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="VEVENT"> + <C:prop-filter name="ATTENDEE"> + <C:text-match collation="i;ascii-casemap" + >mailto:lisa@example.com</C:text-match> + <C:param-filter name="PARTSTAT"> + <C:text-match collation="i;ascii-casemap" + >NEEDS-ACTION</C:text-match> + </C:param-filter> + </C:prop-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/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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 54]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-55" id="page-55" href="#page-55" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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> + +<span class="h4"><h4><a class="selflink" name="section-7.8.8" href="#section-7.8.8">7.8.8</a>. Example: Retrieval of Events Only</h4></span> + + In this example, the client requests the server to return all VEVENT + components. + + See <a href="#appendix-B">Appendix B</a> for the calendar data being targeted by this example. + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 55]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-56" id="page-56" href="#page-56" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> 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="VEVENT"/> + </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/abcd1.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"fffff-abcd1"</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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 56]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-57" id="page-57" href="#page-57" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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:20060206T001102Z + DTSTART;TZID=US/Eastern:20060102T100000 + DURATION:PT1H + SUMMARY:Event #1 + Description:Go Steelers! + UID:74855313FA803DA593CD579A@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/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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 57]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-58" id="page-58" href="#page-58" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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 + BEGIN:VEVENT + DTSTAMP:20060206T001121Z + 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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 58]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-59" id="page-59" href="#page-59" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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> + +<span class="h4"><h4><a class="selflink" name="section-7.8.9" href="#section-7.8.9">7.8.9</a>. Example: Retrieval of All Pending To-Dos</h4></span> + + In this example, the client requests the server to return all VTODO + components that do not include a COMPLETED property and do not have a + STATUS property value matching CANCELLED, i.e., VTODOs that still + need to be worked on. + + See <a href="#appendix-B">Appendix B</a> for the calendar data being targeted by this example. + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 59]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-60" id="page-60" href="#page-60" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + >> 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:prop-filter name="COMPLETED"> + <C:is-not-defined/> + </C:prop-filter> + <C:prop-filter name="STATUS"> + <C:text-match + negate-condition="yes">CANCELLED</C:text-match> + </C:prop-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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 60]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-61" id="page-61" href="#page-61" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + DTSTAMP:20060205T235335Z + DUE;VALUE=DATE:20060104 + STATUS:NEEDS-ACTION + SUMMARY:Task #1 + UID:DDDEEB7915FA61233B861457@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:response> + <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"fffff-abcd5"</D:getetag> + <C:calendar-data>BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//Example Corp.//CalDAV Client//EN + BEGIN:VTODO + DTSTAMP:20060205T235300Z + DUE;VALUE=DATE:20060106 + 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> + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 61]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-62" id="page-62" href="#page-62" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.8.10" href="#section-7.8.10">7.8.10</a>. Example: Attempt to Query Unsupported Property</h4></span> + + In this example, the client requests the server to return all VEVENT + components that include an X-ABC-GUID property with a value matching + "ABC". However, the server does not support querying that non- + standard property, and instead returns an error response. + + See <a href="#appendix-B">Appendix B</a> 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="VEVENT"> + <C:prop-filter name="X-ABC-GUID"> + <C:text-match>ABC</C:text-match> + </C:prop-filter> + </C:comp-filter> + </C:comp-filter> + </C:filter> + </C:calendar-query> + + >> Response << + + HTTP/1.1 403 Forbidden + Date: Sat, 11 Nov 2005 09:32:12 GMT + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <D:error> + <C:supported-filter> + <C:prop-filter name="X-ABC-GUID"/> + </C:supported-filter> + </D:error> + + + + +<span class="grey">Daboo, et al. Standards Track [Page 62]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-63" id="page-63" href="#page-63" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h3"><h3><a class="selflink" name="section-7.9" href="#section-7.9">7.9</a>. CALDAV:calendar-multiget REPORT</h3></span> + + The CALDAV:calendar-multiget REPORT is used to retrieve specific + calendar object resources from within a collection, if the Request- + URI is a collection, or to retrieve a specific calendar object + resource, if the Request-URI is a calendar object resource. This + report is similar to the CALDAV:calendar-query REPORT (see + <a href="#section-7.8">Section 7.8</a>), except that it takes a list of DAV:href elements, + instead of a CALDAV:filter element, to determine which calendar + object resources to return. + + Support for the CALDAV:calendar-multiget REPORT is REQUIRED. + + Marshalling: + + The request body MUST be a CALDAV:calendar-multiget XML element + (see <a href="#section-9.10">Section 9.10</a>). If the Request-URI is a collection resource, + then the DAV:href elements MUST refer to calendar object resources + within that collection, and they MAY refer to calendar object + resources at any depth within the collection. As a result, the + "Depth" header MUST be ignored by the server and SHOULD NOT be + sent by the client. If the Request-URI refers to a non-collection + resource, then there MUST be a single DAV:href element that is + equivalent to the Request-URI. + + The response body for a successful request MUST be a DAV: + multistatus XML element. + + The response body for a successful CALDAV:calendar-multiget REPORT + request MUST contain a DAV:response element for each calendar + object resource referenced by the provided set of DAV:href + elements. Calendar data is being returned in the CALDAV:calendar- + data element inside the DAV:prop element. + + In the case of an error accessing any of the provided DAV:href + resources, the server MUST return the appropriate error status + code in the DAV:status element of the corresponding DAV:response + element. + + Preconditions: + + (CALDAV:supported-calendar-data): The attributes "content-type" + and "version" of the CALDAV:calendar-data XML elements (see + <a href="#section-9.6">Section 9.6</a>) specify a media type supported by the server for + calendar object resources. + + (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 + + + +<span class="grey">Daboo, et al. Standards Track [Page 63]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-64" id="page-64" href="#page-64" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + or equal to the value of the CALDAV:min-date-time property value + (<a href="#section-5.2.6">Section 5.2.6</a>) 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 + (<a href="#section-5.2.7">Section 5.2.7</a>) on the calendar collections being targeted by the + REPORT request; + + Postconditions: + + None. + +<span class="h4"><h4><a class="selflink" name="section-7.9.1" href="#section-7.9.1">7.9.1</a>. Example: Successful CALDAV:calendar-multiget REPORT</h4></span> + + In this example, the client requests the server to return specific + properties of the VEVENT components referenced by specific URIs. In + addition, the DAV:getetag property is also requested and returned as + part of the response. Note that in this example, the resource at + http://cal.example.com/bernard/work/mtg1.ics does not exist, + resulting in an error status response. + + See <a href="#appendix-B">Appendix B</a> for the calendar data being targeted by this example. + + >> Request << + + REPORT /bernard/work/ HTTP/1.1 + Host: cal.example.com + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <C:calendar-multiget xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <D:prop> + <D:getetag/> + <C:calendar-data/> + </D:prop> + <D:href>/bernard/work/abcd1.ics</D:href> + <D:href>/bernard/work/mtg1.ics</D:href> + </C:calendar-multiget> + + >> Response << + + HTTP/1.1 207 Multi-Status + Date: Sat, 11 Nov 2006 09:32:12 GMT + Content-Type: application/xml; charset="utf-8" + + + +<span class="grey">Daboo, et al. Standards Track [Page 64]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-65" id="page-65" href="#page-65" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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/abcd1.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"fffff-abcd1"</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:20060206T001102Z + DTSTART;TZID=US/Eastern:20060102T100000 + DURATION:PT1H + SUMMARY:Event #1 + Description:Go Steelers! + UID:74855313FA803DA593CD579A@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/mtg1.ics</D:href> + <D:status>HTTP/1.1 404 Not Found</D:status> + + + +<span class="grey">Daboo, et al. Standards Track [Page 65]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-66" id="page-66" href="#page-66" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + </D:response> + </D:multistatus> + +<span class="h3"><h3><a class="selflink" name="section-7.10" href="#section-7.10">7.10</a>. CALDAV:free-busy-query REPORT</h3></span> + + The CALDAV:free-busy-query REPORT generates a VFREEBUSY component + containing free busy information for all the calendar object + resources targeted by the request and that have the CALDAV:read-free- + busy or DAV:read privilege granted to the current user. + + Only VEVENT components without a TRANSP property or with the TRANSP + property set to OPAQUE, and VFREEBUSY components SHOULD be considered + in generating the free busy time information. + + In the case of VEVENT components, the free or busy time type (FBTYPE) + of the FREEBUSY properties in the returned VFREEBUSY component SHOULD + be derived from the value of the TRANSP and STATUS properties, as + outlined in the table below: + + +---------------------------++------------------+ + | VEVENT || VFREEBUSY | + +-------------+-------------++------------------+ + | TRANSP | STATUS || FBTYPE | + +=============+=============++==================+ + | | CONFIRMED || BUSY | + | | (default) || | + | OPAQUE +-------------++------------------+ + | (default) | CANCELLED || FREE | + | +-------------++------------------+ + | | TENTATIVE || BUSY-TENTATIVE | + | +-------------++------------------+ + | | x-name || BUSY or | + | | || x-name | + +-------------+-------------++------------------+ + | | CONFIRMED || | + | TRANSPARENT | CANCELLED || FREE | + | | TENTATIVE || | + | | x-name || | + +-------------+-------------++------------------+ + + Duplicate busy time periods with the same FBTYPE parameter value + SHOULD NOT be specified in the returned VFREEBUSY component. Servers + SHOULD coalesce consecutive or overlapping busy time periods of the + same type. Busy time periods with different FBTYPE parameter values + MAY overlap. + + Support for the CALDAV:free-busy-query REPORT is REQUIRED. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 66]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-67" id="page-67" href="#page-67" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Marshalling: + + The request body MUST be a CALDAV:free-busy-query XML element (see + <a href="#section-9.11">Section 9.11</a>), which MUST contain exactly one CALDAV:time-range + XML element, as defined in <a href="#section-9.9">Section 9.9</a>. + + 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 an iCalendar + object that contains exactly one VFREEBUSY component that + describes the busy time intervals for the calendar object + resources containing VEVENT, or VFREEBUSY components that satisfy + the Depth value and for which the current user is at least granted + the CALDAV:read-free-busy privilege. If no calendar object + resources are found to satisfy these conditions, a VFREEBUSY + component with no FREEBUSY property MUST be returned. This report + only returns busy time information. Free time information can be + inferred from the returned busy time information. + + If the current user is not granted the CALDAV:read-free-busy or + DAV:read privileges on the Request-URI, the CALDAV:free-busy-query + REPORT request MUST fail and return a 404 (Not Found) status + value. This restriction will prevent users from discovering URLs + of resources for which they are only granted the CALDAV:read-free- + busy privilege. + + The CALDAV:free-busy-query REPORT request can only be run against + a collection (either a regular collection or a calendar + collection). An attempt to run the report on a calendar object + resource MUST fail and return a 403 (Forbidden) status value. + + Preconditions: + + None. + + Postconditions: + + (DAV:number-of-matches-within-limits): The number of matching + calendar object resources must fall within server-specific, + predefined limits. For example, this postcondition might fail if + the specified CALDAV:time-range would cause an extremely large + number of calendar object resources to be considered in computing + the response. + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 67]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-68" id="page-68" href="#page-68" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.10.1" href="#section-7.10.1">7.10.1</a>. Example: Successful CALDAV:free-busy-query REPORT</h4></span> + + In this example, the client requests the server to return free busy + information on the calendar collection /bernard/work/, between 9:00 + A.M. and 5:00 P.M. EST (2:00 P.M. and 10:00 P.M. UTC) on the January + 4, 2006. The server responds, indicating two busy time intervals of + one hour, one of which is tentative. + + See <a href="#appendix-B">Appendix B</a> 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:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav"> + <C:time-range start="20060104T140000Z" + end="20060105T220000Z"/> + </C:free-busy-query> + + >> Response << + + HTTP/1.1 200 OK + Date: Sat, 11 Nov 2006 09:32:12 GMT + Content-Type: text/calendar + Content-Length: xxxx + + BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//Example Corp.//CalDAV Server//EN + BEGIN:VFREEBUSY + DTSTAMP:20050125T090000Z + DTSTART:20060104T140000Z + DTEND:20060105T220000Z + FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H + FREEBUSY:20060104T190000Z/PT1H + END:VFREEBUSY + END:VCALENDAR + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 68]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-69" id="page-69" href="#page-69" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h2"><h2><a class="selflink" name="section-8" href="#section-8">8</a>. Guidelines</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-8.1" href="#section-8.1">8.1</a>. Client-to-Client Interoperability</h3></span> + + There are a number of actions clients can take that will be legal + (the server will not return errors), but that can degrade + interoperability with other client implementations accessing the same + data. For example, a recurrence rule could be replaced with a set of + recurrence dates, a single recurring event could be replaced with a + set of independent resources to represent each recurrence, or the + start/end time values can be translated from the original time zone + to another time zone. Although this advice amounts to iCalendar + interoperability best practices and is not limited only to CalDAV + usage, interoperability problems are likely to be more evident in + CalDAV use cases. + +<span class="h3"><h3><a class="selflink" name="section-8.2" href="#section-8.2">8.2</a>. Synchronization Operations</h3></span> + + WebDAV already provides functionality required to synchronize a + collection or set of collections, to make changes offline, and + provides a simple way to resolve conflicts when reconnected. ETags + are the key to making this work, but these are not required of all + WebDAV servers. Since offline functionality is more important to + calendar applications than to some other WebDAV applications, CalDAV + servers MUST support ETags, as specified in <a href="#section-5.3.4">Section 5.3.4</a>. + +<span class="h4"><h4><a class="selflink" name="section-8.2.1" href="#section-8.2.1">8.2.1</a>. Use of Reports</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-8.2.1.1" href="#section-8.2.1.1">8.2.1.1</a>. Restrict the Time Range</h5></span> + + The reports provided in CalDAV can be used by clients to optimize + their performance in terms of network bandwidth usage and resource + consumption on the local client machine. Both are certainly major + considerations for mobile or handheld devices with limited capacity, + but they are also relevant to desktop client applications in cases + where the calendar collections contain large amounts of data. + + Typically, clients present calendar data to users in views that span + a finite time interval, so whenever possible, clients should only + retrieve calendar components from the server using CALDAV:calendar- + query REPORT, combined with a CALDAV:time-range element, to limit the + set of returned components to just those needed to populate the + current view. + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 69]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-70" id="page-70" href="#page-70" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h5"><h5><a class="selflink" name="section-8.2.1.2" href="#section-8.2.1.2">8.2.1.2</a>. Synchronize by Time Range</h5></span> + + Typically in a calendar, historical data (events, to-dos, etc. that + have completed prior to the current date) do not change, though they + may be deleted. As a result, a client can speed up the + synchronization process by only considering data for the present time + and the future up to a reasonable limit (e.g., one week, one month). + If the user then tries to examine a portion of the calendar outside + the range that has been synchronized, the client can perform another + synchronization operation on the new time interval being examined. + This "just-in-time" synchronization can minimize bandwidth for common + user interaction behaviors. + +<span class="h5"><h5><a class="selflink" name="section-8.2.1.3" href="#section-8.2.1.3">8.2.1.3</a>. Synchronization Process</h5></span> + + If a client wants to support calendar data synchronization, as + opposed to downloading calendar data each time it is needed, the + client needs to cache the calendar object resource's URI and ETag, + along with the actual calendar data. While the URI remains static + for the lifetime of the calendar object resource, the ETag will + change with each successive change to the calendar object resource. + Thus, to synchronize a local data cache with the server, the client + can first fetch the URI/ETag pairs for the time interval being + considered, and compare those results with the cached data. Any + cached component whose ETag differs from that on the server needs to + be refreshed. + + In order to properly detect the changes between the server and client + data, the client will need to keep a record of which calendar object + resources have been created, changed, or deleted since the last + synchronization operation so that it can reconcile those changes with + the data on the server. + + Here's an example of how to do that: + + The client issues a CALDAV:calendar-query REPORT request for a + specific time range and asks for only the DAV:getetag property to be + returned: + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 70]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-71" id="page-71" href="#page-71" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + 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/> + </D:prop> + <C:filter> + <C:comp-filter name="VCALENDAR"> + <C:comp-filter name="VEVENT"> + <C:time-range start="20040902T000000Z" + end="20040903T000000Z"/> + </C:comp-filter> + </C:comp-filter> + </C:filter> + </C:calendar-query> + + The client then uses the results to determine which calendar object + resources have changed, been created, or deleted on the server, and + how those relate to locally cached calendar object resources that may + have changed, been created, or deleted. If the client determines + that there are calendar object resources on the server that need to + be fetched, the client issues a CALDAV:calendar-multiget REPORT + request to fetch its calendar data: + + REPORT /bernard/work/ HTTP/1.1 + Host: cal.example.com + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <C:calendar-multiget xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <D:prop> + <D:getetag/> + <C:calendar-data/> + </D:prop> + <D:href>/bernard/work/abcd1.ics</D:href> + <D:href>/bernard/work/mtg1.ics</D:href> + </C:calendar-multiget> + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 71]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-72" id="page-72" href="#page-72" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h4"><h4><a class="selflink" name="section-8.2.2" href="#section-8.2.2">8.2.2</a>. Restrict the Properties Returned</h4></span> + + A client may not need all the calendar properties of a calendar + object resource when presenting information to the user. Since some + calendar property values can be large (e.g., ATTACH or ATTENDEE), a + client can choose to restrict the calendar properties to be returned + in a calendaring REPORT request to those it knows it will use. + + However, if a client needs to make a change to a calendar object + resource, it can only change the entire calendar object resource via + a PUT request. There is currently no way to incrementally make a + change to a set of calendar properties of a calendar object resource. + As a result, the client will have to get the entire calendar object + resource that is being changed. + +<span class="h3"><h3><a class="selflink" name="section-8.3" href="#section-8.3">8.3</a>. Use of Locking</h3></span> + + WebDAV locks can be used to prevent two clients that are modifying + the same resource from either overwriting each others' changes + (though that problem can also be solved by using ETags) or wasting + time making changes that will conflict with another set of changes. + In a multi-user calendar system, an interactive calendar client could + lock an event while the user is editing the event, and unlock the + event when the user finishes or cancels. Locks can also be used to + prevent changes while data is being reorganized. For example, a + calendar client might lock two calendar collections prior to moving a + bunch of calendar resources from one to another. + + Clients are responsible for requesting a lock timeout period that is + appropriate to the use case. When the user explicitly decides to + reserve a resource and prevent other changes, a long timeout might be + appropriate, but in cases where the client automatically decides to + lock the resource, the timeout should be short (and the client can + always refresh the lock should it need to). A short lock timeout + means that if the client is unable to remove the lock, the other + calendar users aren't prevented from making changes. + +<span class="h3"><h3><a class="selflink" name="section-8.4" href="#section-8.4">8.4</a>. Finding Calendars</h3></span> + + Much of the time, a calendar client (or agent) will discover a new + calendar's location by being provided directly with the URL. For + example, a user will type his or her own calendar location into + client configuration information or copy and paste a URL from email + into the calendar application. The client need only confirm that the + URL points to a resource that is a calendar collection. The client + may also be able to browse WebDAV collections to find calendar + collections. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 72]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-73" id="page-73" href="#page-73" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + The choice of HTTP URLs means that calendar object resources are + backward compatible with existing software, but does have the + disadvantage that existing software does not usually know to look at + the OPTIONS response to that URL to determine what can be done with + it. This is somewhat of a barrier for WebDAV usage as well as with + CalDAV usage. This specification does not offer a way through this + other than making the information available in the OPTIONS response + should this be requested. + + For calendar sharing and scheduling use cases, one might wish to find + the calendar belonging to another user. If the other user has a + calendar in the same repository, that calendar can be found by using + the principal namespace required by WebDAV ACL support. For other + cases, the authors have no universal solution, but implementers can + consider whether to use vCard [<a href="http://tools.ietf.org/html/rfc2426" title="" vcard mime directory profile>RFC2426</a>] or LDAP [<a href="http://tools.ietf.org/html/rfc4511" title="" lightweight directory access protocol the>RFC4511</a>] standards + together with calendar attributes [<a href="http://tools.ietf.org/html/rfc2739" title="" calendar attributes for vcard and ldap>RFC2739</a>]. + + Because CalDAV requires servers to support WebDAV ACL [<a href="http://tools.ietf.org/html/rfc3744" title="" web distributed authoring and versioning access control protocol>RFC3744</a>], + including principal namespaces, and with the addition of the CALDAV: + calendar-home-set property, there are a couple options for CalDAV + clients to find one's own calendar or another user's calendar. + + In this case, a DAV:principal-match REPORT is used to find a named + property (the CALDAV:calendar-home-set) on the Principal-URL of the + current user. Using this, a WebDAV client can learn "who am I" and + "where are my calendars". The REPORT request body looks like this: + + <?xml version="1.0" encoding="utf-8" ?> + <D:principal-match xmlns:D="DAV:"> + <D:self/> + <D:prop> + <C:calendar-home-set + xmlns:C="urn:ietf:params:xml:ns:caldav"/> + </D:prop> + </D:principal-match> + + To find other users' calendars, the DAV:principal-property-search + REPORT can be used to filter on some properties and return others. + To search for a calendar owned by a user named "Laurie", the REPORT + request body would look like this: + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 73]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-74" id="page-74" href="#page-74" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <?xml version="1.0" encoding="utf-8" ?> + <D:principal-property-search xmlns:D="DAV:"> + <D:property-search> + <D:prop> + <D:displayname/> + </D:prop> + <D:match>Laurie</D:match> + </D:property-search> + <D:prop> + <C:calendar-home-set + xmlns:C="urn:ietf:params:xml:ns:caldav"/> + <D:displayname/> + </D:prop> + </D:principal-property-search> + + The server performs a case-sensitive or caseless search for a + matching string subset of "Laurie" within the DAV:displayname + property. Thus, the server might return "Laurie Dusseault", "Laurier + Desruisseaux", or "Wilfrid Laurier" as matching DAV:displayname + values, and return the calendars for each of these. + +<span class="h3"><h3><a class="selflink" name="section-8.5" href="#section-8.5">8.5</a>. Storing and Using Attachments</h3></span> + + CalDAV clients MAY create attachments in calendar components either + as inline or external. This section contains some guidelines for + creating and managing attachments. + +<span class="h4"><h4><a class="selflink" name="section-8.5.1" href="#section-8.5.1">8.5.1</a>. Inline Attachments</h4></span> + + CalDAV clients MUST support inline attachments as specified in + iCalendar [<a href="http://tools.ietf.org/html/rfc2445" title="" internet calendaring and scheduling core object specification>RFC2445</a>]. CalDAV servers MUST support inline attachments, + so clients can rely on being able to create attachments this way. On + the other hand, inline attachments have some drawbacks: + + o Servers MAY impose limitations on the size of calendar object + resources (i.e., refusing PUT requests of very large iCalendar + objects). Servers that impose such limitations MUST use the + CALDAV:max-resource-size property on a calendar collection to + inform the client as to what the limitation is (see + <a href="#section-5.2.5">Section 5.2.5</a>). + + o Servers MAY impose storage quota limitations on calendar + collections (See [<a href="http://tools.ietf.org/html/rfc4331" title="" quota and size properties for distributed authoring versioning collections>RFC4331</a>]). + + o Any change to a calendar object resource containing an inline + attachment requires the entire inline attachment to be re- + uploaded. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 74]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-75" id="page-75" href="#page-75" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + o Clients synchronizing a changed calendar object resource have to + download the entire calendar object resource, even if the + attachment is unchanged. + +<span class="h4"><h4><a class="selflink" name="section-8.5.2" href="#section-8.5.2">8.5.2</a>. External Attachments</h4></span> + + CalDAV clients SHOULD support downloading of external attachments + referenced by arbitrary URI schemes, by either processing them + directly, or by passing the attachment URI to a suitable "helper + application" for processing, if such an application exists. CalDAV + clients MUST support downloading of external attachments referenced + by the "http" or "https" URI schemes. An external attachment could + be: + + o In a collection in the calendar collection containing the calendar + object resource; + + o Somewhere else in the same repository that hosts the calendar + collection; or + + o On an HTTP or FTP server elsewhere. + + CalDAV servers MAY provide support for child collections in calendar + collections. CalDAV servers MAY allow the MKCOL method to create + child collections in calendar collections. Child collections of + calendar collections MAY contain any type of resource except calendar + collections that they MUST NOT contain. Some CalDAV servers won't + allow child collections in calendar collections, and it may be + possible on such a server to discover other locations where + attachments can be stored. + + Clients are entirely responsible for maintaining reference + consistency with calendar components that link to external + attachments. A client deleting a calendar component with an external + attachment might therefore also delete the attachment if that's + appropriate; however, appropriateness can be very hard to determine. + A new component might easily reference some pre-existing Web resource + that is intended to have independent existence from the calendar + component (the "attachment" could be a major proposal to be discussed + in a meeting, for instance). Best practices will probably emerge and + should probably be documented, but for now, clients should be wary of + engaging in aggressive "cleanup" of external attachments. A client + could involve the user in making decisions about removing + unreferenced documents, or a client could be conservative in only + deleting attachments it had created. + + Also, clients are responsible for consistency of permissions when + using external attachments. One reason for servers to support the + + + +<span class="grey">Daboo, et al. Standards Track [Page 75]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-76" id="page-76" href="#page-76" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + storage of attachments within child collections of calendar + collections is that ACL inheritance might make it easier to grant the + same permissions to attachments that are granted on the calendar + collection. Otherwise, it can be very difficult to keep permissions + synchronized. With attachments stored on separate repositories, it + can be impossible to keep permissions consistent -- the two + repositories may not support the same permissions or have the same + set of principals. Some systems have used tickets or other anonymous + access control mechanisms to provide partially satisfactory solutions + to these kinds of problems. + +<span class="h3"><h3><a class="selflink" name="section-8.6" href="#section-8.6">8.6</a>. Storing and Using Alarms</h3></span> + + Note that all CalDAV calendar collections (including those the user + might treat as public or group calendars) can contain alarm + information on events and to-dos. Users can synchronize a calendar + between multiple devices and decide to have alarms execute on a + different device than the device that created the alarm. Not all + alarm action types are completely interoperable (e.g., those that + name a sound file to play). + + When the action is AUDIO and the client is configured to execute + the alarm, the client SHOULD play the suggested sound if it's + available or play another sound, but SHOULD NOT rewrite the alarm + just to replace the suggested sound with a sound that's locally + available. + + When the action is DISPLAY and the client is configured to execute + the alarm, the client SHOULD execute a display alarm by displaying + according to the suggested description or some reasonable + replacement, but SHOULD NOT rewrite the alarm for its own + convenience. + + When the action is EMAIL and the client is incapable of sending + email, it SHOULD ignore the alarm, but it MUST continue to + synchronize the alarm itself. + + This specification makes no recommendations about executing alarms + of type PROCEDURE, except to note that clients are advised to take + care to avoid creating security holes by executing these. + + Non-interoperable alarm information (e.g., should somebody define a + color to be used in a display alarm) should be put in non-standard + properties inside the VALARM component in order to keep the basic + alarm usable on all devices. + + Clients that allow changes to calendar object resources MUST + synchronize the alarm data that already exists in the resources. + + + +<span class="grey">Daboo, et al. Standards Track [Page 76]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-77" id="page-77" href="#page-77" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Clients MAY execute alarms that are downloaded in this fashion, + possibly based on user preference. If a client is only doing read + operations on a calendar and there is no risk of losing alarm + information, then the client MAY discard alarm information. + + This specification makes no attempt to provide multi-user alarms on + group calendars or to find out for whom an alarm is intended. + Addressing those issues might require extensions to iCalendar; for + example, to store alarms per-user, or to indicate for which user a + VALARM was intended. In the meantime, clients might maximize + interoperability by generally not uploading alarm information to + public, group, or resource calendars. + +<span class="h2"><h2><a class="selflink" name="section-9" href="#section-9">9</a>. XML Element Definitions</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-9.1" href="#section-9.1">9.1</a>. CALDAV:calendar XML Element</h3></span> + + Name: calendar + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies the resource type of a calendar collection. + + Description: See <a href="#section-4.2">Section 4.2</a>. + + Definition: + + <!ELEMENT calendar EMPTY> + +<span class="h3"><h3><a class="selflink" name="section-9.2" href="#section-9.2">9.2</a>. CALDAV:mkcalendar XML Element</h3></span> + + Name: mkcalendar + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a request that includes the WebDAV property + values to be set for a calendar collection resource when it is + created. + + Description: See <a href="#section-5.3.1">Section 5.3.1</a>. + + Definition: + + <!ELEMENT mkcalendar (DAV:set)> + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 77]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-78" id="page-78" href="#page-78" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h3"><h3><a class="selflink" name="section-9.3" href="#section-9.3">9.3</a>. CALDAV:mkcalendar-response XML Element</h3></span> + + Name: mkcalendar-response + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a response body for a successful MKCALENDAR + request. + + Description: See <a href="#section-5.3.1">Section 5.3.1</a>. + + Definition: + + <!ELEMENT mkcalendar-response ANY> + +<span class="h3"><h3><a class="selflink" name="section-9.4" href="#section-9.4">9.4</a>. CALDAV:supported-collation XML Element</h3></span> + + Name: supported-collation + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Identifies a single collation via its collation identifier, + as defined by [<a href="http://tools.ietf.org/html/rfc4790" title="" internet application protocol collation registry>RFC4790</a>]. + + Description: The CALDAV:supported-collation contains the text of a + collation identifier, as described in <a href="#section-7.5.1">Section 7.5.1</a>. + + Definition: + + <!ELEMENT supported-collation (#PCDATA)> + PCDATA value: collation identifier + +<span class="h3"><h3><a class="selflink" name="section-9.5" href="#section-9.5">9.5</a>. CALDAV:calendar-query XML Element</h3></span> + + Name: calendar-query + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Defines a report for querying calendar object resources. + + Description: See <a href="#section-7.8">Section 7.8</a>. + + Definition: + + <!ELEMENT calendar-query ((DAV:allprop | + DAV:propname | + DAV:prop)?, filter, timezone?)> + + + + +<span class="grey">Daboo, et al. Standards Track [Page 78]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-79" id="page-79" href="#page-79" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h3"><h3><a class="selflink" name="section-9.6" href="#section-9.6">9.6</a>. CALDAV:calendar-data XML Element</h3></span> + + Name: calendar-data + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specified one of the following: + + 1. A supported media type for calendar object resources when + nested in the CALDAV:supported-calendar-data property; + + 2. The parts of a calendar object resource should be returned by + a calendaring report; + + 3. The content of a calendar object resource in a response to a + calendaring report. + + Description: When nested in the CALDAV:supported-calendar-data + property, the CALDAV:calendar-data XML element specifies a media + type supported by the CalDAV server for calendar object resources. + + When used in a calendaring REPORT request, the CALDAV:calendar- + data XML element specifies which parts of calendar object + resources need to be returned in the response. If the CALDAV: + calendar-data XML element doesn't contain any CALDAV:comp element, + calendar object resources will be returned in their entirety. + + Finally, when used in a calendaring REPORT response, the CALDAV: + calendar-data XML element specifies the content of a calendar + object resource. Given that XML parsers normalize the two- + character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal + 10) to a single LF character (US-ASCII decimal 10), the CR + character (US-ASCII decimal 13) MAY be omitted in calendar object + resources specified in the CALDAV:calendar-data XML element. + Furthermore, calendar object resources specified in the CALDAV: + calendar-data XML element MAY be invalid per their media type + specification if the CALDAV:calendar-data XML element part of the + calendaring REPORT request did not specify required properties + (e.g., UID, DTSTAMP, etc.), or specified a CALDAV:prop XML element + with the "novalue" attribute set to "yes". + + Note: The CALDAV:calendar-data XML element is specified in requests + and responses inside the DAV:prop XML element as if it were a + WebDAV property. However, the CALDAV:calendar-data XML element is + not a WebDAV property and, as such, is not returned in PROPFIND + responses, nor used in PROPPATCH requests. + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 79]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-80" id="page-80" href="#page-80" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Note: The iCalendar data embedded within the CALDAV:calendar-data + XML element MUST follow the standard XML character data encoding + rules, including use of &lt;, &gt;, &amp; etc. entity encoding or + the use of a <![CDATA[ ... ]]> construct. In the later case, the + iCalendar data cannot contain the character sequence "]]>", which + is the end delimiter for the CDATA section. + + Definition: + + <!ELEMENT calendar-data EMPTY> + + when nested in the CALDAV:supported-calendar-data property + to specify a supported media type for calendar object + resources; + + <!ELEMENT calendar-data (comp?, + (expand | limit-recurrence-set)?, + limit-freebusy-set?)> + + when nested in the DAV:prop XML element in a calendaring + REPORT request to specify which parts of calendar object + resources should be returned in the response; + + <!ELEMENT calendar-data (#PCDATA)> + PCDATA value: iCalendar object + + when nested in the DAV:prop XML element in a calendaring + REPORT response to specify the content of a returned + calendar object resource. + + <!ATTLIST calendar-data content-type CDATA "text/calendar" + version CDATA "2.0"> + content-type value: a MIME media type + version value: a version string + + attributes can be used on all three variants of the + CALDAV:calendar-data XML element. + +<span class="h4"><h4><a class="selflink" name="section-9.6.1" href="#section-9.6.1">9.6.1</a>. CALDAV:comp XML Element</h4></span> + + Name: comp + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Defines which component types to return. + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 80]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-81" id="page-81" href="#page-81" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Description: The name value is a calendar component name (e.g., + VEVENT). + + Definition: + + <!ELEMENT comp ((allprop | prop*), (allcomp | comp*))> + + <!ATTLIST comp name CDATA #REQUIRED> + name value: a calendar component name + + Note: The CALDAV:prop and CALDAV:allprop elements have the same name + as the DAV:prop and DAV:allprop elements defined in [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]. + However, the CALDAV:prop and CALDAV:allprop elements are defined + in the "urn:ietf:params:xml:ns:caldav" namespace instead of the + "DAV:" namespace. + +<span class="h4"><h4><a class="selflink" name="section-9.6.2" href="#section-9.6.2">9.6.2</a>. CALDAV:allcomp XML Element</h4></span> + + Name: allcomp + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies that all components shall be returned. + + Description: The CALDAV:allcomp XML element can be used when the + client wants all types of components returned by a calendaring + REPORT request. + + Definition: + + <!ELEMENT allcomp EMPTY> + +<span class="h4"><h4><a class="selflink" name="section-9.6.3" href="#section-9.6.3">9.6.3</a>. CALDAV:allprop XML Element</h4></span> + + Name: allprop + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies that all properties shall be returned. + + Description: The CALDAV:allprop XML element can be used when the + client wants all properties of components returned by a + calendaring REPORT request. + + Definition: + + <!ELEMENT allprop EMPTY> + + + + +<span class="grey">Daboo, et al. Standards Track [Page 81]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-82" id="page-82" href="#page-82" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Note: The CALDAV:allprop element has the same name as the DAV: + allprop element defined in [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]. However, the CALDAV:allprop + element is defined in the "urn:ietf:params:xml:ns:caldav" + namespace instead of the "DAV:" namespace. + +<span class="h4"><h4><a class="selflink" name="section-9.6.4" href="#section-9.6.4">9.6.4</a>. CALDAV:prop XML Element</h4></span> + + Name: prop + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Defines which properties to return in the response. + + Description: The "name" attribute specifies the name of the calendar + property to return (e.g., ATTENDEE). The "novalue" attribute can + be used by clients to request that the actual value of the + property not be returned (if the "novalue" attribute is set to + "yes"). In that case, the server will return just the iCalendar + property name and any iCalendar parameters and a trailing ":" + without the subsequent value data. + + Definition: + + <!ELEMENT prop EMPTY> + + <!ATTLIST prop name CDATA #REQUIRED + novalue (yes | no) "no"> + name value: a calendar property name + novalue value: "yes" or "no" + + Note: The CALDAV:prop element has the same name as the DAV:prop + element defined in [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>]. However, the CALDAV:prop element is + defined in the "urn:ietf:params:xml:ns:caldav" namespace instead + of the "DAV:" namespace. + +<span class="h4"><h4><a class="selflink" name="section-9.6.5" href="#section-9.6.5">9.6.5</a>. CALDAV:expand XML Element</h4></span> + + Name: expand + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Forces the server to expand recurring components into + individual recurrence instances. + + Description: The CALDAV:expand XML element specifies that for a + given calendaring REPORT request, the server MUST expand the + recurrence set into calendar components that define exactly one + + + + +<span class="grey">Daboo, et al. Standards Track [Page 82]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-83" id="page-83" href="#page-83" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + recurrence instance, and MUST return only those whose scheduled + time intersect a specified time range. + + The "start" attribute specifies the inclusive start of the time + range, and the "end" attribute specifies the non-inclusive end of + the time range. Both attributes are specified as date with UTC + time value. The value of the "end" attribute MUST be greater than + the value of the "start" attribute. + + The server MUST use the same logic as defined for CALDAV:time- + range to determine if a recurrence instance intersects the + specified time range. + + Recurring components, other than the initial instance, MUST + include a RECURRENCE-ID property indicating which instance they + refer to. + + The returned calendar components MUST NOT use recurrence + properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT + have reference to or include VTIMEZONE components. Date and local + time with reference to time zone information MUST be converted + into date with UTC time. + + Definition: + + <!ELEMENT expand EMPTY> + + <!ATTLIST expand start CDATA #REQUIRED + end CDATA #REQUIRED> + start value: an iCalendar "date with UTC time" + end value: an iCalendar "date with UTC time" + +<span class="h4"><h4><a class="selflink" name="section-9.6.6" href="#section-9.6.6">9.6.6</a>. CALDAV:limit-recurrence-set XML Element</h4></span> + + Name: limit-recurrence-set + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a time range to limit the set of "overridden + components" returned by the server. + + Description: The CALDAV:limit-recurrence-set XML element specifies + that for a given calendaring REPORT request, the server MUST + return, in addition to the "master component", only the + "overridden components" that impact a specified time range. 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 + + + + +<span class="grey">Daboo, et al. Standards Track [Page 83]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-84" id="page-84" href="#page-84" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + times -- the ones that would have been used if the instance were + not overridden -- overlap the time range. + + The "start" attribute specifies the inclusive start of the time + range, and the "end" attribute specifies the non-inclusive end of + the time range. Both attributes are specified as date with UTC + time value. The value of the "end" attribute MUST be greater than + the value of the "start" attribute. + + The server MUST use the same logic as defined for CALDAV:time- + range to determine if the current or original scheduled time of an + "overridden" recurrence instance intersects the specified time + range. + + Overridden components that have a RANGE parameter on their + RECURRENCE-ID property may specify one or more instances in the + recurrence set, and some of those instances may fall within the + specified time range or may have originally fallen within the + specified time range prior to being overridden. If that is the + case, the overridden component MUST be included in the results, as + it has a direct impact on the interpretation of instances within + the specified time range. + + Definition: + + <!ELEMENT limit-recurrence-set EMPTY> + + <!ATTLIST limit-recurrence-set start CDATA #REQUIRED + end CDATA #REQUIRED> + start value: an iCalendar "date with UTC time" + end value: an iCalendar "date with UTC time" + +<span class="h4"><h4><a class="selflink" name="section-9.6.7" href="#section-9.6.7">9.6.7</a>. CALDAV:limit-freebusy-set XML Element</h4></span> + + Name: limit-freebusy-set + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a time range to limit the set of FREEBUSY values + returned by the server. + + Description: The CALDAV:limit-freebusy-set XML element specifies + that for a given calendaring REPORT request, the server MUST only + return the FREEBUSY property values of a VFREEBUSY component that + intersects a specified time range. + + The "start" attribute specifies the inclusive start of the time + range, and the "end" attribute specifies the non-inclusive end of + + + +<span class="grey">Daboo, et al. Standards Track [Page 84]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-85" id="page-85" href="#page-85" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + the time range. Both attributes are specified as "date with UTC + time" value. The value of the "end" attribute MUST be greater + than the value of the "start" attribute. + + The server MUST use the same logic as defined for CALDAV:time- + range to determine if a FREEBUSY property value intersects the + specified time range. + + Definition: + + <!ELEMENT limit-freebusy-set EMPTY> + + <!ATTLIST limit-freebusy-set start CDATA #REQUIRED + end CDATA #REQUIRED> + start value: an iCalendar "date with UTC time" + end value: an iCalendar "date with UTC time" + +<span class="h3"><h3><a class="selflink" name="section-9.7" href="#section-9.7">9.7</a>. CALDAV:filter XML Element</h3></span> + + Name: filter + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a filter to limit the set of calendar components + returned by the server. + + Description: The CALDAV:filter XML element specifies the search + filter used to limit the calendar components returned by a + calendaring REPORT request. + + Definition: + + <!ELEMENT filter (comp-filter)> + +<span class="h4"><h4><a class="selflink" name="section-9.7.1" href="#section-9.7.1">9.7.1</a>. CALDAV:comp-filter XML Element</h4></span> + + Name: comp-filter + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies search criteria on calendar components. + + Description: The CALDAV:comp-filter XML element specifies a query + targeted at the calendar object (i.e., VCALENDAR) or at a specific + calendar component type (e.g., VEVENT). The scope of the + CALDAV:comp-filter XML element is the calendar object when used as + a child of the CALDAV:filter XML element. The scope of the + CALDAV:comp-filter XML element is the enclosing calendar component + + + +<span class="grey">Daboo, et al. Standards Track [Page 85]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-86" id="page-86" href="#page-86" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + when used as a child of another CALDAV:comp-filter XML element. A + CALDAV:comp-filter is said to match if: + + * The CALDAV:comp-filter XML element is empty and the calendar + object or calendar component type specified by the "name" + attribute exists in the current scope; + + or: + + * The CALDAV:comp-filter XML element contains a CALDAV:is-not- + defined XML element and the calendar object or calendar + component type specified by the "name" attribute does not exist + in the current scope; + + or: + + * The CALDAV:comp-filter XML element contains a CALDAV:time-range + XML element and at least one recurrence instance in the + targeted calendar component is scheduled to overlap the + specified time range, and all specified CALDAV:prop-filter and + CALDAV:comp-filter child XML elements also match the targeted + calendar component; + + or: + + * The CALDAV:comp-filter XML element only contains CALDAV:prop- + filter and CALDAV:comp-filter child XML elements that all match + the targeted calendar component. + + Definition: + + <!ELEMENT comp-filter (is-not-defined | (time-range?, + prop-filter*, comp-filter*))> + + <!ATTLIST comp-filter name CDATA #REQUIRED> + name value: a calendar object or calendar component + type (e.g., VEVENT) + +<span class="h4"><h4><a class="selflink" name="section-9.7.2" href="#section-9.7.2">9.7.2</a>. CALDAV:prop-filter XML Element</h4></span> + + Name: prop-filter + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies search criteria on calendar properties. + + Description: The CALDAV:prop-filter XML element specifies a query + targeted at a specific calendar property (e.g., CATEGORIES) in the + + + +<span class="grey">Daboo, et al. Standards Track [Page 86]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-87" id="page-87" href="#page-87" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + scope of the enclosing calendar component. A calendar property is + said to match a CALDAV:prop-filter if: + + * The CALDAV:prop-filter XML element is empty and a property of + the type specified by the "name" attribute exists in the + enclosing calendar component; + + or: + + * The CALDAV:prop-filter XML element contains a CALDAV:is-not- + defined XML element and no property of the type specified by + the "name" attribute exists in the enclosing calendar + component; + + or: + + * The CALDAV:prop-filter XML element contains a CALDAV:time-range + XML element and the property value overlaps the specified time + range, and all specified CALDAV:param-filter child XML elements + also match the targeted property; + + or: + + * The CALDAV:prop-filter XML element contains a CALDAV:text-match + XML element and the property value matches it, and all + specified CALDAV:param-filter child XML elements also match the + targeted property; + + Definition: + + <!ELEMENT prop-filter (is-not-defined | + ((time-range | text-match)?, + param-filter*))> + + <!ATTLIST prop-filter name CDATA #REQUIRED> + name value: a calendar property name (e.g., ATTENDEE) + +<span class="h4"><h4><a class="selflink" name="section-9.7.3" href="#section-9.7.3">9.7.3</a>. CALDAV:param-filter XML Element</h4></span> + + Name: param-filter + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Limits the search to specific parameter values. + + Description: The CALDAV:param-filter XML element specifies a query + targeted at a specific calendar property parameter (e.g., + PARTSTAT) in the scope of the calendar property on which it is + + + +<span class="grey">Daboo, et al. Standards Track [Page 87]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-88" id="page-88" href="#page-88" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + defined. A calendar property parameter is said to match a CALDAV: + param-filter if: + + * The CALDAV:param-filter XML element is empty and a parameter of + the type specified by the "name" attribute exists on the + calendar property being examined; + + or: + + * The CALDAV:param-filter XML element contains a CALDAV:is-not- + defined XML element and no parameter of the type specified by + the "name" attribute exists on the calendar property being + examined; + + Definition: + + <!ELEMENT param-filter (is-not-defined | text-match?)> + + <!ATTLIST param-filter name CDATA #REQUIRED> + name value: a property parameter name (e.g., PARTSTAT) + +<span class="h4"><h4><a class="selflink" name="section-9.7.4" href="#section-9.7.4">9.7.4</a>. CALDAV:is-not-defined XML Element</h4></span> + + Name: is-not-defined + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies that a match should occur if the enclosing + component, property, or parameter does not exist. + + Description: The CALDAV:is-not-defined XML element specifies that a + match occurs if the enclosing component, property, or parameter + value specified in a calendaring REPORT request does not exist in + the calendar data being tested. + + Definition: + + <!ELEMENT is-not-defined EMPTY> + +<span class="h4"><h4><a class="selflink" name="section-9.7.5" href="#section-9.7.5">9.7.5</a>. CALDAV:text-match XML Element</h4></span> + + Name: text-match + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a substring match on a property or parameter + value. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 88]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-89" id="page-89" href="#page-89" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + Description: The CALDAV:text-match XML element specifies text used + for a substring match against the property or parameter value + specified in a calendaring REPORT request. + + The "collation" attribute is used to select the collation that the + server MUST use for character string matching. In the absence of + this attribute, the server MUST use the "i;ascii-casemap" + collation. + + The "negate-condition" attribute is used to indicate that this + test returns a match if the text matches when the attribute value + is set to "no", or return a match if the text does not match, if + the attribute value is set to "yes". For example, this can be + used to match components with a STATUS property not set to + CANCELLED. + + Definition: + + <!ELEMENT text-match (#PCDATA)> + PCDATA value: string + + <!ATTLIST text-match collation CDATA "i;ascii-casemap" + negate-condition (yes | no) "no"> + +<span class="h3"><h3><a class="selflink" name="section-9.8" href="#section-9.8">9.8</a>. CALDAV:timezone XML Element</h3></span> + + Name: timezone + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies the time zone component to use when determining + the results of a report. + + Description: The CALDAV:timezone XML element specifies that for a + given calendaring REPORT request, the server MUST rely on the + specified VTIMEZONE component instead of the CALDAV:calendar- + timezone property of the calendar collection, in which the + calendar object resource is contained to resolve "date" values and + "date with local time" values (i.e., floating time) to "date with + UTC time" values. The server will require this information to + determine if a calendar component scheduled with "date" values or + "date with local time" values intersects a CALDAV:time-range + specified in a CALDAV:calendar-query REPORT. + + Note: The iCalendar data embedded within the CALDAV:timezone XML + element MUST follow the standard XML character data encoding + rules, including use of &lt;, &gt;, &amp; etc. entity encoding or + the use of a <![CDATA[ ... ]]> construct. In the later case, the + + + +<span class="grey">Daboo, et al. Standards Track [Page 89]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-90" id="page-90" href="#page-90" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + iCalendar data cannot contain the character sequence "]]>", which + is the end delimiter for the CDATA section. + + Definition: + + <!ELEMENT timezone (#PCDATA)> + PCDATA value: an iCalendar object with exactly one VTIMEZONE + +<span class="h3"><h3><a class="selflink" name="section-9.9" href="#section-9.9">9.9</a>. CALDAV:time-range XML Element</h3></span> + + Name: time-range + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: Specifies a time range to limit the set of calendar + components returned by the server. + + Description: The CALDAV:time-range XML element specifies that for a + given calendaring REPORT request, the server MUST only return the + calendar object resources that, depending on the context, have a + component or property whose value intersects a specified time + range. + + The "start" attribute specifies the inclusive start of the time + range, and the "end" attribute specifies the non-inclusive end of + the time range. Both attributes MUST be specified as "date with + UTC time" value. Time ranges open at one end can be specified by + including only one attribute; however, at least one attribute MUST + always be present in the CALDAV:time-range element. If either the + "start" or "end" attribute is not specified in the CALDAV:time- + range XML element, assume "-infinity" and "+infinity" as their + value, respectively. If both "start" and "end" are present, the + value of the "end" attribute MUST be greater than the value of the + "start" attribute. + + Time range tests MUST consider every recurrence instance when + testing the time range condition; if any one instance matches, + then the test returns true. Testing recurrence instances requires + the server to infer an effective value for DTSTART, DTEND, + DURATION, and DUE properties for an instance based on the + recurrence patterns and any overrides. + + A VEVENT component overlaps a given time range if the condition + for the corresponding component state specified in the table below + is satisfied. Note that, as specified in [<a href="http://tools.ietf.org/html/rfc2445" title="" internet calendaring and scheduling core object specification>RFC2445</a>], the DTSTART + property is REQUIRED in the VEVENT component. The conditions + depend on the presence of the DTEND and DURATION properties in the + VEVENT component. Furthermore, the value of the DTEND property + + + +<span class="grey">Daboo, et al. Standards Track [Page 90]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-91" id="page-91" href="#page-91" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + MUST be later in time than the value of the DTSTART property. The + duration of a VEVENT component with no DTEND and DURATION + properties is 1 day (+P1D) when the DTSTART is a DATE value, and 0 + seconds when the DTSTART is a DATE-TIME value. + + +---------------------------------------------------------------+ + | VEVENT has the DTEND property? | + | +-----------------------------------------------------------+ + | | VEVENT has the DURATION property? | + | | +-------------------------------------------------------+ + | | | DURATION property value is greater than 0 seconds? | + | | | +---------------------------------------------------+ + | | | | DTSTART property is a DATE-TIME value? | + | | | | +-----------------------------------------------+ + | | | | | Condition to evaluate | + +---+---+---+---+-----------------------------------------------+ + | Y | N | N | * | (start < DTEND AND end > DTSTART) | + +---+---+---+---+-----------------------------------------------+ + | N | Y | Y | * | (start < DTSTART+DURATION AND end > DTSTART) | + | | +---+---+-----------------------------------------------+ + | | | N | * | (start <= DTSTART AND end > DTSTART) | + +---+---+---+---+-----------------------------------------------+ + | N | N | N | Y | (start <= DTSTART AND end > DTSTART) | + +---+---+---+---+-----------------------------------------------+ + | N | N | N | N | (start < DTSTART+P1D AND end > DTSTART) | + +---+---+---+---+-----------------------------------------------+ + + A VTODO component is said to overlap a given time range if the + condition for the corresponding component state specified in the + table below is satisfied. The conditions depend on the presence + of the DTSTART, DURATION, DUE, COMPLETED, and CREATED properties + in the VTODO component. Note that, as specified in [<a href="http://tools.ietf.org/html/rfc2445" title="" internet calendaring and scheduling core object specification>RFC2445</a>], the + DUE value MUST be a DATE-TIME value equal to or after the DTSTART + value if specified. + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 91]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-92" id="page-92" href="#page-92" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + +-------------------------------------------------------------------+ + | VTODO has the DTSTART property? | + | +---------------------------------------------------------------+ + | | VTODO has the DURATION property? | + | | +-----------------------------------------------------------+ + | | | VTODO has the DUE property? | + | | | +-------------------------------------------------------+ + | | | | VTODO has the COMPLETED property? | + | | | | +---------------------------------------------------+ + | | | | | VTODO has the CREATED property? | + | | | | | +-----------------------------------------------+ + | | | | | | Condition to evaluate | + +---+---+---+---+---+-----------------------------------------------+ + | Y | Y | N | * | * | (start <= DTSTART+DURATION) AND | + | | | | | | ((end > DTSTART) OR | + | | | | | | (end >= DTSTART+DURATION)) | + +---+---+---+---+---+-----------------------------------------------+ + | Y | N | Y | * | * | ((start < DUE) OR (start <= DTSTART)) | + | | | | | | AND | + | | | | | | ((end > DTSTART) OR (end >= DUE)) | + +---+---+---+---+---+-----------------------------------------------+ + | Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) | + +---+---+---+---+---+-----------------------------------------------+ + | N | N | Y | * | * | (start < DUE) AND (end >= DUE) | + +---+---+---+---+---+-----------------------------------------------+ + | N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))| + | | | | | | AND | + | | | | | | ((end >= CREATED) OR (end >= COMPLETED))| + +---+---+---+---+---+-----------------------------------------------+ + | N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) | + +---+---+---+---+---+-----------------------------------------------+ + | N | N | N | N | Y | (end > CREATED) | + +---+---+---+---+---+-----------------------------------------------+ + | N | N | N | N | N | TRUE | + +---+---+---+---+---+-----------------------------------------------+ + + A VJOURNAL component overlaps a given time range if the condition + for the corresponding component state specified in the table below + is satisfied. The conditions depend on the presence of the + DTSTART property in the VJOURNAL component and on whether the + DTSTART is a DATE-TIME or DATE value. The effective "duration" of + a VJOURNAL component is 1 day (+P1D) when the DTSTART is a DATE + value, and 0 seconds when the DTSTART is a DATE-TIME value. + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 92]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-93" id="page-93" href="#page-93" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + +----------------------------------------------------+ + | VJOURNAL has the DTSTART property? | + | +------------------------------------------------+ + | | DTSTART property is a DATE-TIME value? | + | | +--------------------------------------------+ + | | | Condition to evaluate | + +---+---+--------------------------------------------+ + | Y | Y | (start <= DTSTART) AND (end > DTSTART) | + +---+---+--------------------------------------------+ + | Y | N | (start < DTSTART+P1D) AND (end > DTSTART) | + +---+---+--------------------------------------------+ + | N | * | FALSE | + +---+---+--------------------------------------------+ + + A VFREEBUSY component overlaps a given time range if the condition + for the corresponding component state specified in the table below + is satisfied. The conditions depend on the presence in the + VFREEBUSY component of the DTSTART and DTEND properties, and any + FREEBUSY properties in the absence of DTSTART and DTEND. Any + DURATION property is ignored, as it has a special meaning when + used in a VFREEBUSY component. + + When only FREEBUSY properties are used, each period in each + FREEBUSY property is compared against the time range, irrespective + of the type of free busy information (free, busy, busy-tentative, + busy-unavailable) represented by the property. + + + +------------------------------------------------------+ + | VFREEBUSY has both the DTSTART and DTEND properties? | + | +--------------------------------------------------+ + | | VFREEBUSY has the FREEBUSY property? | + | | +----------------------------------------------+ + | | | Condition to evaluate | + +---+---+----------------------------------------------+ + | Y | * | (start <= DTEND) AND (end > DTSTART) | + +---+---+----------------------------------------------+ + | N | Y | (start < freebusy-period-end) AND | + | | | (end > freebusy-period-start) | + +---+---+----------------------------------------------+ + | N | N | FALSE | + +---+---+----------------------------------------------+ + + A VALARM component is said to overlap a given time range if the + following condition holds: + + (start <= trigger-time) AND (end > trigger-time) + + + + +<span class="grey">Daboo, et al. Standards Track [Page 93]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-94" id="page-94" href="#page-94" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + A VALARM component can be defined such that it triggers repeatedly. + Such a VALARM component is said to overlap a given time range if at + least one of its triggers overlaps the time range. + + The calendar properties COMPLETED, CREATED, DTEND, DTSTAMP, + DTSTART, DUE, and LAST-MODIFIED overlap a given time range if the + following condition holds: + + (start <= date-time) AND (end > date-time) + + Note that if DTEND is not present in a VEVENT, but DURATION is, then + the test should instead operate on the 'effective' DTEND, i.e., + DTSTART+DURATION. Similarly, if DUE is not present in a VTODO, but + DTSTART and DURATION are, then the test should instead operate on the + 'effective' DUE, i.e., DTSTART+DURATION. + + The semantic of CALDAV:time-range is not defined for any other + calendar components and properties. + + Definition: + + <!ELEMENT time-range EMPTY> + + <!ATTLIST time-range start CDATA #IMPLIED + end CDATA #IMPLIED> + start value: an iCalendar "date with UTC time" + end value: an iCalendar "date with UTC time" + +<span class="h3"><h3><a class="selflink" name="section-9.10" href="#section-9.10">9.10</a>. CALDAV:calendar-multiget XML Element</h3></span> + + Name: calendar-multiget + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: CalDAV report used to retrieve specific calendar object + resources. + + Description: See <a href="#section-7.9">Section 7.9</a>. + + Definition: + + <!ELEMENT calendar-multiget ((DAV:allprop | + DAV:propname | + DAV:prop)?, DAV:href+)> + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 94]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-95" id="page-95" href="#page-95" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h3"><h3><a class="selflink" name="section-9.11" href="#section-9.11">9.11</a>. CALDAV:free-busy-query XML Element</h3></span> + + Name: free-busy-query + + Namespace: urn:ietf:params:xml:ns:caldav + + Purpose: CalDAV report used to generate a VFREEBUSY to determine + busy time over a specific time range. + + Description: See <a href="#section-7.10">Section 7.10</a>. + + Definition: + + <!ELEMENT free-busy-query (time-range)> + +<span class="h2"><h2><a class="selflink" name="section-10" href="#section-10">10</a>. Internationalization Considerations</h2></span> + + CalDAV allows internationalized strings to be stored and retrieved + for the description of calendar collections (see <a href="#section-5.2.1">Section 5.2.1</a>). + + The CALDAV:calendar-query REPORT (<a href="#section-7.8">Section 7.8</a>) includes a text + searching option controlled by the CALDAV:text-match element, and + details of character handling are covered in the description of that + element (see <a href="#section-9.7.5">Section 9.7.5</a>). + +<span class="h2"><h2><a class="selflink" name="section-11" href="#section-11">11</a>. Security Considerations</h2></span> + + HTTP protocol transactions are sent in the clear over the network + unless protection from snooping is negotiated. This can be + accomplished by use of TLS, as defined in [<a href="http://tools.ietf.org/html/rfc2818" title="" http over tls>RFC2818</a>]. In particular, + HTTP Basic authentication MUST NOT be used unless TLS is in effect. + + Servers MUST take adequate precautions to ensure that malicious + clients cannot consume excessive server resources (CPU, memory, disk, + etc.) through carefully crafted reports. For example, a client could + upload an event with a recurrence rule that specifies a recurring + event occurring every second for the next 100 years, which would + result in approximately 3 x 10^9 instances! A report that asks for + recurrences to be expanded over that range would likely constitute a + denial-of-service attack on the server. + + When creating new resources (including calendar collections), clients + MUST ensure that the resource name (the last path segment of the + resource URI) assigned to the new resource does not expose any data + from within the iCalendar resource itself or information about the + nature of a calendar collection. This is required to ensure that the + presence of a specific iCalendar component or nature of components in + a collection cannot be inferred based on the name of a resource. + + + +<span class="grey">Daboo, et al. Standards Track [Page 95]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-96" id="page-96" href="#page-96" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + When rolling up free-busy information, more information about a + user's events is exposed if busy periods overlap or are adjacent + (this tells the client requesting the free-busy information that the + calendar owner has at least two events, rather than knowing only that + the calendar owner has one or more events during the busy period). + Thus, a conservative approach to calendar data privacy would have + servers always coalesce such busy periods when they are the same + type. + + Procedure alarms are a known security risk for either clients or + servers to handle, particularly when the alarm was created by another + agent. Clients and servers are not required to execute such + procedure alarms. + + Security considerations described in iCalendar [<a href="http://tools.ietf.org/html/rfc2445" title="" internet calendaring and scheduling core object specification>RFC2445</a>] and iTIP + [<a href="http://tools.ietf.org/html/rfc2446" title="" icalendar transport-independent interoperability protocol scheduling events busytime to-dos and journal entries>RFC2446</a>] are also applicable to CalDAV. + + Beyond these, CalDAV does not raise any security considerations that + are not present in HTTP [<a href="http://tools.ietf.org/html/rfc2616" title="" hypertext transfer protocol http>RFC2616</a>] and WebDAV [<a href="http://tools.ietf.org/html/rfc2518" title="" http extensions for distributed authoring webdav>RFC2518</a>], [<a href="http://tools.ietf.org/html/rfc3253" title="" versioning extensions to webdav distributed authoring and>RFC3253</a>], + [<a href="http://tools.ietf.org/html/rfc3744" title="" web distributed authoring and versioning access control protocol>RFC3744</a>]. + +<span class="h2"><h2><a class="selflink" name="section-12" href="#section-12">12</a>. IANA Considerations</h2></span> + + This document uses one new URN to identify a new XML namespace. The + URN conforms to a registry mechanism described in [<a href="http://tools.ietf.org/html/rfc3688" title="" the ietf xml registry>RFC3688</a>]. + +<span class="h3"><h3><a class="selflink" name="section-12.1" href="#section-12.1">12.1</a>. Namespace Registration</h3></span> + + Registration request for the CalDAV namespace: + + URI: urn:ietf:params:xml:ns:caldav + + Registrant Contact: See the "Authors' Addresses" section of this + document. + + XML: None. Namespace URIs do not represent an XML specification. + +<span class="h2"><h2><a class="selflink" name="section-13" href="#section-13">13</a>. Acknowledgements</h2></span> + + The authors would like to thank the following individuals for + contributing their ideas and support for writing this specification: + Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Andre + Courtemanche, Mike Douglass, Ted Hardie, Marten den Haring, Jeffrey + Harris, Sam Hartman, Helge Hess, Jeff McCullough, Alexey Melnikov, + Dan Mosedale, Brian Moseley, Francois Perrault, Kervin L. Pierre, + Julian F. Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari + Urpalainen, Simon Vaillancourt, and Jim Whitehead. + + + + +<span class="grey">Daboo, et al. Standards Track [Page 96]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-97" id="page-97" href="#page-97" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + The authors would also like to thank the Calendaring and Scheduling + Consortium for advice with this specification, and for organizing + interoperability testing events to help refine it. + +<span class="h2"><h2><a class="selflink" name="section-14" href="#section-14">14</a>. References</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-14.1" href="#section-14.1">14.1</a>. Normative References</h3></span> + + [<a name="ref-RFC2119" id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", <a href="http://tools.ietf.org/html/bcp14">BCP 14</a>, + <a href="http://tools.ietf.org/html/rfc2119">RFC 2119</a>, March 1997. + + [<a name="ref-RFC2246" id="ref-RFC2246">RFC2246</a>] Dierks, T. and C. Allen, "The TLS Protocol + Version 1.0", <a href="http://tools.ietf.org/html/rfc2246">RFC 2246</a>, January 1999. + + [<a name="ref-RFC2445" id="ref-RFC2445">RFC2445</a>] Dawson, F. and Stenerson, D., "Internet + Calendaring and Scheduling Core Object + Specification (iCalendar)", <a href="http://tools.ietf.org/html/rfc2445">RFC 2445</a>, + November 1998. + + [<a name="ref-RFC2446" id="ref-RFC2446">RFC2446</a>] Silverberg, S., Mansour, S., Dawson, F., and + R. Hopson, "iCalendar Transport-Independent + Interoperability Protocol (iTIP) Scheduling + Events, BusyTime, To-dos and Journal + Entries", <a href="http://tools.ietf.org/html/rfc2446">RFC 2446</a>, November 1998. + + [<a name="ref-RFC2518" id="ref-RFC2518">RFC2518</a>] Goland, Y., Whitehead, E., Faizi, A., Carter, + S., and D. Jensen, "HTTP Extensions for + Distributed Authoring -- WEBDAV", <a href="http://tools.ietf.org/html/rfc2518">RFC 2518</a>, + February 1999. + + [<a name="ref-RFC2616" id="ref-RFC2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, + H., Masinter, L., Leach, P., and T. Berners- + Lee, "Hypertext Transfer Protocol -- + HTTP/1.1", <a href="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, June 1999. + + [<a name="ref-RFC2818" id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="http://tools.ietf.org/html/rfc2818">RFC 2818</a>, + May 2000. + + [<a name="ref-RFC3253" id="ref-RFC3253">RFC3253</a>] Clemm, G., Amsden, J., Ellison, T., Kaler, + C., and J. Whitehead, "Versioning Extensions + to WebDAV (Web Distributed Authoring and + Versioning)", <a href="http://tools.ietf.org/html/rfc3253">RFC 3253</a>, March 2002. + + [<a name="ref-RFC3688" id="ref-RFC3688">RFC3688</a>] Mealling, M., "The IETF XML Registry", + <a href="http://tools.ietf.org/html/bcp81">BCP 81</a>, <a href="http://tools.ietf.org/html/rfc3688">RFC 3688</a>, January 2004. + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 97]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-98" id="page-98" href="#page-98" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + [<a name="ref-RFC3744" id="ref-RFC3744">RFC3744</a>] Clemm, G., Reschke, J., Sedlar, E., and J. + Whitehead, "Web Distributed Authoring and + Versioning (WebDAV) Access Control Protocol", + <a href="http://tools.ietf.org/html/rfc3744">RFC 3744</a>, May 2004. + + [<a name="ref-RFC4346" id="ref-RFC4346">RFC4346</a>] Dierks, T. and E. Rescorla, "The Transport + Layer Security (TLS) Protocol Version 1.1", + <a href="http://tools.ietf.org/html/rfc4346">RFC 4346</a>, April 2006. + + [<a name="ref-RFC4790" id="ref-RFC4790">RFC4790</a>] Newman, C., Duerst, M., and A. Gulbrandsen, + "Internet Application Protocol Collation + Registry", <a href="http://tools.ietf.org/html/rfc4790">RFC 4790</a>, March 2007. + + [<a name="ref-W3C.REC-xml-20060816" id="ref-W3C.REC-xml-20060816">W3C.REC-xml-20060816</a>] Paoli, J., Maler, E., Yergeau, F., Sperberg- + McQueen, C., and T. Bray, "Extensible Markup + Language (XML) 1.0 (Fourth Edition)", World + Wide Web Consortium Recommendation REC-xml- + 20060816, August 2006, + <<a href="http://www.w3.org/TR/2006/REC-xml-20060816">http://www.w3.org/TR/2006/REC-xml-20060816</a>>. + +<span class="h3"><h3><a class="selflink" name="section-14.2" href="#section-14.2">14.2</a>. Informative References</h3></span> + + [<a name="ref-RFC2426" id="ref-RFC2426">RFC2426</a>] Dawson, F. and T. Howes, "vCard MIME + Directory Profile", <a href="http://tools.ietf.org/html/rfc2426">RFC 2426</a>, September 1998. + + [<a name="ref-RFC2739" id="ref-RFC2739">RFC2739</a>] Small, T., Hennessy, D., and F. Dawson, + "Calendar Attributes for vCard and LDAP", + <a href="http://tools.ietf.org/html/rfc2739">RFC 2739</a>, January 2000. + + [<a name="ref-RFC4331" id="ref-RFC4331">RFC4331</a>] Korver, B. and L. Dusseault, "Quota and Size + Properties for Distributed Authoring and + Versioning (DAV) Collections", <a href="http://tools.ietf.org/html/rfc4331">RFC 4331</a>, + February 2006. + + [<a name="ref-RFC4511" id="ref-RFC4511">RFC4511</a>] Sermersheim, J., "Lightweight Directory + Access Protocol (LDAP): The Protocol", + <a href="http://tools.ietf.org/html/rfc4511">RFC 4511</a>, June 2006. + + [<a name="ref-rfc2518bis" id="ref-rfc2518bis">rfc2518bis</a>] Dusseault, L., "HTTP Extensions for + Distributed Authoring - WebDAV", Work + in Progress, December 2006. + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 98]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-99" id="page-99" href="#page-99" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +<span class="h2"><h2><a class="selflink" name="appendix-A" href="#appendix-A">Appendix A</a>. CalDAV Method Privilege Table (Normative)</h2></span> + + The following table extends the WebDAV Method Privilege Table + specified in <a href="http://tools.ietf.org/html/rfc3744#appendix-B">Appendix B of [RFC3744]</a>. + + +------------+------------------------------------------------------+ + | METHOD | PRIVILEGES | + +------------+------------------------------------------------------+ + | MKCALENDAR | DAV:bind | + | REPORT | DAV:read or CALDAV:read-free-busy (on all referenced | + | | resources) | + +------------+------------------------------------------------------+ + +<span class="h2"><h2><a class="selflink" name="appendix-B" href="#appendix-B">Appendix B</a>. Calendar Collections Used in the Examples</h2></span> + + This appendix shows the calendar object resources contained in the + calendar collection queried in the examples throughout this document. + + The content of the calendar collection is being shown as if it were + returned by a CALDAV:calendar-query REPORT request designed to return + all the calendar data in the collection: + + >> 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/> + </D:prop> + <C:filter> + <C:comp-filter name="VCALENDAR"/> + </C:filter> + </C:calendar-query> + + >> Response << + + HTTP/1.1 207 Multi-Status + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + + + +<span class="grey">Daboo, et al. Standards Track [Page 99]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-100" id="page-100" href="#page-100" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <?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/abcd1.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"fffff-abcd1"</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:20060206T001102Z + DTSTART;TZID=US/Eastern:20060102T100000 + DURATION:PT1H + SUMMARY:Event #1 + Description:Go Steelers! + UID:74855313FA803DA593CD579A@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/abcd2.ics</D:href> + <D:propstat> + + + +<span class="grey">Daboo, et al. Standards Track [Page 100]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-101" id="page-101" href="#page-101" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <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> + + + +<span class="grey">Daboo, et al. Standards Track [Page 101]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-102" id="page-102" href="#page-102" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <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 + 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/abcd4.ics</D:href> + <D:propstat> + <D:prop> + + + +<span class="grey">Daboo, et al. Standards Track [Page 102]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-103" id="page-103" href="#page-103" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + <D:getetag>"fffff-abcd4"</D:getetag> + <C:calendar-data>BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//Example Corp.//CalDAV Client//EN + BEGIN:VTODO + DTSTAMP:20060205T235335Z + DUE;VALUE=DATE:20060104 + STATUS:NEEDS-ACTION + SUMMARY:Task #1 + UID:DDDEEB7915FA61233B861457@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:response> + <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"fffff-abcd5"</D:getetag> + <C:calendar-data>BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//Example Corp.//CalDAV Client//EN + BEGIN:VTODO + DTSTAMP:20060205T235300Z + DUE;VALUE=DATE:20060106 + 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> + + + +<span class="grey">Daboo, et al. Standards Track [Page 103]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-104" id="page-104" href="#page-104" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + </D:response> + + <D:response> + <D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"fffff-abcd6"</D:getetag> + <C:calendar-data>BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//Example Corp.//CalDAV Client//EN + BEGIN:VTODO + COMPLETED:20051223T122322Z + DTSTAMP:20060205T235400Z + DUE;VALUE=DATE:20051225 + LAST-MODIFIED:20060205T235308Z + SEQUENCE:1 + STATUS:COMPLETED + SUMMARY:Task #3 + UID:E10BA47467C5C69BB74E8722@example.com + END:VTODO + 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/abcd7.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"fffff-abcd7"</D:getetag> + <C:calendar-data>BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//Example Corp.//CalDAV Client//EN + BEGIN:VTODO + DTSTAMP:20060205T235600Z + DUE;VALUE=DATE:20060101 + LAST-MODIFIED:20060205T235308Z + SEQUENCE:1 + STATUS:CANCELLED + SUMMARY:Task #4 + UID:E10BA47467C5C69BB74E8725@example.com + END:VTODO + END:VCALENDAR + </C:calendar-data> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + + + +<span class="grey">Daboo, et al. Standards Track [Page 104]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-105" id="page-105" href="#page-105" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + + </D:propstat> + </D:response> + + <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:20060101T000000Z + DTEND:20060108T000000Z + FREEBUSY:20050531T230000Z/20050601T010000Z + FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z + FREEBUSY:20060103T100000Z/20060103T120000Z + FREEBUSY:20060104T100000Z/20060104T120000Z + FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z + FREEBUSY:20060106T100000Z/20060106T120000Z + END:VFREEBUSY + END:VCALENDAR + </C:calendar-data> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + + </D:multistatus> + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 105]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-106" id="page-106" href="#page-106" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +Authors' Addresses + + Cyrus Daboo + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + EMail: cyrus@daboo.name + URI: <a href="http://www.apple.com/">http://www.apple.com/</a> + + + Bernard Desruisseaux + Oracle Corporation + 600 Blvd. de Maisonneuve West + Suite 1900 + Montreal, QC H3A 3J2 + CANADA + + EMail: bernard.desruisseaux@oracle.com + URI: <a href="http://www.oracle.com/">http://www.oracle.com/</a> + + + Lisa Dusseault + CommerceNet + 169 University Ave. + Palo Alto, CA 94301 + USA + + EMail: ldusseault@commerce.net + URI: <a href="http://commerce.net/">http://commerce.net/</a> + + + + + + + + + + + + + + + + + + + + +<span class="grey">Daboo, et al. Standards Track [Page 106]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-107" id="page-107" href="#page-107" class="invisible"> </a> +<span class="grey"><a href="#">RFC 4791</a> CalDAV March 2007</span> + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in <a href="http://tools.ietf.org/html/bcp78">BCP 78</a>, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in <a href="http://tools.ietf.org/html/bcp78">BCP 78</a> and <a href="http://tools.ietf.org/html/bcp79">BCP 79</a>. + + 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 + <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Daboo, et al. Standards Track [Page 107] + +</pre><br> +<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.111, available from +<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a> +</small></small></span> + +</body></html>
\ No newline at end of file |