Groupe de travail Réseau	C. Daboo, Apple
Demande for Comments : 4791	B. Desruisseaux, Oracle
Catégorie : Sur la voie de la normalisation	L. Dusseault, CommerceNet
Traduction Claude Brière de L'Isle	mars 2007

Extensions de calendrier à WebDAV (CalDAV)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The IETF Trust (2007).

Résumé
Le présent document définit des extensions au protocole de collecte ordonnée des auteurs et des versions distribuée sur la Toile (WebDAV, Web Distributed Authoring and Versioning) pour spécifier une façon standard d'accéder, gérer, et partager les informations de calendrier et de programmation fondées sur le format iCalendar. Le présent document définit la caractéristique "calendar-access" de CalDAV.
Table des matières
1. Introduction	2
1.1 Conventions de notation	2
1.2 Espaces de noms et traitement XML	2
1.3 Préconditions et postconditions de méthode	3
2. Vue d'ensemble des exigences	3
3. Modèle de données de calendrier	3
3.1 Serveur de calendrier	4
3.2 Récurrence et modèle de données	4
4. Ressources de calendrier 	4
4.1 Ressources d'objet de calendrier	4
4.2 Collection de calendrier	5
5. Caractéristiques d'accès au calendrier	6
5.1 Prise en charge de l'accès au calendrier	6
5.2 Propriétés des collections de calendriers	6
5.3 Création de ressources	11
6. Contrôle d'accès au calendrier	16
6.1 Privilège de calendrier	16
6.2 Propriété principale supplémentaire	16
7. Rapports de calendrier	17
7.1 Méthode REPORT	17
7.2 Collections ordinaires	17
7.3 Date et heure flottante	17
7.4. Filtrage de gamme de temps	18
7.5 Recherche de collations de Text:	18
7.6 Restitution partielle	19
7.7 Composants, propriétés, et paramètres non standard	19
7.8. Rapport CALDAV:calendar-query	20
7.9 Rapport CALDAV:calendar-multiget	38
7.10 Rapport CALDAV:free-busy-query	40
8. Lignes directrices	42
8.1 Interopérability de client à client	42
8.2 Opérations de synchronisation	42
8.3 Utilisation de verrouillage	44
8.4 Trouver les calendriers	44
8.5 Mémorisation et utilisation de pièces jointes	45
8.6 Mémorisation et utilisation des alarmes	46
9. Définitions d'éléments XML	47
9.1 Élément XML CALDAV:calendar	47
9.2 Élément XML CALDAV:mkcalendar	47
9.3 Élément XML CALDAV:mkcalendar-response	47
9.4 Élément XML CALDAV:pris en charge-collation	47
9.5 Élément XML CALDAV:calendar-query	47
9.6 Élément XML CALDAV:calendar-data	48
9.7 Élément XML CALDAV:filter	51
9.8 Élément XML CALDAV:timezone	53
9.9 Élément XML CALDAV:time-range	53
9.10 Élément XML CALDAV:calendar-multiget	56
9.11 Élément XML CALDAV:free-busy-query	56
10. Considérations d'internationalisation	56
11. Considérations sur la sécurité	56
12. Considerations relatives à l'IANA	57
12.1 Enregistrement d'espace de noms	57
13. Remerciements	57
14. Références	58
14.1 Références normatives	58
14.2 Références pour information	58
Appendice A. Tableau de privilège de méthode CalDAV (normatif)	58
Appendice B. Collections Calendar tilisées dans les exemples	59
Adresse des auteurs	64
Déclaration complète de droits de reproduction	64

 	1.	Introduction

Le concept d'utiliser HTTP [RFC2616] et WebDAV [RFC2518] comme base d'un protocole d'accès au calendrier n'est absolument pas nouveau : il a été discuté dans le groupe de travail CALSCH de l'IETF dès 1997 ou 1998. Plusieurs compagnies ont mis en œuvre des protocoles d'accès au calendrier utilisant HTTP pour télécharger des objets iCalendar [RFC2445], et ont utilisé WebDAV pour obtenir des listes de ressources. Cependant, ces mises en œuvre n'interopèrent pas parce que il y a beaucoup de petites et grandes décisions à prendre sur la façon de modéliser les données de calendrier comme ressources WebDAV, ainsi que sur la façon de mettre en œuvre les caractéristiques requises qui ne font pas encore partie de WebDAV. Le présent document propose une façon de modeliser les données de calendrier dans WebDAV, avec des caractéristiques supplémentaires pour constituer un protocole interopérable d'accès à un calendrier.

 	1.1	Conventions de notation
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Le terme "protégé" est utilisé dans le champ Conformité des définitions de propriétés, comme défini au paragraphe 1.4.2 de la [RFC3253].

Quand les types d'élément XML dans les espaces de noms "DAV:" et "urn:ietf:params:xml:ns:caldav" sont référencés dans ce document en dehors du contexte d'un fragment XML, les chaînes "DAV:" et "CALDAV:" vont être munies du préfixe des noms de type d'élément respectifs.

 	1.2	Espaces de noms et traitement XML
Les définitions des éléments XML dans ce document utilisent des déclarations de type d'élément XML (comme on les trouve dans les déclarations de type de document XML) décrites au paragraphe 3.2 de [XML-2006].

L'espace de noms "urn:ietf:params:xml:ns:caldav" est réservé pour les éléments XML définis dans la présente spécification, ses révisions, et les spécifications CalDAV qui s'y rapportent. Les éléments XML définis par des mises en œuvre individuelles NE DOIVENT PAS utiliser l'espace de noms "urn:ietf:params:xml:ns:caldav", et devraient plutôt utiliser un espace de noms qu'elles contrôlent.

Les déclarations XML utilisées dans le présent document n'incluent pas d'informations d'espace de noms. Donc, les mises en œuvre ne doivent pas utiliser ces déclarations comme le seul moyen de créer des propriétés CalDAV valides ou pour valider des types d'élément XML CalDAV. Certaines des déclarations se réfèrent à des éléments XML définis par WebDAV [RFC2518], qui utilisent l'espace de noms "DAV:". Chaque fois que de tels éléments XML apparaissent, ils sont explicitement préfixés avec "DAV:" pour éviter toute confusion.

On notera aussi que certains noms d'élément XML de CalDAV sont identiques aux noms d'élément XML de WebDAV, bien que leurs espaces de noms diffèrent. Il faut faire attention à ne pas confondre les deux ensembles de noms.

Le traitement de XML par les clients et serveurs CalDAV DOIT suivre les règles décrites dans la [RFC2518] ; en particulier, de la Section 14, et de l'Appendice 3 de cette spécification.

 	1.3	Préconditions et postconditions de méthode
Une "précondition" d'une méthode décrit l'état du serveur qui doit être vrai pour que cette méthode soit effectuée. Une "postcondition" d'une méthode décrit l'état du serveur qui doit être vrai après que cette méthode a été achevée. Si une précondition ou postcondition de méthode pour une demande n'est pas satisfaite, l'état de réponse de la demande DOIT être 403 (Interdit) si la demande ne devrait pas être répétée parce qu'elle va toujours échouer, ou 409 (Conflit) si il est prévu que l'utilisateur pourrait être capable de résoudre le conflit et resoumettre la demande.

Afin de permettre un meilleur traitement par le client des réponses 403 et 409, un type distinct d'élément XML est associé à chaque précondition et postcondition de méthode d'une demande. Quand une précondition particulière n'est pas satisfaite ou qu'une postcondition particulière ne peut pas être réalisée, l'élément XML approprié DOIT être retourné comme fils d'un élément DAV:error de niveau supérieur dans le corps de réponse, sauf si il en a été négocié autrement par la demande.

 	2.	Vue d'ensemble des exigences

Cette section fait la liste des fonctionnalités requises d'un serveur CalDAV. Pour annoncer la prise en charge de CalDAV, un serveur :
o	DOIT prendre en charge iCalendar [RFC2445] comme type de support pour le format de ressource d'objet calendar ;
o	DOIT prendre en charge WebDAV classe 1 [RFC2518] (noter que la [RFC4918] décrit des éclaircissements à la [RFC2518] qui aident à l'interopérabilité) ;
o	DOIT prendre en charge WebDAV ACL [RFC3744] avec le privilège supplémentaire défini au paragraphe 6.1 du présent document ;
o	DOIT prendre en charge le transport sur TLS [RFC2246] comme défini dans la [RFC2818] (noter que la [RFC2246] a été rendue obsolète par la [RFC4346]) ;
o	DOIT prendre en charge les ETag [RFC2616] avec les exigences additionnelles spécifiées au paragraphe 5.3.4 de ce document ;
o	DOIT prendre en charge tous les rapports de calendrier définis à la Section 7 de ce document ; et
o	DOIT annoncer la prise en charge sur toutes les collections de calendriers et les ressources d'objet calendar pour les rapports de calendrier dans la propriété DAV:supported-report-set, comme défini dans les extensions de versions à WebDAV [RFC3253].

De plus, un serveur :
o	DEVRAIT prendre en charge la méthode MKCALENDAR définie au paragraphe 5.3.1 de ce document.

 	3.	Modèle de données de calendrier

Une des caractéristiques qui ont fait le succès de WebDAV est son modèle de données solide. Cela en fait un cadre utile pour d'autres applications comme celles de calendrier. La présente spécification suit le même schéma en développant toutes les caractéristiques sur la base d'un modèle de données bien décrit.

Pour un bref survol, un calendrier CalDAV est modélisé comme une collection WebDAV avec une structure définie ; chaque collection de calendriers contient un certain nombre de ressources représentant des objets de calendrier comme ressources filles directes. Chaque ressource représentant un objet de calendrier (événement, à faire, entrée de journal, ou autres composants de calendrier) est appelé une "ressource d'objet de calendrier". Chaque ressource d'objet de calendrier et chaque collection de calendriers peut être individuellement verrouillée et avoir des propriétés WebDAV individuelles. Les exigences déduites de ce modèle sont décrites aux paragraphes 4.1 et 4.2.

 	3.1	Serveur de calendrier
Un serveur CalDAV est un moteur à capacité de calendrier combiné avec un répertoire WebDAV. Un répertoire WebDAV est un ensemble de collections WebDAV, contenant d'autres ressources WebDAV, au sein d'un espace de nom unifié d'URL. Par exemple, le répertoire "http://www.exemple.com/webdav/" peut contenir des collections et resources WebDAV, qui ont toutes des URL commençant par "http://www.exemple.com/webdav/". Noter que l'URL racine, "http://www.exemple.com/", ne peut pas lui-même être un répertoire WebDAV (par exemple, si la prise en charge de WebDAV est mise en œuvre à travers un servlet ou autre extension de serveur de la Toile).

Un répertoire WebDAV PEUT inclure des données de calendrier dans certaines parties de son espace de noms d'URL, et des données non de calendrier dans d'autres parties.

Un répertoire WebDAV peut s'annoncer comme serveur CalDAV si il prend en charge la fonction définie dans la présente spécification en tout point au sein de la racine du répertoire. Cela pourrait signifier que les données de calendrier sont étalées dans tout les répertoires et mélangées avec des données non de calendrier dans les collections du voisinage (par exemple, les données de calendrier peuvent se trouver dans /home/lisa/calendars/ aussi bien que dans /home/bernard/calendars/, et des données non de calendrier dans /home/lisa/contacts/). Ou, cela pourrait signifier que les données de calendrier ne peuvent se trouver que dans certaines sections du répertoire (par exemple, /calendar/). Les caractéristiques de calendrier ne sont exigées que dans les sections de répertoire qui sont ou qui contiennent des ressources d'objet de calendrier. Donc, un répertoire qui confine les données de calendrier dans la collection /calendar/ va seulement avoir besoin de prendre en charge les caractéristiques exigées de CalDAV au sein de cette collection.

Le serveur ou répertoire CalDAV est la localisation canonique pour les données de calendrier et les informations d'état. Les clients peuvent soumettre des demandes pour changer ou télécharger des données. Les clients peuvent mémoriser hors ligne les objets de calendrier et tenter de se synchroniser ultérieurement. Cependant, les clients DOIVENT être prêts à ce que les données de calendrier sur le serveur changent entre le moment de la dernière synchronisation et celui où ils tentent une mise à jour, car les collections de calendriers peuvent être partagées et accessibles via plusieurs clients. Les étiquettes d'entité et autres caractéristiques rendent cela possible.

 	3.2	Récurrence et modèle de données
La récurrence est une partie importante du modèle de données parce qu'elle gouverne la quantité de ressources dont on attend l'existence. La présente spécification modélise un composant récurrent de calendrier et ses exceptions de récurrence comme une seule ressource. Dans ce modèle, les règles de récurrence, les dates de récurrence, les règles d'exception, et les dates d'exception font toutes partie des données dans une seule ressource d'objet de calendrier. Ce modèle évite les problèmes de limitation du nombre d'instances de récurrence à mémoriser dans le répertoire, de la façon de conserver les instances de récurrence en synchronisation avec le composant récurrent de calendrier, et de comment lier les exceptions de récurrence avec le composant récurrent de calendrier. Il résulte aussi en moins de données de synchronisation entre client et serveur, et rend plus faciles les changements à toutes les instances de récurrence ou à une règle de récurrence. Il rend plus facile de créer un composant de calendrier récurrent que de supprimer toutes les instances de récurrence.

Les clients ne sont pas forcés de restituer les informations sur toutes les instances de récurrence d'un composant récurrent. Les rapports CALDAV:calendar-query et CALDAV:calendar-multiget définis dans le présent document permettent aux clients de restituer les seules instances de récurrence qui se chevauchent sur une gamme de temps donnée.

 	4.	Ressources de calendrier 
 	4.1	Ressources d'objet de calendrier
Les ressources d'objet Calendrier contenues dans les collections de calendriers NE DOIVENT PAS contenir plus d'un type de composant de calendrier (par exemple, VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) à l'exception des composants VTIMEZONE, qui DOIVENT être spécifiés pour chaque valeur de paramètre TZID unique spécifiée dans l'objet iCalendar. Par exemple, une ressource d'objet de calendrier peut contenir un composant VEVENT et un composant VTIMEZONE, mais il ne peut pas contenir un composant VEVENT et un composant VTODO. Les composants VEVENT et VTODO devraient plutôt être mémorisés dans des ressources d'objet Calendrier séparées dans la même collection.

Les ressources d'objet Calendrier contenues dans des collections de calendriers NE DOIVENT PAS spécifier la propriété iCalendar METHOD.

La valeur de propriété UID des composants de calendrier contenus dans une ressource d'objet de calendrier DOIT être unique dans le domaine d'application de la collection de calendriers dans laquelle ils sont mémorisés.

Les composants de calendrier dans une collection de calendriers qui ont des valeurs de propriété UID différentes DOIVENT être mémorisés dans des ressources d'objet Calendrier séparées.

Les composants de calendrier avec la même valeur de propriété UID, dans une certaine collection de calendriers, DOIVENT être contenus dans la même ressource d'objet de calendrier. Cela assure que tous les composants dans un ensemble récurrent sont contenus dans la même ressource d'objet de calendrier. Il est possible pour une ressource d'objet de calendrier de contenir juste les composants qui représentent des instances "outrepassantes" (qui modifient le comportement d'une instance régulière, et donc incluent une propriété RECURRENCE-ID) sans inclure aussi le composant "maître" récurrent (celui qui définit "l'ensemble" de récurrence et ne contient aucune propriété RECURRENCE-ID).

Par exemple, étant donné l'objet iCalendar suivant :

DÉBUT :VCALENDAR
PRODID:-//Exemple Corp.//CalDAV Client//FR
VERSION:2.0
DÉBUT :VEVENT
UID:1@exemple.com
SOMMAIRE : Réunion supprimée
DTSTAMP:20041210T183904Z
DTSTART:20041207T120000Z
DTEND:20041207T130000Z
FIN :VEVENT
DÉBUT :VEVENT
UID:2@exemple.com
SOMMAIRE :Réunion hebdomadaire
DTSTAMP:20041210T183838Z
DTSTART:20041206T120000Z
DTEND:20041206T130000Z
RRULE:FREQ=HEBDOMADAIRE
FIN :VEVENT
DÉBUT :VEVENT
UID:2@exemple.com
SOMMAIRE :Réunion hebdomadaire
RECURRENCE-ID:20041213T120000Z
DTSTAMP:20041210T183838Z
DTSTART:20041213T130000Z
DTEND:20041213T140000Z
FIN :VEVENT
FIN :VCALENDAR

Le composant VEVENT avec la valeur d'UID "1@exemple.com" va être mémorisé dans sa propre ressource d'objet de calendrier. Les deux composants VEVENT avec la valeur d'UID "2@exemple.com", qui représentent un événement récurrent où l'instance de récurrence a été outrepassée, vont être mémorisés dans la même ressource d'objet de calendrier.

 	4.2	Collection de calendrier
Une collection de calendriers contient les ressources d'objet Calendrier qui représentent les composants de calendrier au sein d'un calendrier. Une collection de calendriers est manifestée aux clients comme une collection de ressources WebDAV identifiée par un URL. Une collection de calendriers DOIT rapporter la collection DAV: et les éléments XML CALDAV:calendar dans la valeur de la propriété DAV: resourcetype. La déclaration de type d'élément pour CALDAV:calendar est :

<!ELEMENT calendar EMPTY>

Une collection de calendriers peut être créée par provisionnement (c'est-à-dire, créée automatiquement quand le compte d'un utilisateur est provisionné) ou elle peut être créée avec la méthode MKCALENDAR (voir au paragraphe 5.3.1). Cette méthode peut être utile pour qu'un utilisateur crée des calendriers supplémentaires (par exemple, le programme des matchs de foot) ou pour que les utilisateurs partagent un calendrier (par exemple, les réunions d'équipe ou les salles de conférence). Cependant, on notera que le présent document ne définit pas l'objet des collections de calendriers supplémentaires. Les utilisateurs doivent s'appuyer sur des indices non standard pour découvrir à quoi sert une collection de calendriers, ou utiliser la propriété CALDAV:calendar-description définie au paragraphe 5.2.1 pour avoir un tel indice.

Le restrictions suivantes s'appliquent aux resources au sein d'une collection de calendriers:

a. 	Les collections de calendriers DOIVENT seulement contenir les ressources d'objet Calendrier et les collections qui ne sont pas des collections de calendriers, c'est-à-dire, les seules ressources de non collection de "niveau supérieur" permises dans une collection de calendriers sont les ressources d'objet Calendrier. Cela assure que les clients de calendrier n'ont pas à traiter avec des données de non calendrier dans une collection de calendriers, bien qu'ils aient à distinguer entre les ressources d'objet Calendrier et les collections quand ils utilisent les techniques WebDAV standard pour examiner le contenu d'une collection.

b.	Le contenu des collections dans les collections de calendriers NE DOIT PAS contenir des collections de calendriers à n'importe quelle profondeur, c'est-à-dire, "incorporer" à quelque profondeur que ce soit des collections de calendriers au sein d'autres collections de calendriers n'est pas permis. La présente spécification ne définit pas comment les collections contenues dans une collection de calendriers sont utilisées ou comment elles se rapportent aux ressources d'objet Calendrier contenues dans la collection de calendriers.

Plusieurs collections de calendriers PEUVENT être filles de la même collection.

 	5.	Caractéristiques d'accès au calendrier
 	5.1	Prise en charge de l'accès au calendrier
Un serveur qui prend en charge les caractéristiques décrites dans ce document DOIT inclure "calendar-access" comme champ dans l'en-tête de réponse DAV d'une demande OPTIONS sur toute ressource qui prend en charge des propriétés, rapports, méthodes, ou privilèges de calendrier. Une valeur de "calendar-access" dans l'en-tête de réponse DAV DOIT indiquer que le serveur prend en charge toutes les exigences de niveau DOIT spécifiées dans le présent document.

 	5.1.1	Exemple : Utilisation d'OPTIONS pour la découverte de la prise en charge de l'accès au calendrier
>> Demande <<

OPTIONS /home/bernard/calendars/ HTTP/1.1
Host: cal.exemple.com

>> Réponse <<

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: Sam, 11 Nov 2006 09:32:12 GMT
Content-Length: 0

Dans cet exemple, la méthode OPTIONS retourne la valeur "calendar-access" dans l'en-tête de réponse DAV pour indiquer que la collection "/home/bernard/calendars/" supporte les propriétés, rapports, méthodes, ou privilèges définies dans la présente spécification.

 	5.2	Propriétés des collections de calendriers
Cette section définit les propriétés des collections de calendriers.

 	5.2.1	Propriété CALDAV:calendar-description
Nom : calendar-description
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Donne une description lisible par l'homme de la collection de calendriers.
Conformité : Cette propriété PEUT être définie sur toutes les collections de calendriers. Si elle est définie, elle PEUT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]). Un attribut xml:lang indique que le langage de la description DEVRAIT être établi pour cette propriété par les clients ou par le provisionnement du serveur. Les serveurs DOIVENT retourner tout attribut xml:lang si il est établi pour la propriété.

Description : Si elle est présente, la propriété contient une description de la collection de calendriers qui convient pour la présentation à un utilisateur. Si elle n'est pas présente, le client devrait supposer qu'il n'y a aucune description pour la collection de calendriers.

Définition : <!ELEMENT calendar-description (#PCDATA)> 
Valeur de PCDATA : chaîne

Exemple :
<C:calendar-description xml:lang="fr-CA"
xmlns:C="urn:ietf:params:xml:ns:caldav"
>Calendrier de Mathilde Desruisseaux</C:calendar-description>

 	5.2.2	Propriété CALDAV:calendar-timezone
Nom : calendar-timezone
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie une zone horaire sur une collection de calendriers.
Conformité : Cette propriété DEVRAIT être définie sur toutes les collections de calendriers. Si elle est définie, elle NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe 12.14.1 de la [RFC2518]).

Description : La propriété CALDAV:calendar-timezone est utilisée pour spécifier la zone horaire sur laquelle le serveur devrait compter pour résoudre les valeurs de "date" et "date avec heure locale" (c'est-à-dire, heure flottante) à des valeurs de "date avec temps UTC". Le serveur va exiger ces informations pour déterminer si un composant de calendrier programmé avec des valeurs de "date" ou des valeurs de "date avec heure locale" se chevauchent avec la CALDAV: time-range spécifiée dans un rapport CALDAV:calendar-query. Le serveur va aussi exiger ces informations pour calculer la période de temps FREEBUSY appropriée comme "date avec temps UTC" dans le composant VFREEBUSY retourné dans une réponse à une demande de rapport CALDAV:free-busy-query qui tient compte des composants de calendrier programmés avec des valeurs "date" ou "date avec heure locale". En l'absence de cette propriété, le serveur PEUT s'appuyer sur la zone horaire de son choix.

Note : les données iCalendar incorporées dans l'élément XML CALDAV:calendar-timezone DOIVENT suivre les règles standard de données de caractères XML, incluant l'utilisation du codage d'entité &lt;, &gt;, &amp; etc. ou l'utilisation d'une construction <![CDATA[ ... ]]>. Dans ce cas, les données de iCalendar ne peuvent pas contenir la séquence de caractères "]]>", qui est le délimiteur de fin de la section CDATA.

Définition :
<!ELEMENT calendar-timezone (#PCDATA)>
Valeur de PCDATA : un objet iCalendar avec exactement un composant VTIMEZONE.

Exemple :
<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>

 	5.2.3	Propriété CALDAV:supported-calendar-component-set
Nom : supported-calendar-component-set (ensemble de composants de calendrier pris en charge)
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie les types de composants de calendrier (par exemple, VEVENT, VTODO, etc.) que les ressources d'objet Calendrier peuvent contenir dans la collection de calendriers.
Conformité : Cette propriété PEUT être définie sur toute collection de calendriers. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]).

Description : La propriété CALDAV:supported-calendar-component-set est utilisée pour spécifier des restrictions sur les types de composant de calendrier que les ressources d'objet Calendrier peuvent contenir dans une collection de calendriers. Toute tentative du client de mémoriser les ressources d'objet Calendrier avec des types de composants ne figurant pas sur la liste de cette propriété, si elle existe, DOIT résulter en une erreur, avec la mention que la précondition CALDAV:supported-calendar-component (paragraphe 5.3.2.1) a été violée. Comme cette propriété est protégée, elle ne peut pas être changée par les clients en utilisant une demande PROPPATCH. Cependant, les clients peuvent initialiser la valeur de cette propriété quand ils créent une nouvelle collection de calendriers avec MKCALENDAR. L'étiquette d'élément vide <C:comp name="VTIMEZONE"/> DOIT seulement être spécifiée si la prise en charge des ressources d'objet Calendrier qui contiennent seulement des composants VTIMEZONE est fournie ou désirée. La prise en charge des composants VTIMEZONE dans les ressources d'objet Calendrier qui contiennent des composants VEVENT ou VTODO est toujours supposée. En l'absence de cette propriété, le serveur DOIT accepter tous les types de composants, et le client peut supposer que tous les types de composants sont acceptés.

Définition : <!ELEMENT supported-calendar-component-set (comp+)>

Exemple :
<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>

 	5.2.4	Propriété CALDAV;supported-calendar-data
Nom : supported-calendar-data (données de calendrier prises en charge)
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie quels types de prise en charge sont permis pour les ressources d'objet Calendrier dans une collection de calendriers.
Conformité : Cette propriété PEUT être définie sur toute collection de calendriers. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]).

Description : La propriété CALDAV;supported-calendar-data est utilisée pour spécifier le type de support pris en charge pour les ressources d'objet Calendrier contenues dans une certaine collection de calendriers (par exemple, iCalendar version 2.0). Toute tentative du client de mémoriser les ressources d'objet Calendrier avec un type de support ne figurant pas sur la liste dans cette propriété DOIT résulter en une erreur, avec la mention que la précondition CALDAV;supported-calendar-data (paragraphe 5.3.2.1) a été violée. En l'absence de cette propriété, le serveur DOIT seulement accepter les données du type de support "text/calendar" et iCalendar version 2.0, et les clients peuvent supposer que le serveur va accepter seulement ces données.

Définition : <!ELEMENT supported-calendar-data (calendar-data+)>

Exemple :
<C:supported-calendar-data
    xmlns:C="urn:ietf:params:xml:ns:caldav">
   <C:calendar-data content-type="text/calendar" version="2.0"/>
</C:pris en charge-calendar-data>

 	5.2.5	Propriété CALDAV:max-resource-size
Nom : max-resource-size
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Donne une valeur numérique qui indique la taille maximum d'une ressource en octets que le serveur veut accepter quand une ressource d'objet de calendrier est mémorisée dans une collection de calendriers.
Conformité : Cette propriété PEUT être définie sur toute collection de calendriers. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]).

Description : La propriété CALDAV:max-resource-size est utilisée pour spécifier une valeur numérique qui représente la taille maximum en octets que le serveur veut accepter quand une ressource d'objet de calendrier est mémorisée dans une collection de calendriers. Toute tentative de mémoriser une ressource d'objet de calendrier excédant cette taille DOIT résulter en une erreur, avec la mention que la précondition CALDAV:max-resource-size (paragraphe 5.3.2.1) a été violée. En l'absence de cette propriété, le client peut supposer que le serveur va permettre la mémorisation d'une ressource de toute taille raisonnable.

Définition :
<!ELEMENT max-resource-size (#PCDATA)>
Valeur de PCDATA : valeur numérique (entier positif)

Exemple :
<C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"
>102400</C:max-resource-size>

 	5.2.6	Propriété CALDAV:min-date-time
Nom : min-date-time
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Fournit une valeur de DATE-HEURE qui indique la date et heure au plus tôt (en UTC) que le serveur veut accepter pour toute valeur de DATE ou DATE-HEURE dans une ressource d'objet de calendrier mémorisée dans une collection de calendriers.
Conformité : Cette propriété PEUT être définie sur toute collection de calendriers. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]).

Description : La propriété CALDAV:min-date-time est utilisée pour spécifier une valeur de DATE-TIME iCalendar en UTC qui indique la date inclusive au plus tôt que le serveur veut accepter pour toute valeur explicite de DATE ou DATE-TIME dans une ressource d'objet de calendrier mémorisée dans une collection de calendriers. Toute tentative de mémoriser une ressource d'objet de calendrier utilisant une valeur de DATE ou DATE-TIME antérieure à cette valeur DOIT résulter en une erreur, avec mention que la précondition CALDAV:min-date-time (paragraphe 5.3.2.1) a été violée. Noter que les serveurs DOIVENT accepter les composants récurrents qui spécifient des instances au delà de cette limite, pourvu qu'aucune de ces instances n'ait été outrepassée. Dans ce cas, le serveur PEUT simplement ignorer ces instances en dehors de la gamme acceptable quand il traite les rapports sur la ressource d'objet de calendrier. En l'absence de cette propriété, le client peut supposer que toute date valide de iCalendar peut être utilisée au moins jusqu'à la valeur de CALDAV:max-date-time, si celle-ci est définie.

Définition :
<!ELEMENT min-date-time (#PCDATA)>
Valeur de PCDATA : une valeur DATE-TIME en UTC en format iCalendar

Exemple :
<C:min-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
>19000101T000000Z</C:min-date-time>

 	5.2.7	Propriété CALDAV:max-date-time
Nom : max-date-time
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Donne une valeur de DATE-TIME qui indique la date et heure (en UTC) au plus tard que le serveur veut accepter pour toute valeur de DATE ou DATE-TIME dans une ressource d'objet de calendrier mémorisée dans une collection de calendriers.
Conformité : Cette propriété PEUT être définie sur toute collection de calendriers. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]).

Description : La propriété CALDAV:max-date-time est utilisée pour spécifier une valeur iCalendar DATE-TIME en UTC qui indique la date incluse au plus tard que le serveur veut accepter pour toute valeur de date ou heure dans une ressource d'objet de calendrier mémorisée dans une collection de calendriers. Toute tentative de mémoriser une ressource d'objet de calendrier en utilisant une valeur de DATE ou DATE-TIME plus tard que cette valeur DOIT résulter en une erreur, avec la mention que la précondition CALDAV:max-date-time (paragraphe 5.3.2.1) a été violée. Noter que les serveurs DOIVENT accepter les composants récurrents qui spécifient des instances au delà de cette limite, pourvu qu'aucune de ces instances n'ait été outrepassée. Dans ce cas, le serveur PEUT simplement ignorer ces instances en dehors de la gamme acceptable quand il traite les rapports sur la ressource d'objet de calendrier. En l'absence de cette propriété, le client peut supposer que toute date iCalendar valide peut être utilisée au moins jusqu'à la valeur CALDAV:min-date-time, si elle est définie.

Définition :
<!ELEMENT max-date-time (#PCDATA)>
Valeur PCDATA : une valeur DATE-TIME en UTC en format iCalendar

Exemple :
<C:max-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
>20491231T235959Z</C:max-date-time>

 	5.2.8	Propriété CALDAV:max-instances
Nom : max-instances
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Donne une valeur numérique indiquant le nombre maximum d'instances récurrentes qu'une ressource d'objet de calendrier mémorisée dans une collection de calendriers peut générer.
Conformité : Cette propriété PEUT être définie sur toute collection de calendriers. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]).

Description : La propriété CALDAV:max-instances est utilisée pour spécifier une valeur numérique qui indique le nombre maximum d'instances récurrentes qu'une ressource d'objet de calendrier mémorisée dans une collection de calendriers peut générer. Toute tentative de mémoriser une ressource d'objet de calendrier avec un schéma de récurrence qui génère plus d'instances que cette valeur DOIT résulter en une erreur, avec la mention que la précondition CALDAV:max-instances (paragraphe 5.3.2.1) a été violée. En l'absence de cette propriété, le client peut supposer que le serveur n'a pas de limite sur le nombre d'instances de récurrence qu'il peut traiter ou développer.

Définition :
<!ELEMENT max-instances (#PCDATA)>
Valeur de PCDATA : une valeur numérique (entier supérieur à zéro)

Exemple :
<C:max-instances xmlns:C="urn:ietf:params:xml:ns:caldav"
>100</C:max-instances>

 	5.2.9	Propriété CALDAV:max-attendees-per-instance
Nom : max-attendees-per-instance (nombre maximum de participants par instance)
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Donne une valeur numérique indiquant le nombre maximum de propriétés ATTENDEE dans toute instance d'une ressource d'objet de calendrier mémorisé dans une collection de calendriers.
Conformité : Cette propriété PEUT être définie sur toute collection de calendriers. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  12.14.1 de la [RFC2518]).

Description : La propriété CALDAV:max-attendees-per-instance est utilisée pour spécifier une valeur numérique qui indique le nombre maximum de propriétés iCalendar ATTENDEE sur chaque instance d'une ressource d'objet de calendrier mémorisée dans une collection de calendriers. Toute tentative de mémoriser une ressource d'objet de calendrier avec plus de propriétés ATTENDEE par instance que cette valeur DOIT résulter en une erreur, avec la mention que la précondition CALDAV:max-attendees-per-instance (paragraphe 5.3.2.1) a été violée. En l'absence de cette propriété, le client peut supposer que le serveur peut traiter tout nombre de propriétés ATTENDEE dans un composant de calendrier.

Définition :
<!ELEMENT max-attendees-per-instance (#PCDATA)>
Valeur de PCDATA : une valeur numérique (entier supérieur à zéro)

Exemple :
<C:max-attendees-per-instance xmlns:C="urn:ietf:params:xml:ns:caldav"
 >25</C:max-attendees-per-instance>

 	5.2.10	Précondition supplémentaire pour PROPPATCH
La présente spécification exige une précondition supplémentaire pour la méthode PROPPATCH. La précondition est :

(CALDAV:valid-calendar-data) : la zone horaire spécifiée dans la propriété CALDAV:calendar-timezone DOIT être un objet iCalendar valide contenant un seul composant VTIMEZONE valide.

 	5.3	Création de ressources
Les collections de calendriers et les ressources d'objet Calendrier peuvent être créées par un client CalDAV ou par le serveur CalDAV. La présente spécification définit des restrictions et un modèle de données auquels les clients et les serveurs DOIVENT adhérer quand ils manipulent de telles données de calendrier.

 	5.3.1	Méthode MKCALENDAR
Une demande HTTP crée une nouvelle ressource de collection de calendriers en utilisant la méthode MKCALENDAR. Un serveur PEUT restreindre la création de collection de calendriers à des collections particulières.

La prise en charge de MKCALENDAR sur le serveur est seulement RECOMMANDÉE et non EXIGEÉ parce que certaines mémorisations de calendrier ne prennent en charge qu'un calendrier par utilisateur (ou principal) ceux-ci sont normalement pré créés pour chaque compte. Cependant, les serveurs et clients sont vivement encouragés à prendre en charge MKCALENDAR chaque fois que possible pour permettre aux utilisateurs de créer plusieurs collections de calendriers pour aider à mieux organiser leurs données.

Les clients DEVRAIENT utiliser la propriété DAV:displayname (nom d'affichage) pour un nom du calendrier lisible par l'homme. Les clients peuvent spécifier la valeur de la propriété DAV:displayname dans le corps de demande de la demande MKCALENDAR, ou autrement produire une demande PROPPATCH pour changer la propriété DAV:displayname en la valeur appropriée immédiatement après la production de la demande MKCALENDAR. Les clients NE DEVRAIENT PAS régler la propriété DAV:displayname à être la même que les autres collection de calendriers au même "niveau" d'URI. Lors de l'affichage de collections de calendriers aux utilisateurs, les clients DEVRAIENT vérifier la propriété DAV:displayname et utiliser cette valeur comme nom du calendrier. Dans le cas où la propriété DAV:displayname serait vide, le client PEUT utiliser la dernière partie de l'URI de collection de calendriers comme nom ; cependant, ce segment de chemin peut être "opaque" et ne représenter aucun texte signifiant pour un humain.

Si une demande MKCALENDAR échoue, l'état de serveur précédant la demande DOIT être restauré.

Note d'ordre : Si un corps de demande est inclus, il DOIT être un élément XML CALDAV:mkcalendar. Le traitement des instructions DOIT se faire dans l'ordre de réception des instructions (c'est-à-dire, de haut en bas). Les instructions DOIVENT être exécutées, soit toutes, soit aucune. Donc, si une erreur survient durant le traitement, toutes les instructions exécutées DOIVENT être défaites et un résultat d'erreur approprié retourné. Les détails de traitement des instructions se trouvent dans la définition de l'instruction DAV:set au paragraphe 12.13.2 de la [RFC2518].

<!ELEMENT mkcalendar (DAV:set)>

Si un corps de réponse est inclus pour une demande réussie, il DOIT être un élément XML CALDAV:mkcalendar-response.

<!ELEMENT mkcalendar-response ANY>

La réponse DOIT inclure un en-tête Cache-Control:no-cache.

Préconditions : 
(DAV:resource-must-be-null) : une ressource NE DOIT PAS exister à l'URI de demande ;
(CALDAV:calendar-collection-location-ok) : l'URI de demande DOIT identifier un lieu où une collection de calendriers peut être créée ;
(CALDAV:valid-calendar-data) : la zone horaire spécifiée dans la propriété CALDAV:calendar-timezone DOIT être un objet iCalendar valide contenant un seul composant VTIMEZONE valide ;
(DAV:needs-privilege) : le privilège DAV:bind DOIT être accordé à l'utilisateur actuel sur la collection parente de l'URI de demande.

Postconditions :
(CALDAV:initialize-calendar-collection) : il existe une nouvelle collection de calendriers à l'URI de demande. Le DAV:resourcetype de la collection de calendriers DOIT contenir les deux éléments XML DAV:collection et CALDAV:calendar.

 	5.3.1.1	Codes d'état
On donne ci-dessous des exemples de codes de réponse qu'on s'attend à obtenir dans une réponse à une demande MKCALENDAR. Noter que cette liste n'est pas exhaustive.

201 (Créée) – la ressource de collection de calendriers a été entièrement créée ;

207 (Multi états) - la ressource de collection de calendriers n'a pas été créée car une ou plusieurs instructions DAV:set spécifiées dans le corps de demande pourraient n'être pas traitées avec succès. Les codes suivants sont des exemples de codes de réponse qu'on s'attend à voir utiliser dans une réponse 207 (Multi états) dans cette situation :
403 (Interdit) - le client, pour une raison que le serveur choisit de ne pas spécifier, ne peut pas altérer une des propriétés ;
409 (Conflit) - le client a fourni une valeur dont la sémantique n'est pas appropriée pour la propriété. Cela inclut d'essayer d'établir des propriétés en lecture seule ;
424 (Échec de dépendance) - l'instruction DAV:set sur la ressource spécifiée aurait réussi si il n'y avait pas eu l'échec d'une autre instruction DAV:set spécifiée dans le corps de demande ;
423 (Verrouillée) - la ressource spécifiée est verrouillée et le client n'est pas un possesseur du verrou ou le type de verrou exige qu'un jeton de verrou soit soumis et le client ne l'a pas soumis ; et
507 (Mémorisation insuffisante) - le serveur n'avait pas un espace suffisant pour enregistrer la propriété;

403 (Interdit) - Cela indique au moins une de deux conditions : 1) le serveur ne permet pas la création de collections de calendriers à la localisation donnée dans son espace de noms, ou 2) la collection parent de l'URI de demande existe mais ne peut pas accepter de membres ;

409 (Conflit) - Une collection ne peut pas être faite à l'URI de demande tant qu'une ou plusieurs collections intermédiaires n'ont pas été créées ;

415 (Type de support non pris en charge) - Le serveur ne prend pas en charge le type de demande du corps ; et

507 (Mémorisation insuffisante) - La ressource n'a pas un espace suffisant pour enregistrer l'état de la ressource après l'exécution de cette méthode.

 	5.3.1.2	Exemple : Demande MKCALENDAR réussie
Cet exemple crée une collection de calendriers appelée /home/lisa/calendars/events/ sur le serveur cal.exemple.com avec des valeurs spécifiques pour les propriétés DAV:displayname, CALDAV:calendar-description, CALDAV:supported-calendar-component-set, et CALDAV:calendar-timezone.

>> Demande <<

MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
Host: cal.exemple.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>Événements de Lisa</D:displayname>
      <C:calendar-description xml:lang="fr"
>Calendrier restreint aux événements.</C:calendar-description>
      <C:supported-calendar-component-set>
        <C:comp name="VEVENT"/>
      </C:supported-calendar-component-set>
      <C:calendar-timezone><![CDATA[BEGIN:VCALENDAR
PRODID:-//Exemple 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>

>> Réponse <<

HTTP/1.1 201 Created
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Length: 0

 	5.3.2	Création de ressource d'objet Calendrier
Les clients remplissent les collections de calendriers avec les ressources d'objet Calendrier. L'URL pour chaque ressource d'objet de calendrier est entièrement arbitraire et n'a pas besoin de porter une relation spécifique avec les propriétés iCalendar ou autres métadonnées de la ressource d'objet de calendrier. Les nouvelles ressources d'objet Calendrier DOIVENT être créées avec une demande PUT ciblée sur un URI non transposé. Une demande PUT ciblée sur un URI transposé met à jour une ressource d'objet de calendrier existante.

Quand des serveurs créent de nouvelles ressources, il ne leur est pas difficile de choisir un URI non transposé. C'est un peu plus difficile pour les clients, parce qu'un client peut ne pas vouloir examiner toutes les ressources de la collection et peut ne pas vouloir parcourir la collection entière pour s'assurer qu'une nouvelle ressource n'est pas créée avec une collision de noms. Cependant, il y a un dispositif HTTP pour traiter cela. Si le client a l'intention de créer une nouvelle ressource non de collection, comme un nouveau VEVENT, le client DEVRAIT utiliser l'en-tête de demande HTTP "If-None-Match: *" sur la demande PUT. L'URI de demande sur la demande PUT DOIT inclure la collection cible, où la ressource est à créer, plus le nom de la ressource dans le dernier segment de chemin. L'en-tête de demande "If-None-Match: *" assure que le client ne va pas écraser par inadvertence une ressouce existante si le dernier segment de chemin se trouvait être déjà utilisé.

>> Demande <<

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:-//Exemple Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:20010712T182145Z-123401@exemple.com
DTSTAMP:20060712T182145Z
DTSTART:20060714T170000Z
DTEND:20060715T040000Z
SUMMARY:Bastille Day Party
END:VEVENT
END:VCALENDAR

>> Réponse <<

HTTP/1.1 201 Created
Content-Length: 0
Date: Sat, 11 Nov 2006 09:32:12 GMT
ETag: "123456789-000-111"

La demande pour changer un événement existant est la même, mais avec une ETag spécifique dans l'en-tête "If-Match", plutôt que dans l'en-tête "If-None-Match".

Comme indiqué au paragraphe 3.10 de la [RFC2445], l'URL des ressources d'objet Calendrier contenant (un ensemble arbitraire de) les informations de calendrier et de programmation peut être muni d'un suffixe ".ics", et l'URL des ressources d'objet Calendrier contenant des informations libres ou d'heures ouvrables peut être muni du suffixe ".ifb".

 	5.3.2.1	Préconditions supplémentaires pour PUT, COPY, et MOVE
La présente spécification crée des préconditions supplémentaires pour les méthodes PUT, COPY, et MOVE. Ces préconditions s'appliquent quand une opération PUT d'une ressource d'objet de calendrier se produit dans une collection de calendriers, ou quand une opération COPY ou MOVE d'une ressource d'objet de calendrier se produit dans une collection de calendriers, ou quand une opération COPY ou MOVE se produit sur une collection de calendriers.

Les nouvelles préconditions sont :

(CALDAV;supported-calendar-data) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT être un type de support pris en charge (c'est-à-dire, iCalendar) pour les ressources d'objet Calendrier;

(CALDAV:valid-calendar-data) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT être de données valides pour le type de prise en charge spécifié (c'est-à-dire, DOIT contenir des données iCalendar valides) ;

(CALDAV:valid-calendar-object-resource) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT respecter toutes les restrictions spécifiées au paragraphe 4.1 (par exemple, les ressources d'objet Calendrier NE DOIVENT PAS contenir plus d'un type de composant de calendrier, les ressources d'objet Calendrier NE DOIVENT PAS spécifier la propriété METHOD de iCalendar, etc.) ;

(CALDAV:supported-calendar-component) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT contenir un type de composant de calendrier pris en charge dans la collection de calendriers ciblée  ;

(CALDAV:no-uid-conflict) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, NE DOIT PAS spécifier une valeur de propriété iCalendar UID déjà utilisée dans la collection de calendriers ciblée ou écraser une ressource d'objet de calendrier existante avec une qui a une valeur de propriété UID différente. Les serveurs DEVRAIENT rapporter l'URL de la ressource qui utilise déjà la même valeur de propriété UID dans l'élément DAV:href ;

<!ELEMENT no-uid-conflict (DAV:href)>

(CALDAV:calendar-collection-location-ok) : dans une demande COPY ou MOVE, quand l'URI de demande est une collection de calendriers, l'URI de destination DOIT identifier un lieu où une collection de calendriers peut être créée ;

(CALDAV:max-resource-size) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT avoir une taille en octets inférieure ou égale à la valeur de la propriété CALDAV:max-resource-size (paragraphe  5.2.5) sur la collection de calendriers où la ressource va être mémorisée ;

(CALDAV:min-date-time) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT avoir toutes ses valeurs de propriété iCalendar DATE ou DATE-TIME (pour chaque instance récurrente) supérieure ou égale à la valeur de la propriété CALDAV:min-date-time (paragraphe 5.2.6) sur la collection de calendriers où la ressource va être mémorisée ;

(CALDAV:max-date-time) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT avoir toutes ses valeurs de propriété iCalendar DATE ou DATE-TIME (pour chaque instance récurrente) inférieure à la valeur de la propriété CALDAV:max-date-time (paragraphe 5.2.7) sur la collection de calendriers où la ressource va être mémorisée ;

(CALDAV:max-instances) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT générer un nombre d'instances récurrentes inférieur ou égal à la valeur de la propriété CALDAV:max-instances (paragraphe 5.2.8) sur la collection de calendriers où la ressource va être mémorisée ;

(CALDAV:max-attendees-per-instance) : la ressource soumise dans la demande PUT, ou ciblée par une demande COPY ou MOVE, DOIT avoir un nombre de propriétés ATTENDEE sur toute instance inférieure ou égale à la valeur de la propriété CALDAV:max-attendees-per-instance (paragraphe 5.2.9) sur la collection de calendriers où la ressource va être mémorisée.

 	5.3.3	Composants, propriétés, et paramètres non standard 
iCalendar fournit un "mécanisme standard pour faire des choses non standard". La prise en charge de cette extension permet aux mises en œuvre d'utiliser des composants, propriétés, et paramètres non standard dont les noms sont munis du préfixe "X-".

Les serveurs DOIVENT prendre en charge l'usage de composants, propriétés, et paramètres non standard dans les ressources d'objet Calendrier mémorisées via la méthode PUT.

Les serveurs peuvent devoir appliquer les règles de leurs propres composants, propriétés, ou paramètres "privés", de sorte que les serveurs PEUVENT rejeter les tentatives des clients de les changer ou d'utiliser pour eux des valeurs en dehors de toutes restrictions que le serveur peut avoir. Les serveurs DEVRAIENT s'assurer que tous les composants, propriétés, ou paramètres "privés" qu'il utilise suivent la convention d'inclure un identifiant de fabricant dans le nom "X-", comme décrit au paragraphe 4.2 de la [RFC2445], par exemple, "X-ABC-PRIVATE".

 	5.3.4	Étiquette d'entité de ressource d'objet Calendar
La propriété DAV:getetag DOIT être définie et établir une forte étiquette d'entité sur toutes les ressources d'objet Calendrier.

Une réponse à une demande GET ciblée sur une ressource d'objet de calendrier DOIT contenir un champ d'en-tête de réponse ETag indiquant la valeur courante de la forte étiquette d'entité de la ressource d'objet de calendrier.

Les serveurs DEVRAIENT retourner une forte étiquette d'entité (en-tête ETag) dans une réponse PUT quand la ressource d'objet de calendrier mémorisée est équivalente par égalité d'octet à la ressource d'objet de calendrier soumise dans le corps de la demande PUT. Cela permet aux clients d'utiliser fiablement la forte étiquette d'entité retournée pour les besoins de la synchronisation des données. Par exemple, le client peut faire une demande PROPFIND sur la ressource d'objet de calendrier mémorisée et avoir la propriété DAV:getetag en retour, et comparer cette valeur avec la forte étiquette d'entité qu'il a reçue dans la réponse PUT, et savoir que si elles sont égales, alors la ressource d'objet de calendrier sur le serveur n'a pas été changée.

Dans le cas où les données mémorisées par un serveur par suite d'une demande PUT ne sont pas équivalentes par égalité d'octet à la ressource d'objet de calendrier soumise, le comportement de l'en-tête de réponse ETag n'est pas spécifié ici, à l'exception qu'une forte étiquette d'entité NE DOIT PAS être retournée dans la réponse. Par suite, les clients peuvent avoir besoin de restituer la ressource d'objet de calendrier (et ETag) modifiée comme base d'autres changements, plutôt que d'utiliser la ressource d'objet de calendrier qu'ils avaient envoyée avec la demande PUT.

 	6.	Contrôle d'accès au calendrier
 	6.1	Privilège de calendrier
Les serveurs CalDAV DOIVENT prendre en charge et respecter les exigences de WebDAV ACL [RFC3744]. WebDAV ACL fournit un cadre pour un ensemble extensible de privilèges qui peuvent être appliqués aux collections et ressources ordinaires WebDAV. Les serveurs CalDAV DOIVENT aussi prendre en charge le privilège de calendrier défini dans cette section.

 	6.1.1	Privilège CALDAV:read-free-busy
Les utilisateurs Calendar souhaitent souvent permettre aux autres utilisateurs de voir les informations sur leurs heures de travail, sans voir les autres détails des composants du calendrier (par exemple, lieux, sommaires, participants). Cela permet une confidentialité significative tout en permettant aux autres utilisateurs de programmer des réunions aux moments où l'utilisateur a le plus de chances d'être libre.

Le privilege CALDAV:read-free-busy contrôle quelles collections de calendriers, collections régulières, et ressources d'objet Calendrier sont examinées quand une demande REPORT CALDAV:free-busy-query est traitée (voir au paragraphe  7.10). Ce privilège peut être accordé sur des collections de calendriers, des collections régulières, ou des ressources d'objet Calendrier.

Les serveurs DOIVENT prendre en charge ce privilège sur toutes les collections de calendriers, collections régulières, et ressources d'objet Calendrier.

<!ELEMENT read-free-busy EMPTY>

Le privilège CALDAV:read-free-busy DOIT être agrégé dans le privilège DAV:read. Les serveurs DOIVENT permettre que le privilège CALDAV:read-free-busy soit accordé sans que le privilège DAV:read le soit.

Les clients devraient noter que quand seul le privilège CALDAV:read-free-busy a été accordé sur une ressource, l'accès aux opérations GET, HEAD, OPTIONS, et PROPFIND sur la ressource n'est pas impliqué (ces opérations sont gouvernées par le privilege DAV:read).

 	6.2	Propriété principale supplémentaire
Cette section définit une propriété supplémentaire pour les ressources principales de WebDAV, comme défini dans la [RFC3744].

 	6.2.1	Propriété CALDAV:calendar-home-set
Nom : calendar-home-set
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Identifie l'URL de toutes les collections WebDAV qui contiennent des collections de calendriers possédées par la ressource principale associée.
Conformité : Cette propriété DEVRAIT être définie sur une ressource principale. Si elle est définie, elle PEUT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe  2.14.1 de la [RFC2518]).

Description : La propriété CALDAV:calendar-home-set est destinée à permettre aux usagers de trouver facilement les collections de calendriers possédées par le principal. Normalement, les utilisateurs vont grouper toutes les collections de calendriers qu'ils possèdent sous une collection commune. Cette propriété spécifie l'URL des collections qui sont soit des collections de calendriers ou des collections ordinaires qui ont des collections de calendriers filles ou descendantes possédées par le principal.

Définition :  <!ELEMENT calendar-home-set (DAV:href*)>

Exemple :

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

 	7.	Rapports de calendrier

Cette section définit les rapports que les serveurs CalDAV DOIVENT prendre en charge sur les collections de calendriers et les ressources d'objet Calendrier.

Les serveurs CalDAV DOIVENT annoncer la prise en charge de ces rapports sur toutes les collections de calendriers et les ressources d'objet Calendrier avec la propriété DAV:supported-report-set, définie au paragraphe 3.1.5 de la [RFC3253]. Les serveurs CalDAV PEUVENT aussi annoncer la prise en charge de ces rapports sur les collections ordinaires.

Certains de ces rapports permettent de retourner des données de calendrier (éventuellement provenant de multiples ressources).

 	7.1	Méthode REPORT
La méthode REPORT (définie au paragraphe 3.6 de la [RFC3253]) fournit un mécanisme extensible pour obtenir des informations sur une ou plusieurs resources. À la différence de la méthode PROPFIND qui retourne la valeur d'une ou plusieurs propriétés désignées, la méthode REPORT peut impliquer un traitement plus complexe. REPORT est valable dans les cas où le serveur a accès à toutes les informations nécessaires pour effectuer la demande complexe (comme une interrogation) et lorsque il faudrait plusieurs demandes pour que le client restitue les informations nécessaires pour effectuer la même demande.

Les serveurs CalDAV DOIVENT prendre en charge le rapport DAV:expand-property défini au paragraphe 3.8 de la [RFC3253].

 	7.2	Collections ordinaires
Les serveurs PEUVENT prendre en charge les rapports définis dans le présent document sur les collections ordinaires (collections qui ne sont pas des collections de calendriers) en plus des collections de calendriers ou des ressources d'objet Calendrier. En calculant les réponses aux rapports sur les collections ordinaires, les serveurs DOIVENT seulement considérer les ressources d'objet Calendrier contenues dans les collections de calendriers qui sont ciblées par le demande REPORT, sur la base de la valeur de l'en-tête de demande Depth.

 	7.3	Date et heure flottante
iCalendar fournit un moyen de spécifier des valeurs de DATE et DATE-TIME qui ne sont pas liées à une zone horaire en particulier, ci-après appelées respectivement "date flottante" et "heure flottante". Ces valeurs sont utilisées pour représenter la même valeur de jour, heure, minute, et seconde, sans considération de la zone horaire observée. Par exemple, la valeur de DATE "20051111", représente le 11 novembre 2005 sans zone horaire spécifique, tandis que la valeur de DATE-TIME de "20051111T111100" représente le 11 novembre 2005, à 11:11 A.M. sans zone horaire spécifique.

Les serveurs CalDAV peuvent avoir besoin de convertir des valeurs de "date flottante" et de "heure flottante" en date avec des valeurs de temps UTC dans le traitement des demandes REPORT de calendriers.

Pour le rapport de CALDAV:calendar-query, les serveurs CalDAV DOIVENT s'appuyer sur la valeur de l'élément XML CALDAV:timezone, si il est spécifié au titre du corps de demande, pour effectuer la conversion appropriée des valeurs de "date flottante" et "heure flottante" en date avec des valeurs de temps UTC. Si l'élément XML CALDAV:timezone n'est pas spécifié dans le corps de demande, les serveurs CalDAV DOIVENT s'appuyer sur la valeur de la propriété CALDAV:calendar-timezone, si elle est définie, ou autrement les serveurs CalDAV PEUVENT s'appuyer sur la zone horaire de leur choix.

Pour le rapport de CALDAV:free-busy-query, les serveurs CalDAV DOIT s'appuyer sur la valeur de la propriété CALDAV:calendar-timezone, si elle est définie, pour calculer la valeur de période horaire FREEBUSY appropriée comme date avec temps UTC pour les composants de calendrier programmés avec une "date flottante" ou "heure flottante". Si la propriété CALDAV:calendar-timezone n'est pas définie, les serveurs CalDAV PEUVENT s'appuyer sur la zone horaire de leur choix.

 	7.4.	Filtrage de gamme de temps
Certains des rapports définis dans cette section peuvent inclure un filtre de gamme de temps qui est utilisé pour restreindre l'ensemble des ressources d'objet Calendrier retourné à seulement celles qui recouvrent les gammes de temps spécifiées. Le filtre de gamme de temps peut être appliqué à un composant de calendrier comme un tout, ou à des propriétés spécifiques de composant de calendrier avec des types de valeur de DATE ou DATE-TIME.

Pour déterminer si une ressource d'objet de calendrier correspond à l'élément de filtre de gamme de temps, les heures de début et de fin du composant ou propriété ciblé sont déterminés puis comparés à la gamme de temps demandée. Si il y a un chevauchement avec la gamme de temps demandée, alors la ressource d'objet de calendrier correspond à l'élément de filtre. Les règles définies dans la [RFC2445] pour déterminer les heures réelles de début et de fin des composants de calendrier DOIVENT être utilisées, et elles sont énumérées au paragraphe 9.9 du présent document.

Quand un tel filtrage de gamme de temps est utilisé, une considération particulière doit être portée à la récurrence des composants de calendrier, tels que VEVENT et VTODO. Le serveur DOIT étendre les composants récurrents pour déterminer si des instances de récurrence chevauchent les gammes de temps spécifiées. Si une ou plusieurs instances de récurrence chevauche la gamme de temps, alors la ressource d'objet de calendrier correspond à l'élément de filre.

 	7.5	Recherche de collations de Text:
Certains des rapports définis dans ce paragraphe font des confrontations de texte de chaînes de caractères fournies par le client et sont comparées aux données de calendrier mémorisées. Comme les données de iCalendar sont, par défaut, codée dans le jeu de caractères UTF-8 et peuvent inclure des caractères en-dehors de la gamme des caractères US-ASCII dans certaines valeurs de propriété et paramètre, il est nécessaire de s'assurer que la confrontation de texte suit des règles bien définies.

Pour traiter cela, la présente spécification utilise le registre de collations de l'IANA défini dans la [RFC4790] pour spécifier les collations qui peuvent être utilisées pour effectuer les opérations de comparaison de texte avec une règle bien définie.

Les comparaisons utilisées dans CalDAV sont toutes des correspondances de "sous chaîne", conformément au paragraphe 4.2 de la [RFC4790]. Les collations acceptées par le serveur DOIVENT prendre en charge les opérations de correspondance de "sous chaîne".

Il est EXIGÉ des serveurs qu'ils prennent en charge les collations "i;ascii-casemap" et "i;octet", comme décrit dans la [RFC4790], et ils PEUVENT prendre en charge d'autres collations.

Les serveurs DOIVENT annoncer l'ensemble de collations qu'ils prennent en charge via la propriété CALDAV:supported-collation-set définie sur toute ressource qui prend en charge les rapports qui utilisent des collations.

Les clients DOIVENT utiliser seulement les collations de la liste annoncée par le serveur.

En l'absence d'une collation explicitement spécifiée par le client, ou si le client spécifie l'identifiant de collation "par défaut" (comme défini dans la [RFC4790], paragraphe 3.1) le serveur DOIT par défaut utiliser la collation "i;ascii-casemap".

Des caractères génériques (comme défini dans la [RFC4790], paragraphe 3.2) NE DOIVENT PAS être utilisés dans l'identifiant de collation.

Si le client choisit une collation non prise en charge par le serveur, le serveur DOIT répondre avec une réponse d'erreur de précondition CALDAV:supported-collation.

 	7.5.1	Propriété CALDAV:supported-collation-set
Nom : supported-collation-set
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Identifie l'ensemble de collations pris en charge par le serveur pour les opérations de confrontation de texte.
Conformité : Cette propriété DOIT être définie sur toute ressource qui prend en charge un rapport qui ne confronte pas de texte. Si elle est définie, elle DOIT être protégée et NE DEVRAIT PAS être retournée par une demande PROPFIND DAV:allprop (comme défini au paragraphe 12.14.1 de la [RFC2518]).

Description: La propriété CALDAV:supported-collation-set contient zéro, un ou plusieurs éléments CALDAV:supported-collation, qui spécifient les identifiants de collection des collations prises en charge par le serveur.

Définition :

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

Exemple :

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

 	7.6	Restitution partielle
Certains rapports de calendrier définis dans le présent document permettent une restitution partielle des ressources d'objet Calendrier. Un client CalDAV peut spécifier quelles informations retourner dans le corps d'une demande REPORT de calendrier.

Un client CalDAV peut demander des valeurs particulières de propriété WebDAV, toutes les valeurs de propriété WebDAV, ou une liste des noms des propriétés WebDAV de la ressource. Un client CalDAV peut aussi demander que des données de calendrier soient retournées et spécifier si tous les composants et propriétés de calendrier devraient être retournés, ou seulement certains. Voir CALDAV:calendar-data au paragraphe 9.6.

Par défaut, les données de calendrier retournées vont inclure le composant qui définit l'ensemble de récurrence, appelé le "composant maître", ainsi que les composants qui définissent des exceptions à l'ensemble de récurrence, appelés les "composants outrepassés".

Un client CalDAV qui est seulement intéressé par les instances de récurrence qui se chevauchent comme gamme de temps spécifiée peut demander de recevoir seulement le "composant maître", avec les "composants outrepassés" qui impactent la gamme de temps spécifiée, et donc, limiter les données retournées par le serveur (voir CALDAV:limit-recurrence-set au paragraphe 9.6.6). Un composant outrepassé impacte une gamme de temps si ses heures courantes de début et de fin se chevauchent avec la gamme de temps, ou si les heures originales de début et de fin – celles qui auraient été utilisées si l'instance n'avait pas été outrepassée – chevauchent la gamme de temps, ou si il affecte d'autres instances qui chevauchent la gamme de temps.

Un client CalDAV qui ne prend pas en charge les propriétés de récurrence (c'est-à-dire, EXDATE, EXRULE, RDATE, et RRULE) et éventuellement les composants VTIMEZONE, ou un client qui ne veut pas effectuer l'expansion de récurrence à cause de capacités de traitement limitées, peut demander de recevoir seulement les instances de récurrence qui chevauchent une gamme de temps spécifiée comme des composants de calendrier séparés dont chacun définit exactement une instance de récurrence (voir CALDAV:expand au paragraphe 9.6.5.)

Finalement, dans le cas de composants VFREEBUSY, un client CalDAV peut demander de recevoir seulement les valeurs de propriété FREEBUSY qui chevauchent une gamme de temps spécifiée (voir CALDAV:limit-freebusy-set au paragraphe  9.6.7.)

 	7.7	Composants, propriétés, et paramètres non standard
Les serveurs DOIVENT prendre en charge l'utilisation de composants, propriétés, ou noms de paramètre non standard dans l'élément XML CALDAV:calendar-data dans les demandes REPORT de calendrier pour permettre aux clients de demander que les composants, propriétés, ou noms de paramètre non standard soient retournés dans les données de calendrier fournies dans la réponse.

Les serveurs PEUVENT prendre en charge l'utilisation de composants, propriétés, ou noms de paramètre non standard dans les éléments XML CALDAV:comp-filter, CALDAV:prop-filter, et CALDAV:param-filter spécifiés dans l'élément XML CALDAV:filter des demandes REPORT de calendrier.

Les serveurs DOIVENT échouer avec la précondition CALDAV:supported-filter si une demande REPORT de calendier utilise un élément XML CALDAV:comp-filter, CALDAV:prop-filter, ou CALDAV:param-filter qui fait référence à un composant, propriété, ou nom de paramètre non standard sur lequel le serveur ne prend pas en charge les interrogations.

 	7.8.	Rapport CALDAV:calendar-query
Le rapport CALDAV:calendar-query effectue une recherche de toutes les ressources d'objet Calendrier qui correspondent à un filtre spécifié. La réponse de ce rapport va contenir toutes les propriétés WebDAV et données de ressource d'objet de calendrier spécifiées dans la demande. Dans le cas de l'élément XML CALDAV:calendar-data, on peut explicitement spécifier les composants et propriétés de calendrier qui devraient être retournés dans les données de ressource d'objet de calendrier qui correspondent au filtre.

Le format de ce rapport est modélisé sur la méthode PROPFIND. Les corps de demande et réponse du rapport CALDAV:calendar-query utilisent les éléments XML qui sont aussi utilisés par PROPFIND. En particulier, la demande peut inclure des éléments XML pour demander que les propriétés WebDAV soient retournées. Quand cela arrive, la réponse devrait suivre le même comportement que PROPFIND par rapport aux éléments de réponse DAV:multistatus utilisés pour retournr des résultats de propriété spécifiques. Par exemple, une demande pour restituer la valeur d'une propriété qui n'existe pas est une erreur et DOIT être notée avec un élément XML de réponse qui contient une valeur d'état 404 (Non trouvé).

La prise en charge du rapport CALDAV:calendar-query est EXIGÉE.

Note d'ordre : le corps de demande DOIT être un élément XML CALDAV:calendar-query, comme défini au paragraphe  9.5. La demande PEUT inclure un en-tête Depth. Si aucun en-tête Depth n'est inclus, Depth:0 est supposé. Le corps de réponse pour une demande réussie DOIT être un élément XML DAV: multistatus (c'est-à-dire, la réponse utilise le même format que la réponse pour PROPFIND). Dans le cas où il n'y a pas d'élément de réponse, l'élément XML DAV:multistatus retourné est vide. Le corps de réponse pour une demande de rapport CALDAV:calendar-query réussie DOIT contenir un élément DAV:response pour chaque objet iCalendar qui correspondait au filtre de la recherche. Les données Calendar sont retournées dans l'élément XML CALDAV:calendar-data à l'intérieur de l'élément XML DAV:propstat.

Préconditions : 
(CALDAV;supported-calendar-data) : les attributs "content-type" et "version" de l'élément XML CALDAV:calendar-data (voir au paragraphe 9.6) spécifient un type de support pris en charge par le serveur pour les ressources d'objet Calendrier.

(CALDAV:valid-filter) : l'élément XML CALDAV:filter (voir au paragraphe 9.7) spécifié dans la demande REPORT DOIT être valide. Par exemple, un CALDAV:filter ne peut pas résider dans un élément <C:comp name="VEVENT"> dans un élément <C:comp name="VTODO">, et un CALDAV:filter ne peut pas résider dans un élément <C:time-range start="..." end="..."> dans un élément <C:prop name="SUMMARY">.

(CALDAV;supported-filter) : les éléments XML CALDAV:comp-filter (paragraphe 9.7.1), CALDAV:prop-filter (paragraphe 9.7.2), et CALDAV:param-filter (paragraphe 9.7.3) utilisés dans l'élément XML CALDAV:filter (paragraphe 9.7) dans la demande REPORT font seulement référence aux composants, propriétés, et paramètres pour lesquels les interrogations sont prises en charge par le serveur, c'est-à-dire, si l'élément CALDAV:filter tente de faire référence à un composant, propriété, ou paramètre non pris en charge, cette précondition est violée. Les serveurs DEVRAIENT rapporter le CALDAV:comp-filter, CALDAV:prop-filter, ou CALDAV:param-filter pour lequel il ne fournit pas la prise en charge.

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

(CALDAV:valid-calendar-data) : la zone horaire spécifiée dans la demande REPORT DOIT être un objet iCalendar valide contenant un seul composant VTIMEZONE valide.

(CALDAV:min-date-time) : tout élément XML spécifiant une plage horaire DOIT avoir ses valeurs de début ou de fin de DATE ou DATE-TIME supérieures ou égales à la valeur de la propriété CALDAV:min-date-time (paragraphe 5.2.6) sur les collections de calendriers ciblées par la demande REPORT ;

(CALDAV:max-date-time) : tout élément XML spécifiant une plage horaire DOIT avoir ses valeurs de début ou de fin de DATE ou DATE-TIME inférieures ou égales à la valeur de la propriété CALDAV:max-date-time (paragraphe 5.2.7) sur les collections de calendriers ciblées par la demande REPORT ;

(CALDAV:supported-collation) : tout attribut XML spécifiant une collation DOIT spécifier une collation prise en charge par le serveur comme décrit au paragraphe 7.5.

Postconditions : (DAV:number-of-matches-within-limits) : le nombre de ressources d'objet Calendrier correspondantes doit tomber dans des limites prédéfinies spécifiques du serveur. Par exemple, cette condition pourrait être déclenchée si une spécification de recherche causait le retour d'un nombre extrêmement grand de réponses.

 	7.8.1	Exemple : restitution partielle d'événements par gamme de temps
Dans cet exemple, le client demande au serveur de retourner des composants et propriétés spécifiques des composants VEVENT qui chevauchent la gamme de temps du 4 janvier 2006, à 00:00:00 A.M. UTC au 5 janvier 2006, à 00:00:00 A.M. UTC. De plus, la propriété DAV:getetag est aussi demandée et retournée au titre de la réponse. Noter que le premier objet de calendrier retourné est un événement récurrent dont la première instance est en dehors de la gamme de temps demandée, mais dont la troisième instance chevauche bien la gamme de temps. Noter qu'à cause des restrictions des éléments CALDAV:calendar-data, la propriété DTSTAMP dans les composants VEVENT n'a pas été retournée, et la seule propriété retournée dans l'objet VCALENDAR est VERSION.

Voir à l'Appendce B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

HTTP/1.1 207 Multi-Status
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd2"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=US/Eastern:20060102T120000
DURATION:PT1H
RRULE:FREQ=DAILY;COUNT=5
SUMMARY:Event #2
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
BEGIN:VEVENT
DTSTART;TZID=US/Eastern:20060104T140000
DURATION:PT1H
RECURRENCE-ID;TZID=US/Eastern:20060104T120000
SUMMARY:Event #2 bis
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
BEGIN:VEVENT
DTSTART;TZID=US/Eastern:20060106T140000
DURATION:PT1H
RECURRENCE-ID;TZID=US/Eastern:20060106T120000
SUMMARY:Event #2 bis bis
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd3"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=US/Eastern:20060104T100000
DURATION:PT1H
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

 	7.8.2	Exemple : restitution partielle d'événements récurrents
Dans cet exemple, le client demande au serveur de retourner les composants VEVENT qui chevauchent la gamme de temps du 3 janvier 2006, à 00: 00:00 A.M. UTC au 5 janvier 2006, à 00:00:00 A.M. UTC. L'utilisation de l'élément CALDAV:limit-recurrence-set cause le retour par le serveur de seulement les composants de récurrence qui chevauchent la gamme de temps spécifiée dans cet élément ou qui affectent d'autres instances qui chevauchent la gamme de temps (par exemple, dans le cas d'un comportement THISANDFUTURE). Dans cet exemple, le premier composant outrepassé dans la ressource correspondante est retourné, mais le second ne l'est pas.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

HTTP/1.1 207 Multi-Status
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd2"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART;TZID=US/Eastern:20060102T120000
DURATION:PT1H
RRULE:FREQ=DAILY;COUNT=5
SUMMARY:Event #2
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART;TZID=US/Eastern:20060104T140000
DURATION:PT1H
RECURRENCE-ID;TZID=US/Eastern:20060104T120000
SUMMARY:Event #2 bis
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd3"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:US/Eastern
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
DTSTAMP:20060206T001220Z
DTSTART;TZID=US/Eastern:20060104T100000
DURATION:PT1H
LAST-MODIFIED:20060206T001330Z
ORGANIZER:mailto:cyrus@example.com
SEQUENCE:1
STATUS:TENTATIVE
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

 	7.8.3	Exemple : restitution étendue d'événements récurrents
Dans cet exemple, le client demande au serveur de retourner les composants VEVENT qui chevauchent la gamme de temps du 2 janvier 2006, à 00: 00:00 A.M. UTC au 5 janvier 2006, à 00:00:00 A.M. UTC et de retourner les composants récurrents de calendrier expansés en composants individuels d'instance de calendrier récurrentes. L'utilisation de l'élément CALDAV:expand cause le retour par le serveur de seulement les instances de récurrence outrepassées qui chevauchent la gamme de temps spécifiée dans cet élément.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

HTTP/1.1 207 Multi-Status
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd2"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART:20060103T170000
DURATION:PT1H
RECURRENCE-ID:20060103T170000
SUMMARY:Event #2
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART:20060104T190000
DURATION:PT1H
RECURRENCE-ID:20060104T170000
SUMMARY:Event #2 bis
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd3"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
DTSTAMP:20060206T001220Z
DTSTART:20060104T150000
DURATION:PT1H
LAST-MODIFIED:20060206T001330Z
ORGANIZER:mailto:cyrus@example.com
SEQUENCE:1
STATUS:TENTATIVE
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

 	7.8.4	Exemple : restitution partielle de composants mémorisés d'occupation/libre
Dans cet exemple, le client demande au serveur de retourner les composants VFREEBUSY qui ont des informations d'occupation/libre qui chevauchent la gamme de temps du 2 janvier 2006, à 00:00:00 A.M. UTC (inclus) au 3 janvier 2006, à 00:00:00 A.M. UTC (exclus). L'utilisation de l'élément CALDAV:limit-freebusy-set cause le retour par le serveur de seulement les valeurs de la propriété FREEBUSY qui chevauchent la gamme de temps spécifiée dans cet élément. Noter que ce n'est pas un exemple de découverte de quand le possesseur du calendrier est occupé.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

HTTP/1.1 207 Multi-Status
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd8"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VFREEBUSY
ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
UID:76ef34-54a3d2@example.com
DTSTAMP:20050530T123421Z
DTSTART:20060101T100000Z
DTEND:20060108T100000Z
FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

 	7.8.5	Exemple : restitution de To-Do par gamme d'heure d'alarme
Dans cet exemple, le client demande au serveur de retourner les composants VTODO qui ont un déclenchement d'alarme programmé dans la gamme de temps spécifiée.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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>

 	7.8.6	Exemple : restitution d'événement par UID
Dans cet exemple, le client demande au serveur de retourner le composant VEVENT qui a la propriété UID réglée à "DC6C50A017428C5216A2F1CD@example.com".

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
DTSTAMP:20060206T001220Z
DTSTART;TZID=US/Eastern:20060104T100000
DURATION:PT1H
LAST-MODIFIED:20060206T001330Z
ORGANIZER:mailto:cyrus@example.com
SEQUENCE:1
STATUS:TENTATIVE
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

 	7.8.7	Exemple : restitution d'événements par PARTSTAT
Dans cet exemple, le client demande au serveur de retourner les composants VEVENT qui ont la propriété ATTENDEE avec la valeur "mailto:lisa@example.com" et pour laquelle le paramètre PARTSTAT est réglé à NEEDS-ACTION.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
DTSTAMP:20060206T001220Z
DTSTART;TZID=US/Eastern:20060104T100000
DURATION:PT1H
LAST-MODIFIED:20060206T001330Z
ORGANIZER:mailto:cyrus@example.com
SEQUENCE:1
STATUS:TENTATIVE
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

 	7.8.8	Exemple : restitution d'événements seuls
Dans cet exemple, le client demande au serveur de retourner tous les composants VEVENT.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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
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
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
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
DTSTAMP:20060206T001220Z
DTSTART;TZID=US/Eastern:20060104T100000
DURATION:PT1H
LAST-MODIFIED:20060206T001330Z
ORGANIZER:mailto:cyrus@example.com
SEQUENCE:1
STATUS:TENTATIVE
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
   </D:response>
</D:multistatus>

 	7.8.9	Exemple : restitution de tous les To-Do en instance
Dans cet exemple, le client demande au serveur de retourner tous les composants VTODO qui ne comportent pas une propriété COMPLETED et n'ont pas une valeur de propriété STATUS correspondant à CANCELLED, c'est-à-dire,  les VTODO qui doivent encore être retravaillés.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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: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>

 	7.8.10	Exemple : tentative d'interroger une propriété non prise en charge
Dans cet exemple, le client demande au serveur de retourner tous les composants VEVENT qui incluent une propriété X-ABC-GUID avec une valeur correspondant à "ABC". Cependant, le serveur ne prend pas en charge l'interogation d'une propriété non standard, et retourne une réponse d'erreur.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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>

 	7.9	Rapport CALDAV:calendar-multiget
Le rapport CALDAV:calendar-multiget est utilisé pour restituer des ressources d'objet Calendrier spécifiques au sein d'une collection, si l'URI de demande est une collection, ou pour restituer une ressource d'objet de calendrier spécifique, si l'URI de demande est une ressource d'objet de calendrier. Ce rapport est similaire au rapport CALDAV:calendar-query (voir au paragraphe 7.8) sauf qu'il prend une liste d'éléments DAV:href, au lieu d'un élément CALDAV:filter, pour déterminer quelles ressources d'objet Calendrier retourner.

La prise en charge du rapport CALDAV:calendar-multiget est EXIGÉE.

Note d'ordre : le corps de demande DOIT être un élément XML CALDAV:calendar-multiget (voir au paragraphe 9.10). Si l'URI de demande est une ressource de collection, les éléments DAV:href DOIVENT alors se référer aux ressources d'objet Calendrier au sein de cette collection, et ils PEUVENT se référer aux ressources d'objet Calendrier à toute profondeur au sein de la collection. Par suite, l'en-tête "Depth" DOIT être ignoré par le serveur et NE DEVRAIT PAS être envoyé par le client. Si l'URI de demande se réfère à une ressource non de collection, il DOIT alors y avoir un seul élément DAV:href qui est équivalent à l'URI de demande. Le corps de réponse pour une demande réussie DOIT être un élément XML DAV:multistatus. Le corps de réponse pour une demande de rapport CALDAV:calendar-multiget réussie DOIT contenir un élément DAV:response pour chaque ressource d'objet de calendrier référencé par l'ensemble fourni d'éléments DAV:href. Les données de calendrier sont retournées dans l'élément CALDAV:calendar-data à l'intérieur de l'élément DAV:prop. Dans le cas d'une erreur d'accès à une des ressources DAV:href fournies, le serveur DOIT retourner le code d'état d'erreur approprié dans l'élément DAV:status de l'élément DAV:response correspondant.

Préconditions :
(CALDAV;supported-calendar-data) : les attributs "content-type" et "version" des éléments XML CALDAV:calendar-data (paragraphe 9.6) spécifient un type de support pris en charge par le serveur pour les ressources d'objet Calendrier.

(CALDAV:min-date-time) : tout élément XML specifiant une plage horaire DOIT avoir ses valeurs de début ou de fin de DATE ou DATE-TIME supérieures ou égales à la valeur de la propriété CALDAV:min-date-time (paragrraphe 5.2.6) sur les collections de calendriers ciblées par la demande REPORT.

(CALDAV:max-date-time) : tout élément XML spécifiant une plage horaire DOIT avoir ses valeurs de début ou de fin de DATE ou DATE-TIME inférieures ou égales à la valeur de la propriété CALDAV:max-date-time (paragraphe 5.2.7) sur la collection de calendriers ciblée par la demande REPORT.

Postcondition : aucune.

 	7.9.1	Exemple : rapport CALDAV:calendar-multiget réussi
Dans cet exemple, le client demande au serveur de retourner des propriétés spécifiques des composants VEVENT référencés par des URI spécifiques. De plus, la propriété DAV:getetag est aussi demandée et retournée au titre de la réponse. Noter que dans cet exemple, la ressource à http://cal.example.com/bernard/work/mtg1.ics n'existe pas, provoquant une réponse d'état d'erreur.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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
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>
  </D:response>
</D:multistatus>

 	7.10	Rapport CALDAV:free-busy-query
Le rapport CALDAV:free-busy-query génère un composant VFREEBUSY contenant des informations sur les heures libres/occupées pour toutes les ressources d'objet Calendrier ciblées par la demande et qui ont le privilège CALDAV:read-free-busy ou DAV:read accordé à l'utilisateur actuel.

Seuls les composants VEVENT sans propriété TRANSP ou avec la propriété TRANSP réglée à OPAQUE, et les composants VFREEBUSY DEVRAIENT être considérés dans la génération des informations de temps libre/occupé.

Dans le cas de composants VEVENT, le type de temps libre/occupé (FBTYPE) des propriétés FREEBUSY dans le composant VFREEBUSY retourné DEVRAIT être déduit de la valeur des propriétés TRANSP et STATUS, comme mentionné dans le tableau ci-dessous :

VEVENT	VFREEBUSY	
TRANSP 	STATUS	FBTYPE	

OPAQUE (défaut)	CONFIRMED (défaut)	BUSY	
	CANCELLED	FREE	
	TENTATIVE	BUSY-TENTATIVE	
	x-name	BUSY ou x-name	

TRANSPARENT	CONFIRMED	
FREE	
	CANCELLED		
	TENTATIVE		
	x-name		

Les périodes dupliquées d'heures d'occupation avec la même valeur de paramètre FBTYPE NE DEVRAIENT PAS être spécifiées dans le composant VFREEBUSY retourné. Les serveurs DEVRAIENT agréger les périodes consécutives ou en chevauchement de périodes de temps d'occupation du même type. Les périodes de temps d'occupation avec des valeurs différentes de paramètre FBTYPE PEUVENT se chevaucher.

La prise en charge du rapport CALDAV:free-busy-query est EXIGEÉ.

Note d'ordre : le corps de demande DOIT être un élément XML CALDAV:free-busy-query (voir au paragraphe 9.11) qui DOIT contenir exactement un élément XML CALDAV:time-range, comme défini au paragraphe 9.9. La demande PEUT inclure un en-tête Depth. Si un en-tête Depth n'est pas inclus, Depth:0 est supposé. Le corps de réponse pour une demande réussie DOIT être un objet iCalendar qui contient exactement un composant VFREEBUSY qui décrit les intervalles d'heures d'occupation pour les ressources d'objet Calendrier contenant des composants VEVENT, ou VFREEBUSY qui satisfont la valeur de Depth et pour lesquels l'utilisateur actuel a au moins le privilège CALDAV:read-free-busy. Si aucune ressource d'objet Calendrier n'est trouvée qui satisfasse ces conditions, un composant VFREEBUSY sans propriété FREEBUSY DOIT être retourné. Ce rapport returne seulement les informations d'heures d'occupation. Les informations de temps libre peuvent être déduites des informations d'heures d'occupation retournées. Si l'utilisateur actuel n'a pas les privilèges CALDAV:read-free-busy ou DAV:read sur l'URI de demande, la demande de rapport CALDAV:free-busy-query DOIT échouer et retourner une valeur d'état de 404 (Non trouvé). Cette restriction empêchera les utilisateurs de découvrir des URL de ressources pour lesquelles ils ont seulement le privilège CALDAV:read-free-busy. La demande de rapport CALDAV:free-busy-query peut seulement être effectuée pour une collection (soit une collection régulière, soit une collection de calendriers). Une tentative d'effectuer le rapport sur une ressource d'objet de calendrier DOIT échouer et retourner une valeur d'état de 403 (Interdit).

Préconditions : aucune.

Postconditions :
(DAV:number-of-matches-within-limits) : le nombre de ressources d'objet Calendrier correspondants doit échouer dans des limites prédéfiniées spécifiques du serveur. Par exemple, cette postcondition pourrait échouer si la CALDAV:time-range spécifiée causerait la prise en considération d'un nombre extrêmement grand de ressources d'objet Calendrier dans le calcul de la réponse.

 	7.10.1	Exemple : rapport CALDAV:free-busy-query réussi
Dans cet exemple, le client demande au serveur de retourner les informations libre/occupé sur la collection de calendriers /bernard/work/, entre 9:00 A.M. et 5:00 P.M. EST (2:00 P.M. et 10:00 P.M. UTC) le 4 janvier 2006. Le serveur répond, indiquant deux intervalles d'heure occupées d'une heure, dont un est une tentative.

Voir à l'Appendice B les données de calendrier ciblées par cet exemple.

>> Demande <<

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>

>> Réponse <<

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

 	8.	Lignes directrices
 	8.1	Interopérabilité de client à client
Il y a un certain nombre d'actions que les clients peuvent effectuer qui vont être légales (le serveur ne va pas retourner d'erreur) mais qui peuvent dégrader l'interopérabilité avec les autres mises en œuvre des clients qui accèdent aux mêmes données. Par exemple, une règle de récurrence pourrait être remplacée par un ensemble de dates de récurrence, un seul événement récurrent pourrait être remplacé par un ensemble de ressources indépendantes pour représenter chaque récurrence, ou les valeurs d'heure de début/fin peuvent être traduite de la zone horaire originale en une autre zone horaire.  Bien que cet avis relève des bonnes pratiques d'interopérabilité de iCalendar et ne se limite pas au seul usage de CalDAV, les problèmes d'interopérabilié vont probablement être plus évidents dans les cas d'utilisation de CalDAV.

 	8.2	Opérations de synchronisation
WebDAV fournit déjà les fonctionnalités requises pour synchroniser une collection ou ensemble de collections, pour faire des changements hors ligne, et fournit une façon simple pour résoudre les conflits lors de reconnexions. Les ETag sont la clé pour faire de travail, mais elles ne sont pas exigées sur tous les serveurs WebDAV. Comme la fonction hors ligne est plus importante pour les applications de calendrier que certaines autres applications WebDAV, les serveurs CalDAV DOIVENT prendre en charge les ETag, comme spécifié au paragraphe 5.3.4.

 	8.2.1	Utilisation de rapports
 	8.2.1.1	Restriction de la gamme de temps
Les rapports fournis dans CalDAV peuvent être utilisés par les clients pour optimiser leurs performances en termes d'utilisation de la bande passante du réseau et de consommation de ressource dans la machine locale du client. Les deux sont certainement des considérations majeures pour les appareils mobiles ou portables avec des capacités limitées, mais elles sont aussi pertinentes pour les applications de client d'ordinateur personnel dans les cas où les collections de calendriers contiennent de grandes quantités de données.

Normalement, les clients présentent les données de calendrier aux utilisateurs sous des formes qui s'étendent sur un intervalle de temps fini, de sorte que chaque fois que c'est possible, les clients devraient seulement restituer les composants de calendrier à partir du serveur en utilisant les rapports CALDAV:calendar-query, combinés avec un élément CALDAV:time-range, pour limiter l'ensemble de composants retournés à juste ceux nécessaires pour remplir la présentation actuelle.

 	8.2.1.2	Synchronisation par gamme de temps
Normalement dans un calendrier, les données historiques (événements, choses à faire, etc. qui se sont achevés avant la date actuelle) ne changent pas, bien qu'elles puissent être supprimées. Par suite, un client peut accélérer le processus de synchronisation en considérant seulement les données pour l'instant présent et le futur jusqu'à une limite raisonnable (par exemple, une semaine, un mois). Si l'utilisateur essaye alors d'examiner une portion du calendrier en dehors de la plage qui a été synchronisée, le client peut effectuer une autre opération de synchronisation sur le nouvel intervalle de temps examiné. Cette synchronisation "juste à temps" peut minimiser la bande passante pour les comportements courants d'interactions d'utilisateurs.

 	8.2.1.3	Processus de synchronisation
Si un client veut prendre en charge la synchronisation des données de calendrier, par opposition au téléchargement des données de calendrier chaque fois que nécessaire, le client doit mettre en antémémoire l'URI et l'Etag de ressource d'objet de calendrier, avec les données de calendrier réelles. Alors que l'URI reste statique pour la durée de vie de la ressource d'objet de calendrier, l'ETag va changer avec chaque changement successif de la ressource d'objet de calendrier. Donc, pour synchroniser une antémémoire locale avec le serveur, le client peut d'abord aller chercher les paires d'URI/ETag pour l'intervalle de temps considéré, et comparer ces résultats avec les données en antémémoire. Tout composant mis en antémémoire dont l'ETag diffère de celle du serveur doit être rafraîchi.

Afin de détecter correctement les changements entre les données de serveur et de client, le client va avoir besoin de garder en enregistrement des ressources d'objet Calendrier qui ont été créées, changées, ou supprimées depis la dernière opération de synchronisation afin qu'il puisse réconcilier ces changements avec les données du serveur.

Voici un exemple de la façon de le faire :

Le client produit une demande de rapport CALDAV:calendar-query pour la gamme de temps spécifique et demande seulement que la propriété DAV:getetag soit retournée :
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>

Le client utilise alors le résultat pour déterminer quelles ressources d'objet Calendrier ont changé, été créées, ou supprimées sur le serveur, et comment elles se rapportent aux ressources d'objet Calendrier mise en antémémoire locale qui peuvent avoir changé, été créées, ou supprimées. Si le client détermine qu'il y a des ressources d'objet Calendrier sur le serveur qui doivent être allées cherchées, le client produit une demande de rapport CALDAV:calendar-multiget pour aller chercher ses données de calendrier :

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>

 	8.2.2	Restreindre les propriétés retournées
Un client peut n'avoir pas besoin de toutes les propriétés de calendrier d'une ressource d'objet de calendrier quand il présente les informations à l'utilisateur. Comme certaines valeurs de propriété de calendrier peuvent être grandes (par exemple, ATTACH ou ATTENDEE) un client peut choisir de restreindre à celles qu'il sait qu'il va utiliser les propriétés de calendrier à retourner dans une demande de rapport de calendrier.

Cependant, si un client a besoin de faire un changement à une ressource d'objet de calendrier, il peut changer seulement la ressource d'objet de calendrier entière via une demande PUT. Il n'y a actuellement aucun moyen de faire un changement incrémentaire à un ensemble de propriétés de calendrier d'une ressource d'objet de calendrier. Par suite, le client va devoir obtenir la ressource entière d'objet de calendrier qui est changée.

 	8.3	Utilisation de verrouillage
Les verrous WebDAV peuvent être utilisés pour empêcher deux clients qui modifient la même resource d'écraser les changements l'un de l'autre (bien que ce problème puisse aussi être résolu en utilisant des ETag) ou de perdre du temps à faire des changements qui vont entrer en conflit avec un autre ensemble de changements. Dans un système de calendrier multi utilisateurs, un client de calendrier interactif pourrait verrouiller un événement alors que l'utilisateur édite l'événement, et déverrouiller l'événement quand l'utilisateur a fini ou annule. Les verrous peuvent aussi être utilisés pour empêcher les changements alors que les données sont en cours de réorganisation. Par exemple, un client de calendrier pourrait verrouiller deux collections de calendriers avant de déplacer un faisceau de ressources de calendrier de l'une à l'autre.

Les clients sont chargés de demander une période de temporisation de verrouillage qui soit appropriée au cas d'utilisation. Quand l'utilisateur décide explicitement de réserver une ressource et d'empêcher d'autres changements, une longue temporisation pourrait être appropriée, mais dans les cas où le client décide automatiquement de verrouiller la ressource, la temporisation devrait être courte (et le client peut toujours rafraîchir le verrouillage si il devrait l'être). Une courte temporisation de verrouillage signifie que si le client est incapable de supprimer le verrou, les autres utilisateurs du calendrier ne sont pas empêchés de faire des changements.

 	8.4	Trouver les calendriers
Souvent, un client de calendrier (ou agent) va découvrir la localisation d'un nouveau calendrier en étant provisionné directement avec l'URL. Par exemple, un utilisateur va taper la localisation de son propre calendrier dans les informations de configuration du client ou copier et coller un URL à partir d'un message élecronique dans l'application de calendrier. Le client a seulement besoin de confirmer que l'URL pointe sur une ressource qui est une collection de calendriers. Le client peut aussi être capable de feuilleter les collections WebDAV pour trouver les collections de calendriers.

Le choix des URL HTTP signifie que les ressources d'objet Calendrier sont rétro compatibles avec le logiciel existant, mais a l'inconvénient que le logiciel existant ne sait généralement pas regarder les réponses OPTIONS à cet URL pour déterminer ce qu'on peut en faire. C'est un peu une barrière pour l'utilisation de WebDAV ainsi que de CalDAV. La présente spécification n'offre pas d'autre moyen que de rendre ces informations disponibles dans la réponse OPTIONS si elles devaient être demandées.

Pour les cas d'utilisation de partage et de programmation de calendrier, on pourrait souhaiter trouver le calendrier qui appartient à un autre utilisateur. Si l'autre utilisateur a un calendrier dans le même répertoire, ce calendrier peut être trouvé en utilisant l'espace de noms principal requis par la prise en charge de WebDAV ACL. Pour les autres cas, les auteurs n'ont pas de solution universelle, mais les mises en œuvre peuvent considérer l'utilisation des normes vCard [RFC2426] ou LDAP [RFC4511] avec les attributs de calendrier [RFC2739].

Comme CalDAV exige des serveurs qu'ils prennent en charge WebDAV ACL [RFC3744], incluant les espaces de noms principaux, et avec l'ajout de la propriété CALDAV:calendar-home-set, il y a un couple d'options pour les clients CalDAV pour trouver leur propre calendrier ou celui d'un autre utilisateur.

Dans ce cas, un rapport DAV:principal-match est utilisé pout trouver une propriété désignée (CALDAV:calendar-home-set) sur l'URL principal de l'utilisateur actuel. En utilisant cela, un client WebDAV peut apprendre "qui je suis" et "où sont mes calendriers". Le corps de demande REPORT ressemble à ceci :

<?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>

Pour trouver les calendriers d'autres utilisateurs, le rapport DAV:principal-property-search peut être utilisé pour filtrer sur certaines propriétés et en retourner d'autres. Pour chercher un calendrier possédé par un utilisateur nommé "Laurie", le corps de demande REPORT ressemblerait à ceci :

<?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>

Le serveur effectue une recherche sensible à la casse ou non pour une chaîne correspondant à un sous ensemble de "Laurie au sein de la propriété DAV:displayname. Donc, le serveur pourrait retourner "Laurie Dusseault", "Laurier Desruisseaux", ou "Wilfrid Laurier" comme valeurs de DAV:displayname correspondantes, et retourner les calendriers pour chacune d'elles.

 	8.5	Mémorisation et utilisation de pièces jointes
Les clients CalDAV PEUVENT créer des rattachements dans les composants de calendrier soit comme en ligne, soit en externe. Ce paragraphe contient des lignes directrices pour créer et gérer les rattachements.

 	8.5.1	Pièces jointes en ligne
Les clients CalDAV DOIVENT prendre en charge les rattachements en ligne comme spécifié dans iCalendar [RFC2445]. Les serveurs CalDAV DOIVENT prendre en charge les rattachements en ligne, afin que les clients puissent compter être capables de créer des rattachements de cette façon. Par ailleurs, les rattachements en ligne ont des inconvénients :
o	Les serveurs PEUVENT imposer des limitations sur la taille des ressources d'objet Calendrier (c'est-à-dire, de refuser une demande PUT de très gros objets iCalendar). Les serveurs qui imposent de telles limitations DOIVENT utiliser la propriété CALDAV:max-resource-size sur une collection de calendriers pour informer le client de ce qu'est la limitation (voir au paragraphe 5.2.5).
o	Les serveurs PEUVENT imposer des limitations de quota de mémorisation aux collections de calendriers (voir la [RFC4331]).
o	Tout changement d'une ressource d'objet de calendrier contenant un rattachement en ligne exige que le rattachement en ligne entier soit téléchargé à nouveau.
o	Les clients qui synchronisent une ressource d'objet de calendrier changée doivent télécharger la ressource d'objet de calendrier entière, même si le rattachement est inchangé.

 	8.5.2	Pièces jointes externes
Les clients CalDAV DEVRAIENT prendre en charge le téléchargement de rattachements externes référencés par des schémas d'URI arbitraires, soit en les traitant directement, soit en passant l'URI de rattachement à une "application d'aide" convenable pour le traitement, si une telle application existe. Les clients CalDAV DOIVENT prendre en charge le téléchargement des rattachements externes référencés par les schéma d'URI "http" ou "https". Un rattachement externe pourrait être :
o	dans une collection dans la collection de calendriers contenant la ressource d'objet de calendrier ;
o	quelque part ailleurs dans le même répertoire qui héberge la collection de calendriers ; ou
o	sur un serveur HTTP ou FTP ailleurs.

Les serveurs CalDAV PEUVENT fournir la prise en charge de collections filles dans les collections de calendriers. Les serveurs CalDAV PEUVENT permettre à la méthode MKCOL de créer des collections filles dans des collections de calendriers. Les collections filles de collections de calendriers PEUVENT contenir tout type de ressource sauf des collections de calendriers qu'elles NE DOIVENT PAS contenir. Certains serveurs CalDAV ne vont pas permettre de collections filles dans les collections de calendriers, et il est possible sur de tels serveurs de découvrir d'autres localisations où les rattachements peuvent être mémorisés.

les clients sont entièrement responsables de la maintenance de la cohérence des références avec les composants de calendrier qui relient aux rattachements externes. Un client qui supprime un composant de calendrier avec un rattachement externe pourrait donc aussi supprimer le rattachement si c'est approprié ; cependant, ce caractère approprié peut être très difficile à déterminer. Un nouveau composant pourrait facilement faire référence à une ressource pré-existante de la Toile qui est destinée à avoir une existence indépendante de celle du composant de calendrier (le "rattachement" pourrait être une proposition majeure à discuter dans une réunion, par exemple). Des bonnes pratiques vont probablement émerger et devraient probablement être documentées, mais pour l'instant, les clients devraient être prudents avant de s'engager dans  des "nettoyages" aggressifs de rattachements externes. Un client pourrait impliquer l'utilisateur pour prendre des décisions sur la suppression de documents non référencés, ou un client pourrait être prudent en ne supprimant que les rattachements qu'il a créés.

Aussi, les clients sont responsables de la cohérence des permissions quand ils utilisent des rattachements externes. Une raison pour que les serveurs prennent en charge la mémorisation des rattachements au sein de collections filles de collections de calendriers est que l'héritage ACL pourrait rendre plus facile d'accorder les mêmes permissions aux rattachements que celles accordées à la collection de calendriers. Autrement, il peut être très difficile de garder les permissions synchronisées. Avec des rattachements mémorisés sur des répertoires séparés, il peut être impossible de garder la cohérence des permissions – les deux répertoires ne peuvent pas prendre en charge les mêmes permissions ou avoir le même ensemble de principaux. Certains systèmes ont utilisé des tickets ou autres mécanismes de contrôle d'accès anonymes pour fournir des solutions partiellement satisfaisantes à cette sorte de problèmes.

 	8.6	Mémorisation et utilisation des alarmes
Noter que toutes les collections de calendriers CalDAV (incluant celles que l'utilisateur pourrait traiter comme calendriers publics ou de groupe) peuvent contenir des informations d'alarme sur des événements et des choses à faire. les utilisateurs peuvent synchroniser un calendrier entre plusieurs appareils et décider d'avoir des alarmes exécutées sur un appareil différent de celui qui a créé l'alarme. Tous les types d'action d'alarme ne sont pas complètement interopérables (par exemple, ceux qui désignent un ficher sonore à exécuter).

Quans l'action est AUDIO et que le client est configuré à exécuter l'alarme, le client DEVRAIT exécuter le son suggéré si il est disponible ou exécuter un autre son, mais NE DEVRAIT PAS réécrire l'alarme juste pour remplacer le son suggéré par un son localement disponible.

Quand l'action est DISPLAY et que le client est configuré à exécuter l'alarme, le client DEVRAIT exécuter une alarme d'affichage en affichant conformément à la description suggérée ou un remplacement raisonnable, mais NE DEVRAIT PAS réécrire l'alarme à sa propre convenance.

Quand l'action est EMAIL et que le client est incapable d'envoyer un message électronique, il DEVRAIT ignorer l'alarme, mais il DOIT continuer de synchroniser l'alarme elle-même.

La présente spécification ne fait pas de recommandation sur l'exécution des alarmes du type PROCEDURE, sauf à noter qu'il est conseillé aux clients de veiller à éviter de créer des trous de sécurité en les exécutant.

Des informations d'alarme non interopérables (par exemple, si quelqu'un devait définir une couleur à utiliser dans une alarme d'affichage) devraient être mises dans des propriétés non standard à l'intérieur du composant VALARM afin de garder l'alarme de base utilisable sur tous les appareils.

Les clients qui permettent des changements aux ressources d'objet Calendrier DOIVENT synchroniser les données d'alarme qui existent déjà dans les ressources.

Les clients PEUVENT exécuter des alarmes qui sont téléchargées de cette façon, éventuellement sur la base des préférences de l'utilisateur. Si un client fait seulement des opérations de lecture sur un calendrier et qu'il n'y a pas de risque de perdre les informations d'alarme, alors le client PEUT éliminer les informations d'alarme.

La présente spécification ne tente pas de fournir des alarmes multi utilisateurs sur des calendriers de groupe ou de trouver à qui une alarme est destinée. Traiter ces questions pourrait exiger des extensions à iCalendar ; par exemple, pour mémoriser des alarmes par utilisateur, ou pour indiquer à quel utilisateur une VALARM est destinée. En même temps, les clients pourraient maximiser l'interopérabilité en ne téléchargeant généralement pas les informations d'alarme à des calendriers publics, de groupe, ou de ressources.

 	9.	Définitions d'éléments XML
 	9.1	Élément XML CALDAV:calendar
Nom : calendar
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie le type de ressource d'une collection de calendriers.
Description : voir le paragraphe 4.2.
Définition : <!ELEMENT calendar EMPTY>

 	9.2	Élément XML CALDAV:mkcalendar
Nom : mkcalendar
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie une demande qui inclut les valeurs de propriété WebDAV à établir pour une ressource de collection de calendriers quand elle est créée.
Description : voir le paragraphe 5.3.1.
Définition : <!ELEMENT mkcalendar (DAV:set)>

 	9.3	Élément XML CALDAV:mkcalendar-response
Nom : mkcalendar-response
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie un corps de réponse pour une demande MKCALENDAR réussie.
Description : voir le paragraphe 5.3.1.
Définition : <!ELEMENT mkcalendar-response ANY>

 	9.4	Élément XML CALDAV:supported-collation
Nom : supported-collation
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Identifie une seule collation via son identifiant de collation, comme défini par la [RFC4790].
Description : l'élément CALDAV:supported-collation contient le texte d'un identifiant de collation, comme décrit au paragraphe 7.5.1.

Définition : <!ELEMENT supported-collation (#PCDATA)>
Valeur de PCDATA : identifiant de collation

 	9.5	Élément XML CALDAV:calendar-query
Nom : calendar-query
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : définit un rapport pour interroger les ressources d'objet Calendrier.
Description : voir le paragraphe 7.8.

Définition : <!ELEMENT calendar-query ((DAV:allprop | DAV:propname | DAV:prop)?, filter, timezone?)>

 	9.6	Élément XML CALDAV:calendar-data
Nom : calendar-data
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie un de ce qui suit :
1.	Un type de support pris en charge pour les ressources d'objet Calendrier quand incorporé dans la propriété CALDAV;supported-calendar-data.
2.	Les parties d'une ressource d'objet de calendrier qui devraient être retournées par un rapport de calendrier.
3.	Le contenu d'une ressource d'objet de calendrier dans une réponse à un rapport de calendrer.

Description : Quand incorporé dans la propriété CALDAV;supported-calendar-data, l'élément XMLCALDAV:calendar-data spécifie un type de support pris en charge par le serveur CalDAV pour les ressources d'objet Calendrier. Quand utilisé dans une demande REPORT de calendrier, l'élément XML CALDAV:calendar-data spécifie quelles parties des ressources d'objet Calendrier doivent être retournées dans la réponse. Si l'élément XML CALDAV:calendar-data ne contient aucun élément CALDAV:comp, les ressources d'objet Calendrier vont être retournées entièrement. Finalement, quand utilisé dans une réponse de REPORT de calendrier, l'élément XML CALDAV:calendar-data spécifie le contenu d'une ressource d'objet de calendrier. Étant donné que les analyseurs XML normalisent les deux caractères de la séquence CRLF (décimal 13 US-ASCII et décimal 10 US-ASCII) en un seul caractère LF (décimal 10 US-ASCII) le caractère CR (décimal US-ASCII 13) PEUT être omis dans les ressources d'objet Calendrier spécifiées dans l'élément XML CALDAV:calendar-data. De plus, les ressources d'objet Calendrier spécifiées dans l'élément XML CALDAV:calendar-data PEUVENT être invalides selon leur spécification de type de support si l'élément XML CALDAV:calendar-data qui fait partie de la demande REPORT de calendrier ne spécifiait pas de propriété exigée (par exemple, UID, DTSTAMP, etc.) ou spécifiait un élément XML CALDAV:prop avec l'attribut "novalue" réglé à "oui".

Note : L'élément XML CALDAV:calendar-data est spécifié dans une demande et les réponses à l'intérieur de l'élément XML DAV:prop comme si il était une propriété WebDAV. Cependant, l'élément XML CALDAV:calendar-data n'est pas une propriété WebDAV et, à ce titre, n'est pas retourné dans les réponses PROPFIND, ni utilisé dans la demande PROPPATCH.

Note : Les données iCalendar incorporées au sein de l'élément XML CALDAV:calendar-data DOIVENT suivre le codage standard de données de caractère XML, incluant l'utilisation du codage d'entité &lt;, &gt;, &amp; etc. ou l'utilisation d'une construction <![CDATA[ ... ]]>. Dans ce dernier cas, les données iCalendar ne peuvent pas contenir la séquence de caractères "]]>", qui est le délimiteur de fin pour la section CDATA.

Définition : 
<!ELEMENT calendar-data EMPTY>
quand incorporé dans la propriété CALDAV;supported-calendar-data pour spécifier un type de support pris en charge pour les ressources d'objet Calendrier ;

<!ELEMENT calendar-data (comp?, (expand | limit-recurrence-set)?, limit-freebusy-set?)>
quand incorporé dans l'élément XML DAV:prop dans une demande REPORT de calendrier pour spécifier quelles parties des ressources d'objet Calendrier devraient être retournées dans la réponse ;

<!ELEMENT calendar-data (#PCDATA)>
Valeur de PCDATA : objet iCalendar
quand incorporé dans l'élément XML DAV:prop dans une réponse REPORT de calendrier pour spécifier le contenu d'une ressource d'objet de calendrier retournée.

<!ATTLIST calendar-data content-type CDATA "text/calendar" version CDATA "2.0">
Valeur de type de contenu : valeur MIME de version de type de support : des attributs de chaîne de version peuvent être utilisés sur les trois variantes de l'élément XML CALDAV:calendar-data.

 	9.6.1	Élément XML CALDAV:comp
Nom : comp
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Définit quels types de composant retourner.
Description : la valeur de nom est un nom de composant de calendrier (par exemple, VEVENT).

Définition :
<!ELEMENT comp ((allprop | prop*), (allcomp | comp*))>
<!ATTLIST comp name CDATA #REQUIRED>
Valeur de nom : un nom de composant de calendrier.

Note :Les éléments CALDAV:prop et CALDAV:allprop ont le même nom que les éléments DAV:prop et DAV:allprop définis dans la [RFC2518]. Cependant, les éléments CALDAV:prop et CALDAV:allprop sont définis dans l'espace de noms "urn:ietf:params:xml:ns:caldav" au lieu de l'espace de noms "DAV:".

 	9.6.2	Élément XML CALDAV:allcomp
Nom : allcomp
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie que tous les composants doivent être retournés.
Description : l'élément XML CALDAV:allcomp peut être utilisé quand le client veut que tous les types de composants soient retournés par une demande REPORT de calendrier.

Définition :<!ELEMENT allcomp EMPTY>

 	9.6.3	Élément XML CALDAV:allprop
Nom : allprop
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie que toutes les propriétés doivent être retournées.
Description : L'élément XML CALDAV:allprop peut être utilisé quand le client veut toutes les propriétés des composants retournés par une demande de rapport de calendrier.

Définition : <!ELEMENT allprop EMPTY>

Note : L'élément CALDAV:allprop a le même nom que l'élément DAV:allprop défini dans la [RFC2518]. Cependant, l'élément CALDAV:allprop est défini dans l'espace de noms "urn:ietf:params:xml:ns:caldav" au lieu de l'espace de noms "DAV:".

 	9.6.4	Élément XML CALDAV:prop
Nom : prop
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Définit quelles propriétés retourner dans la réponse.
Description : L'attribut "name" spécifie le nom de la propriété de calendrier à retourner (par exemple, ATTENDEE). L'attribut "novalue" peut être utilisé par les clients pour demander que la valeur réelle de la propriété ne soit pas retournée (si l'attribut "novalue" est réglé à "oui"). Dans ce cas, le serveur va retourner juste le nom de la propriété iCalendar et tous les paramètres iCalendar et un ":" en queue sans les données de valeur suivantes.

Définition :
<!ELEMENT prop EMPTY>
<!ATTLIST prop name CDATA #REQUIRED novalue (yes | no) "no">
Valeur de nom : une valeur novalue de nom de propriété de calendrier : "oui" ou "non"

Note : L'élément CALDAV:prop a le même nom que l'élément DAV:prop défini dans la [RFC2518]. Cependant, l'élément CALDAV:prop est défini dans l'espace de noms "urn:ietf:params:xml:ns:caldav" au lieu de l'espace de noms "DAV:".

 	9.6.5	Élément XML CALDAV:expand
Nom : expand
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Force le serveur à étendre les composants récurrents en instances de récurrence individuelles.
Description : L'élément XML CALDAV:expand spécifie que pour une certaine demande REPORT de calendrier, le serveur DOIT étendre l'ensemble de récurrence en composants de calendrier qui définissent exactement une instance de récurrence, et DOIT retourner seulement ceux dont l'heure programmée intersecte une gamme de temps spécifiée. L'attribut "start" spécifie le début inclus de la gamme de temps, et l'attribut "end" spécifie la fin non incluse de la gamme de temps. Les deux attributs sont spécifiés comme des dates avec valeur de temps UTC. La valeur de l'attribut "end" DOIT être supérieure à la valeur de l'attribut "start". Le serveur DOIT utiliser la même logique que défini pour CALDAV:time-range pour déterminer si une instance de récurrence intersecte la gamme de temps spécifiée. Les composants récurrents, autres que l'instance initiale, DOIVENT inclure une propriété RECURRENCE-ID indiquant à quelle instance ils se rèferent. Les composants de calendrier retournés NE DOIVENT PAS utiliser de propriétés de récurrence (c'est-à-dire, EXDATE, EXRULE, RDATE, et RRULE) et NE DOIVENT PAS avoir de référence à, ou inclure, des composants VTIMEZONE. La date et l'heure locale avec référence aux informations de zone horaire DOIVENT être converties en date avec temps UTC.

Définition :
<!ELEMENT expand EMPTY>
<!ATTLIST expand start CDATA #REQUIRED
                                  end CDATA #REQUIRED>
valeur de début : "date avec temps UTC" iCalendar
valeur de fin : "date avec temps UTC" iCalendar

 	9.6.6	Élément XML CALDAV:limit-recurrence-set
Nom : limit-recurrence-set
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie une gamme de temps pour limiter l'ensemble de "composants outrepassés" retourné par le serveur.
Description : L'élément XML CALDAV:limit-recurrence-set spécifie que pour une demande REPORT de calendrier donnée, le serveur DOIT retourner, en plus du "composant maître", seulement les "composants outrepassés" qui impactent une gamme de temps spécifiée. Un composant outrepassé impacte une gamme de temps si ses heures de début et de fin actuelles chevauchent la gamme de temps, ou si les heures originales de début et de fin – celles qui auraient été utilisées si l'instance n'avait pas été outrepassée – chevauchent la gamme de temps. L'attribut "start" spécifie le début inclusif de la gamme de temps, et l'attribut "end" spécifie la fin non inclusive de la gamme de temps. Les deux attributs sont spécifiés comme valeur de date avec temps UTC. La valeur de l'attribut "end" DOIT être supérieure à celle de l'attribut "start". Le serveur DOIT utiliser la même logique que définie pour CALDAV:time-range pour déterminer si l'heure courante ou programmée à l'origine d'une instance de réccurence "outrepassée" intersecte la gamme de temps spécifiée. Les composants outrepassés qui ont un paramètre RANGE sur leur propriété RECURRENCE-ID peuvent spécifier une ou plusieurs instances dans l'ensemble de récurrence, et certaines de ces instances peut tomber dans la gamme de temps spécifiée ou peuvent avoir été à l'origine dans la gamme de temps spécifiée avant d'être outrepassées. Si c'est le cas, le composant outrepassé DOIT être inclus dans le résultat, car il a un impact direct sur l'interprétation des instances au sein de la gamme de temps spécifiée.

Définition :
<!ELEMENT limit-recurrence-set EMPTY>
<!ATTLIST limit-recurrence-set start CDATA #REQUIRED
                                                      end CDATA #REQUIRED>
Valeur de début : "date avec temps UTC" iCalendar
Valeur de fin : "date avec temps UTC" iCalendar

 	9.6.7	Élément XML CALDAV:limit-freebusy-set
Nom : limit-freebusy-set
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie une gamme de temps pour limiter l'ensemble de valeurs de FREEBUSY retournées par le serveur.
Description : L'élément XML CALDAV:limit-freebusy-set spécifie que pour une certaine demande REPORT de calendrier, le serveur DOIT seulement retourner les valeurs de propriété FREEBUSY de composant VFREEBUSYqui intersectent une gamme de temps spécifiée. L'attribut "start" spécifie le début inclusif de la gamme de temps, et l'attribut "end" spécifie la fin non incluse de la gamme de temps. Les deux attributs sont spécifiés comme valeur de "date avec temps UTC". La valeur de l'attribut "end" DOIT être supérieure à la valeur de l'attribut "start". Le serveur DOIT utiliser la même logique que définie pour CALDAV:time-range pour déterminer si une valeur de propriété FREEBUSY intersecte la gamme de temps spécifiée.

Définition :
<!ELEMENT limit-freebusy-set EMPTY>
<!ATTLIST limit-freebusy-set start CDATA #REQUIRED
                                                   end CDATA #REQUIRED>
Valeur de début : "date avec temps UTC" iCalendar
Valeur de fin : "date avec temps UTC" iCalendar

 	9.7	Élément XML CALDAV:filter
Nom : filter
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie un filtre pour limiter l'ensemble de composants de calendrier retourné par le serveur.
Description : L'élément XML CALDAV:filter spécifie le filtre de recherche utilisé pour limiter les composants de calendrier retournés par une demande REPORT de calendrier.

Définition : <!ELEMENT filter (comp-filter)>

 	9.7.1	Élément XML CALDAV:comp-filter
Nom : comp-filter
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie les critères de chercher sur les composants de calendrier.
Description : L'élément XML CALDAV:comp-filter spécifie une interrogation ciblée sur l'objet de calendrier (c'est-à-dire, VCALENDAR) ou sur un type de composant de calendrier spécifique (par exemple, VEVENT). La portée de l'élément XML CALDAV:comp-filter est l'objet de calendrier quand il est utilisé comme fils de l'élément XML CALDAV:filter.  La portée de l'élément XML CALDAV:comp-filter est le composant de calendrier incluant quand utilisé comme fils d'un autre élément XML CALDAV:comp-filter. Un CALDAV:comp-filter est dit correspondre si :
*	L'élément XML CALDAV:comp-filter est vide et le type d''object ou de composant de calendrier spécifié par l'attribut "name" existe dans la portée courante ;
ou :
*	L'élément XML CALDAV:comp-filter contient un élément XML CALDAV:is-not-defined et le type d'objet de calendrier ou de composant de calendrier spécifié par l'attribut "name" n'existe pas dans la portée actuelle ;
ou :
*	L'élément XML CALDAV:comp-filter contient un élément XML CALDAV:time-range et au moins une instance de récurrence dans le composant de calendrier ciblé est programmée pour chevaucher la gamme de temps spécifiée, et si tous les éléments XML fils CALDAV:prop-filter et CALDAV:comp-filter spécifiés correspondent aussi au composant de calendrier ciblé ;
ou :
* 	L'élément XML CALDAV:comp-filter contient seulement des éléments XML fils CALDAV:prop-filter et CALDAV:comp-filter qui correspondent tous au composant de calendrier ciblé.

Définition :
<!ELEMENT comp-filter (is-not-défined | (time-range?, prop-filter*, comp-filter*))>
<!ATTLIST comp-filter name CDATA #REQUIRED>
Valeur de nom : un type ou composant d'object de calendrier (par exemple, VEVENT)

 	9.7.2.	Élément XML CALDAV:prop-filter
Nom : prop-filter
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie les critères de recherche sur des propriétés de calendrier.
Description : L'élément XML CALDAV:prop-filter spécifie une interrogation ciblée sur une propriété de clendrier spécifique (par exemple, CATEGORIES) dans la portée du composant de calendrier enclosant. Une propriété de clendrier est dite correspondre à un CALDAV:prop-filter si :
*	L'élément XML CALDAV:prop-filter est vide et si une propriété du type spécifié par l'attribut "name" existe dans le composant de calendrier enclosant ;
ou :
*	L'élément XML CALDAV:prop-filter contient un élément XML CALDAV:is-not-defined et aucune propriété du type spécifié par l'attribut "name" n'existe dans le composant de calendrier enclosant ;
ou :
*	L'élément XML CALDAV:prop-filter contient un élément XML CALDAV:time-range et la valeur de propriété chevauche la gamme de temps spécifiée, et tous les éléments fils XML CALDAV:param-filter correspondent aussi à la propriété ciblée ;
ou :
*	L'élément XML CALDAV:prop-filter contient un élément XML CALDAV:text-match et la valeur de la propriété y correspond, et tous les éléments fils XML CALDAV:param-filter correspondent aussi à la propriété ciblée.

Définition :
<!ELEMENT prop-filter (is-not-defined | ((time-range | text-match)?, param-filter*))>
<!ATTLIST prop-filter name CDATA #REQUIRED>
Valeur de nom : un nom de propriété de calendrier (par exemple, ATTENDEE)

 	9.7.3	Élément XML CALDAV:param-filter
Nom : param-filter
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Limite la recherche à des valeurs de paramètre spécifiques.
Description : L'élément XML CALDAV:param-filter spécifie une interrogation ciblée sur un paramètre spécifique de propriété de calendrier (par exemple, PARTSTAT) dans la portée de la propriété de calendrier sur laquelle il est défini. Un paramètre de propriété de calendrier est dit correspondre à un CALDAV:param-filter si :
*	L'élément XML CALDAV:param-filter est vide et un paramètre du type spécifié par l'attribut "name" existe sur la propriété de calendrier examinée ;
ou :
* 	L'élément XML CALDAV:param-filter contient un élément XML CALDAV:is-not-defined et aucun paramètre du type spécifié par l'attribut "name" n'existe sur la propriété de calendrier examinée.

Définition :
<!ELEMENT param-filter (is-not-defined | text-match?)>
<!ATTLIST param-filter name CDATA #REQUIRED>
Valeur de nom : nom de paramètre de propriété (par exemple, PARTSTAT)

 	9.7.4	Élément XML CALDAV:is-not-defined
Nom : is-not-defined
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie qu'une correspondance devrait se produire si le composant, propriété, ou paramètre enclosant n'existe pas.
Description : L'élément XML CALDAV:is-not-defined spécifie qu'une correspondance se produit si le composant, propriété, ou valeur de paramètre enclosant spécifié dans une demande REPORT de calendrier n'existe pas dans les données de calendrier en essai.

Définition : <!ELEMENT is-not-defined EMPTY>

 	9.7.5	Élément XML CALDAV:text-match
Nom : text-match
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie une correspondance de sous chaîne sur une propriété ou valeur de paramètre.
Description : L'élément XML CALDAV:text-match spécifie un texte utilisé pour une correspondance de sous chaîne par rapport à la propriété ou valeur de paramètre spécifiée dans une demande REPORT de calendrier. L'attribut "collation" est utilisé pour choisir la collation que le serveur DOIT utiliser pour la confrontation de chaîne de caractères. En l'absence de cet attribut, le serveur DOIT utiliser la collation "i;ascii-casemap". L'attribut "negate-condition" est utilisé pour indiquer que cet essai retourne une correspondance si le texte correspond quand la valeur d'attribut est réglée à "non", ou retourne une correspondance si le texte ne correspond pas, si la valeur d'attribut est réglée à "oui". Par exemple, cela peut être utilisé pour confronter les composants avec une propriété STATUS non réglée à CANCELLED.

Définition :
<!ELEMENT text-match (#PCDATA)>
Valeur de PCDATA : chaîne
<!ATTLIST text-match collation CDATA "i;ascii-casemap" negate-condition (oui | non) "non">

 	9.8	Élément XML CALDAV:timezone
Nom : timezone
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie le composant zone horaire à utiliser quand on détermine le résultat d'un rapport.
Description : L'élément XML CALDAV:timezone  spécifie que pour une certaine demande de rapport pour un calendrier donné, le serveur DOIT s'appuyer sur le composant VTIMEZONE spécifié au lieu de la propriété CALDAV:calendar-timezone de la collection de calendriers, dans laquelle la ressource d'objet de calendrier est contenue pour résoudre les valeurs "date" et "date avec heure locale" (c'est-à-dire, l'heure flottante) en valeurs "date avec heure UTC". Le serveur va exiger cette information pour déterminer si un composant de calendrier programmé avec des valeurs "date" ou "date avec heure locale" intersecte une CALDAV:time-range spécifiée dans un rapport CALDAV:calendar-query.

Note : Les données iCalendar incorporées au sein de l'élément XML CALDAV:timezone DOIVENT suivre les règles standard de codage de données de caractère XML, incluant l'utilisation du codage d'entité &lt;, &gt;, &amp; etc. ou l'utilisation de la construction <![CDATA[ ... ]]>. Dans ce dernier cas, les données iCalendar ne peuvent pas contenir la séquence de caractères "]]>", qui est le délimiteur de fin de la section CDATA.

Définition :
<!ELEMENT timezone (#PCDATA)>
Valeur de PCDATA : un objet iCalendar avec exactement une VTIMEZONE

 	9.9	Élément XML CALDAV:time-range
Nom : time-range
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : Spécifie une gamme de temps pour limiter l'ensemble de composants de calendrier retourné par le serveur.
Description : L'élément XML CALDAV:time-range spécifie que pour une certaine demande REPORT de calendrier, le serveur DOIT retourner seulement les ressources d'objet Calendrier qui, selon le contexte, ont un composant ou propriété dont la valeur recoupe une gamme de temps spécifiée. L'attribut "start" spécifie le début inclus de la gamme de temps, et l'attribut "end" spécifie la fin non incluse de la gamme de temps. Les deux attributs DOIVENT être spécifiés comme valeur de "date avec temps UTC". Des gammes de temps ouvertes à un bout peuvent être spécifiées en incluant un seul attribut ; cependant, au moins un attribut DOIT toujours être présent dans l'élément CALDAV:time-range. Si l'attribut "start" ou "end" n'est pas spécifié dans l'élément XML CALDAV:time-range, on suppose comme valeur respectivement "-infini" et "+infini". Si les deux "start" et "end" sont présents, la valeur de l'attribut "end" DOIT être supérieure à la valeur de l'attribut "start". Les essais de plage horaire DOIVENT considérer chaque instance de récurrence lors d'essais des conditions de gamme de temps ; si une instance correspond, alors l'essai retourne vrai. L'essai des instances de récurrence exige que le serveur déduise une valeur effective pour les propriétés DTSTART, DTEND, DURATION, et DUE pour une instance sur la base des schémas de récurrence et de tous les outrepassements.  Un composant VEVENT chevauche une certaine gamme de temps si la condition pour l'état de composant correspondant spécifié dans le tableau ci-dessous est satisfaite. Noter que, comme spécifié dans la [RFC2445], la propriété DTSTART est EXIGÉE dans le component VEVENT. Les conditions dépendent de la présence des propriétés DTEND et DURATION dans le composant VEVENT. De plus, la valeur de la propriété DTEND DOIT être plus tard dans le temps que la valeur de la propriété DTSTART. La durée d'un composant VEVENT sans propriétés DTEND et DURATION est 1 jour (+P1D) quand DTSTART est une valeur de DATE, et 0 seconde quand DTSTART est une valeur DATE-TIME.

+----------------------------------------------------------------+
| VEVENT a t-il la propriété DTEND ?                             |
|   +------------------------------------------------------------+
|   | VEVENT a t-il la propriété DURATION ?                      |
|   |   +--------------------------------------------------------+
|   |   |La valeur de DURATION est elle supérieure à 0 seconde ? |
|   |   |   +----------------------------------------------------+
|   |   |   |La propriété DTSTART est elle une valeur DATE-TIME ?|
|   |   |   |   +------------------------------------------------+
|   |   |   |   | Condition à évaluer                            |
+---+---+---+---+------------------------------------------------+
| O | N | N | * | (début < DTEND ET fin > DTSTART)               |
+---+---+---+---+------------------------------------------------+
| N | O | O | * | (début < DTSTART+DURATION ET fin > DTSTART)    |
|   |   +---+---+------------------------------------------------+
|   |   | N | * | (début ≤ DTSTART ET fin > DTSTART)             |
+---+---+---+---+------------------------------------------------+
| N | N | N | O | (début ≤ DTSTART ET fin > DTSTART)             |
+---+---+---+---+------------------------------------------------+
| N | N | N | N | (début < DTSTART+P1D ET fin > DTSTART)         |
+---+---+---+---+------------------------------------------------+

Un composant VTODO est dit chevaucher une certaine gamme de temps si la condition pour l'état de composant correspondant spécifié dans le tableaui ci-dessous est satisfaite. Les conditions dépendent de la présence des propriétés DTSTART, DURATION, DUE, COMPLETED, et CREATED dans le composant VTODO. Noter que, comme spécifié dans la [RFC2445], la valeur DUE DOIT être une valeur DATE-TIME égale ou postérieure à la valeur de DTSTART si elle est spécifiée.

+-------------------------------------------------------------------+
| VTODO a t-il la propriété DTSTART ?                               |
|   +---------------------------------------------------------------+
|   |   VTODO a t-il la propriété DURATION ?                        |
|   |   +-----------------------------------------------------------+
|   |   | VTODO a t-il la propriété DUE ?                           |
|   |   |   +-------------------------------------------------------+
|   |   |   | VTODO a t-il la propriété COMPLETED ?                 |
|   |   |   |   +---------------------------------------------------+
|   |   |   |   | VTODO a t-il la propriété CREATED ?               |
|   |   |   |   |   +-----------------------------------------------+
|   |   |   |   |   | Condition à évaluer                           |
+---+---+---+---+---+-----------------------------------------------+
| O | O | N | * | * | (début  ≤ DTSTART+DURATION) ET                |
|   |   |   |   |   | ((fin   >  DTSTART)  OU                       |
|   |   |   |   |   |  (fin   ≥ DTSTART+DURATION))                  |
+---+---+---+---+---+-----------------------------------------------+
| O | N | O | * | * | ((début <  DUE)      OU  (début ≤ DTSTART))   |
|   |   |   |   |   | ET                                            |
|   |   |   |   |   | ((fin   >  DTSTART)  OU  (fin   ≥ DUE))       |
+---+---+---+---+---+-----------------------------------------------+
| O | N | N | * | * | (début  ≤ DTSTART)  ET (fin >  DTSTART)       |
+---+---+---+---+---+-----------------------------------------------+
| N | N | O | * | * | (début  <  DUE)     ET fin ≥ DUE)             |
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | O | O | ((début ≤ CREATED)  OU  (début ≤ COMPLETED))  |
|   |   |   |   |   | ET                                            |
|   |   |   |   |   | ((fin   ≥ CREATED)  OU  (fin   ≥ COMPLETED))  |
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | O | N | (début  ≤ COMPLETED) ET (fin  ≥ COMPLETED)    |
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | N | O | (fin    >  CREATED)                           |
+---+---+---+---+---+-----------------------------------------------+
| N | N | N | N | N | VRAI                                          |
+---+---+---+---+---+-----------------------------------------------+

Un composant VJOURNAL chevauche une certaine gamme de temps si la condition pour l'état de composant correspondant spécifié dans le tableau ci-dessous est satisfaite. Les conditions dépendent de la présence de la propriété DTSTART dans le composant VJOURNAL et de si le DTSTART est une valeur de DATE-TIME ou de DATE. La "durée" effective d'un composant VJOURNAL est 1 jour (+P1D) quand le DTSTART est une valeur de DATE, et 0 seconde quand le DTSTART est une valeur de DATE-TIME.

+----------------------------------------------------------+
| VJOURNAL a t-il la propriété DTSTART ?                   |
|   +------------------------------------------------------+
|   | La propriété DTSTART est elle une valeur DATE-TIME ? |
|   |   +--------------------------------------------------+
|   |   | Condition à évaluer                              |
+---+---+--------------------------------------------------+
| O | O | (début ≤ DTSTART)     ET  (fin > DTSTART)        |
+---+---+--------------------------------------------------+
| O | N | (début < DTSTART+P1D) ET (fin > DTSTART)         |
+---+---+--------------------------------------------------+
| N | * | FAUX                                             |
+---+---+--------------------------------------------------+

Un composant VFREEBUSY chevauche une certaine gamme de temps si la condition pour l'état de composant correspondant spécifié dans le tableau ci-dessous est satisfaite. La condition dépend de la présence dans le composant VFREEBUSY des propriétés DTSTART et DTEND, et de toutes propriétés FREEBUSY en l'absence de DTSTART et DTEND. Toute propriété DURATION est ignorée, car elle a une signification spéciale quand utilisée dans un composant VFREEBUSY.

Quand seules des propriétés FREEBUSY sont utilisées, chaque période dans chaque propriété FREEBUSY est comparée à la gamme de temps, sans considération du type d'informations free/busy (libre, occupé, tentative d'occupation, occupé-indisponible) représenté par la propriété.

+--------------------------------------------------------+
| VFREEBUSY a t-il les deux propriétés DTSTART et DTEND ?|
|   +----------------------------------------------------+
|   | VFREEBUSY a t-il la propriété FREEBUSY ?           |
|   |   +------------------------------------------------+
|   |   | Condition à évaluer                            |
+---+---+------------------------------------------------+
| O | * | (début ≤ DTEND) ET (fin > DTSTART)             |
+---+---+------------------------------------------------+
| N | O | (début < freebusy-period-end) ET               |
|   |   | (fin   >  freebusy-period-start)               |
+---+---+------------------------------------------------+
| N | N | FAUX                                           |
+---+---+------------------------------------------------+

Un composant VALARM est dit chevaucher une certaine gamme de temps si la condition suivante tient :

(début ≤ heure de déclenchement) ET (fin > heure de déclenchement)

Un composant VALARM peut être défini de telle façon qu'il se déclenche de façon répétée. Un tel composant VALARM est dit chevaucher une certaine gamme de temps si au moins un de ses déclenchements chevauche la gamme de temps.

Les propriétés de calendrier COMPLETED, CREATED, DTEND, DTSTAMP, DTSTART, DUE, et LAST-MODIFIED chevauchent une certaine gamme de temps si la condition suivante tient :

(début ≤ date-heure) ET (fin > date-heure)

Noter que si DTEND n'est pas présent dans un VEVENT, mais si DURATION l'est, alors l'essai devrait plutôt opérer sur le  DTEND "effectif", c'est-à-dire, DTSTART+DURATION. De même, si DUE n'est pas présent dans un VTODO, mais si DTSTART et DURATION le sont, alors l'essai devrait plutôt opérer sur le DUE "effectif", c'est-à-dire, DTSTART+DURATION.

La sémantique de CALDAV:time-range n'est pas définie pour d'autres composants et propriétés de calendrier.

Définition :
<!ELEMENT time-range EMPTY>
<!ATTLIST time-range start CDATA #IMPLIED
                                        end CDATA #IMPLIED>
Valeur de début : une "date avec temps UTC" iCalendar.
Valeur de fin : une "date avec temps UTC" iCalendar.

 	9.10	Élément XML CALDAV:calendar-multiget
Nom : calendar-multiget
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : rapport CalDAV utilisé pour restituer les ressources spécifiques d'objet Calendrier.
Description : voir le paragraphe 7.9.

Définition :
<!ELEMENT calendar-multiget ((DAV:allprop | DAV:propname | DAV:prop)?, DAV:href+)>

 	9.11	Élément XML CALDAV:free-busy-query
Nom : free-busy-query
Espace de noms : urn:ietf:params:xml:ns:caldav
Objet : rapport CalDAV utilisé pour générer un VFREEBUSY pour déterminer le temps d'occupation sur une gamme de temps spécifique.
Description : voir le paragraphe 7.10.

Définition : <!ELEMENT free-busy-query (time-range)>

 	10.	Considérations d'internationalisation

CalDAV permet que des chaînes internationalisées soient mémorisées et restituées pour la description de collections de calendriers (voir au paragraphe 5.2.1).

Le rapport CALDAV:calendar-query (Section 7.8) inclut une option de recherche de texte contrôlée par l'élément CALDAV:text-match, et les détails du traitement de caractère sont couverts dans la description de cet élément (voir au paragraphe 9.7.5).

 	11.	Considérations sur la sécurité

Les transactions de protocole HTTP sont envoyées en clair sur le réseau sauf si la protection contre l'espionnage est négociée. Cela peut être accompli par l'utilisation de TLS, comme défini dans la [RFC2818]. En particulier, l'authentification HTTP de base NE DOIT PAS être utilisée sauf si TLS est activé.

Les serveurs DOIVENT prendre des précautions adéquates pour s'assurer que des clients malveillants ne peuvent pas consommer d'excessives ressources de serveur (CPU, mémoire, disque, etc.) par des rapports conçus avec soin. Par exemple, un client pourrait télécharger un événement avec une règle de récurrence qui spécifie un événement récurrent survenant chaque seconde pour les 100 années à venir, ce qui résulterait en approximativement 3 x 10^9 instances ! Un rapport qui demande des récurrences à étendre sur cette gamme de temps constituerait probablement une attaque de déni de service sur le serveur.

Quand ils créent de nouvelles ressources (incluant des collections de calendriers) les clients DOIVENT s'assurer que le nom de la ressource (le dernier segment de chemin de l'URI de la ressource) alloué à la nouvelle ressource n'expose aucune donnée provenant de l'intérieur de la ressourc iCalendar elle-même ou des informations sur la nature d'une collection de calendriers. Ceci est nécessaire pour s'assurer que la présence d'un composant spécifique iCalendar ou la nature des composants dans une collection ne peut pas être déduite sur la base du nom d'une ressource.

Quand on déroule des informations d'occupation/liberté, plus d'informations sur les événements d'un utilisateur sont exposées si les périodes occupées se chevauchent ou sont adjacentes (cela dit au client qui demande les informations d'occupation/liberté que le propriétaire du calendrier a au moins deux événements, plutôt que de savoir seulement que le propriétaire du calendrier a un ou plusieurs événements durant la période occupée). Donc, une approche prudente de la confidentialité des données de calendrier serait que les serveurs regroupent toujours de telles périodes d'occupation quand elles sont du même type.

Les alarmes de procédure sont un risque de sécurité connu à traiter par les clients ou serveurs, en particulier quand l'alarme a été créée par un autre agent. Les clients et serveurs ne sont pas obligés d'exécuter de telles alarmes de procédure.

Les considérations sur la sécurité décrites dans iCalendar [RFC2445] et iTIP [RFC2446] sont aussi applicables à CalDAV.

Au delà de cela, CalDAV ne soulève pas de problème de sécurité qui ne soit déjà présent dans HTTP [RFC2616] et WebDAV [RFC2518], [RFC3253], [RFC3744].

 	12.	Considerations relatives à l'IANA

Le présent document utilise un nouvel URN pour identifier un nouvel espace de noms XML. L'URN se conforme à un mécanisme de registre décrit dans la [RFC3688].

 	12.1	Enregistrement d'espace de noms
Demande d'enregistrement pour l'espace de noms CalDAV :

URI : urn:ietf:params:xml:ns:caldav
Contact d'enregistrement : voir la Section "Adresse des auteurs" du présent document.

XML : aucun. Les URI d'espace de noms ne représentent pas une spécification XML.

 	13.	Remerciements

Les auteurs tiennent à remercier les personnes suivantes qui ont contribué par leurs idées et par la prise en charge de la rédaction de la présente spécification : Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, André Courtemanche, Mike Douglass, Ted Hardie, Marten den Haring, Jeffrey Harris, Sam Hartman, Helge Hess, Jeff McCullough, Alexey Melnikov, Dan Mosedale, Brian Moseley, Francois Perrault, Kevin L. Pierre, Julian F. Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari Urpalainen, Simon Vaillancourt, et Jim Whitehead.

Les auteurs tiennent aussi à remercier le "Calendaring and Scheduling Consortium" de ses conseils pour la présente spécification, et pour l'organisation des essais d'interopérabilité pour aider à le préciser.

 	14.	Références
 	14.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2246]	T. Dierks et C. Allen, "Protocole TLS version 1.0", janvier 1999. (P.S. ; MàJ par RFC7919)

[RFC2445]	F. Dawson et D. Stenerson, "Spécification centrale des objets de calendrier et de programmation de l'Internet (iCalendar)", novembre 1998. (P.S.)

[RFC2446]	S. Silverberg, S. Mansour, F. Dawson, R. Hopson, "Événements structurants, heures d'ouverture, opérations à faire et entrées de journalisation du protocole d'interopérabilité iCalendar indépendant du transport (iTIP)", novembre 1998. (P.S., Remplacée par RFC5546)

[RFC2518]	Y. Goland, E. Whitehead, A. Faizi, S. Carter et D. Jensen, "Extensions HTTP pour la création répartie -- WEBDAV", février 1999. (Obsolète, voir la RFC 4918)

[RFC2616]	R. Fielding et autres, "Protocole de transfert hypertexte -- HTTP/1.1", juin 1999. (D.S., MàJ par 2817, 6585)

[RFC2818]	E. Rescorla, "HTTP sur TLS", mai 2000. (Information)

[RFC3253]	G. Clemm et autres, "Extensions de versions à WebDAV (Protocole de collecte ordonnée des auteurs et des versions distribuée sur la Toile)", mars 2002. (P.S.)

[RFC3688]	M. Mealling, "Registre XML de l'IETF", BCP 81, janvier 2004.

[RFC3744]	G. Clemm et autres, "Protocole de contrôle d'accès à la collecte des noms d'auteurs et de version répartie sur la Toile (WebDAV)", mai 2004. (P.S.)

[RFC4346]	T. Dierks et E. Rescorla, "Protocole de sécurité de la couche Transport (TLS) version 1.1", avril 2006. (Remplace RFC2246 ; Remplacée par RFC5246 ; MàJ par RFC4366, 4680, 4681, 5746, 6176, 7465, 7507, 7919)

[RFC4790]	C. Newman et autres, "Registre de collation des protocoles d'application de l'Internet", mars 2007. (P.S.)

[XML-2006]	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, août 2006,

 	14.2	Références pour information

[RFC2426]	F. Dawson, T. Howes, "Profil de répertoire MIME vCard", septembre 1998. (Obsolète, voir RFC6350) (P.S.)

[RFC2739]	T. Small, D. Hennessy, F. Dawson, "Attributs de calendrier pour vCard et LDAP", janvier 2000. (P.S.)

[RFC4331]	B. Korver, L. Dusseault, "Quota et propriétés de taille pour les collections d'auteurs et de version réparties (DAV)" février  2006. (P.S.)

[RFC4511]	J. Sermersheim, éditeur, "Protocole léger d’accès à un répertoire (LDAP) Le protocole", juin 2006.

[RFC4918]	L. Dusseault, éd. "Extensions HTTP pour les informations d'auteur et de version distribuées sur la Toile (WebDAV)", juin 2007. (Remplace RFC2518) (P.S.)

 	Appendice A.	Tableau de privilèges de méthode CalDAV (normatif)

Le tableau suivant étend le tableau des privilèges de méthode WebDAV spécifié à l'Appendice B de la [RFC3744].

MÉTHODE	PRIVILÈGES
MKCALENDAR	DAV:bind
REPORT	DAV:read ou CALDAV:read-free-busy (sur toutes les ressources référencées)

 	Appendice B.	Collections Calendar utilisées dans les exemples

Cet appendice montre les ressources d'objet Calendrier contenues dans la collection de calendriers interrogée dans les exemples donnés dans ce document.

Le contenu de la collection de calendriers est montré comme si il était retourné par une demande de rapport CALDAV:calendar-query destinée à retourner toutes les données de calendrier de la collection:

>> Demande <<

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>

>> Réponse <<

HTTP/1.1 207 Multi-Status
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
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
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART;TZID=US/Eastern:20060102T120000
DURATION:PT1H
RRULE:FREQ=DAILY;COUNT=5
SUMMARY:Event #2
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART;TZID=US/Eastern:20060104T140000
DURATION:PT1H
RECURRENCE-ID;TZID=US/Eastern:20060104T120000
SUMMARY:Event #2 bis
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>

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

 	Adresse des auteurs
Cyrus Daboo	Bernard Desruisseaux	Lisa Dusseault	
Apple Inc.	Oracle Corporation	CommerceNet	
1 Infinite Loop	600 Blvd. de Maisonneuve West	169 University Ave.	
Cupertino, CA  95014	Suite 1900	Palo Alto, CA  94301	
USA	Montreal, QC  H3A 3J2	USA	
mél : cyrus@daboo.name 	CANADA	mél : ldusseault@commerce.net 	
URI : http://www.apple.com/ 	mél : bernard.desruisseaux@oracle.com 	URI : http://commerce.net/ 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est fourni par l'activité de soutien administratif de l'IETF (IASA).