forked from owncloud/android
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrfc6352-CardDAV-Spec.html
2718 lines (1907 loc) · 207 KB
/
rfc6352-CardDAV-Spec.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- saved from url=(0041)http://tools.ietf.org/html/rfc6352#page-7 -->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><meta name="robots" content="index,follow"><meta name="creator" content="rfcmarkup version 1.96"><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"><meta name="DC.Identifier" content="urn:ietf:rfc:6352"><meta name="DC.Description.Abstract" content="This document defines extensions to the Web Distributed Authoring and\nVersioning (WebDAV) protocol to specify a standard way of accessing,\nmanaging, and sharing contact information based on the vCard format.\n[STANDARDS-TRACK]"><meta name="DC.Creator" content="Cyrus Daboo <cyrus@daboo.name>"><meta name="DC.Date.Issued" content="August, 2011"><meta name="DC.Title" content="CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)"><link rel="icon" href="http://tools.ietf.org/images/rfc.png" type="image/png"><link rel="shortcut icon" href="http://tools.ietf.org/images/rfc.png" type="image/png"><title>RFC 6352 - CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)</title> <style type="text/css">body{margin:0px 8px;font-size:1em;}h1,h2,h3,h4,h5,h6,.h1,.h2,.h3,.h4,.h5,.h6{font-weight:bold;line-height:0pt;display:inline;white-space:pre;font-family:monospace;font-size:1em;font-weight:bold;}pre{font-size:1em;margin-top:0px;margin-bottom:0px;}.pre{white-space:pre;font-family:monospace;}.header{font-weight:bold;}.newpage{page-break-before:always;}.invisible{text-decoration:none;color:white;}@media print{body{font-size:10.5pt;}h1,h2,h3,h4,h5,h6{font-size:10.5pt;}a:link,a:visited{color:inherit;text-decoration:none;}.noprint{display:none;}}@media screen{.grey,.grey a:link,.grey a:visited{color:#777;}.docinfo{background-color:#EEE;}.top{border-top:7px solid #EEE;}.bgwhite{background-color:white;}.bgred{background-color:#F44;}.bggrey{background-color:#666;}.bgbrown{background-color:#840;}.bgorange{background-color:#FA0;}.bgyellow{background-color:#EE0;}.bgmagenta{background-color:#F4F;}.bgblue{background-color:#66F;}.bgcyan{background-color:#4DD;}.bggreen{background-color:#4F4;}.legend{font-size:90%;}.cplate{font-size:70%;border:solid grey 1px;}}</style> <!--[if IE]><style>
body {
font-size: 13px;
margin: 10px 10px;
}
</style> <![endif]--><script type="text/javascript"><!--
function addHeaderTags() {
var spans = document.getElementsByTagName("span");
for (var i=0; i < spans.length; i++) {
var elem = spans[i];
if (elem) {
var level = elem.getAttribute("class");
if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
}
}
}
}
var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'> </span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> <tr><td>Best Common Practice:</td><td><span class='cplate bgmagenta'> </span></td></tr> <tr><td>Proposed Standard:</td><td><span class='cplate bgblue'> </span></td></tr> <tr><td>Draft Standard:</td> <td><span class='cplate bgcyan'> </span></td></tr> <tr><td>Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </span></td></tr> </table>";
function showElem(id) {
var elem = document.getElementById(id);
elem.innerHTML = eval(id+"_html");
elem.style.visibility='visible';
}
function hideElem(id) {
var elem = document.getElementById(id);
elem.style.visibility='hidden';
elem.innerHTML = "";
}
// -->
</script> </head><body onload="addHeaderTags()"><div style="height: 13px;"><div onmouseover="this.style.cursor='pointer';" onclick="showElem('legend');" onmouseout="hideElem('legend')" style="height: 6px; position: absolute;" class="pre noprint docinfo bgblue" title="Click for colour legend."></div><div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="showElem('legend');" onmouseout="hideElem('legend');"></div></div><span class="pre noprint docinfo top">[<a href="http://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="http://tools.ietf.org/rfc/rfc6352.txt" title="Plaintext version of this document">txt</a>|<a href="http://tools.ietf.org/pdf/rfc6352" title="PDF version of this document">pdf</a>] [<a href="http://tools.ietf.org/html/draft-ietf-vcarddav-carddav" title="draft-ietf-vcarddav-carddav">draft-ietf-vcardd...</a>] [<a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc6352" title="Inline diff (wdiff)">Diff1</a>] [<a href="http://tools.ietf.org/rfcdiff?url2=rfc6352" title="Side-by-side diff">Diff2</a>] </span><br><span class="pre noprint docinfo"></span><br><span class="pre noprint docinfo">PROPOSED STANDARD</span><br><span class="pre noprint docinfo"></span><br><pre>Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6352 Apple
Category: Standards Track August 2011
ISSN: 2070-1721
<span class="h1"><h1>CardDAV: vCard Extensions to</h1></span>
<span class="h1"><h1>Web Distributed Authoring and Versioning (WebDAV)</h1></span>
Abstract
This document defines extensions to the Web Distributed Authoring and
Versioning (WebDAV) protocol to specify a standard way of accessing,
managing, and sharing contact information based on the vCard format.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="http://tools.ietf.org/html/rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6352">http://www.rfc-editor.org/info/rfc6352</a>.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="http://tools.ietf.org/html/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in <a href="http://tools.ietf.org/html/rfc6352#section-4">Section 4</a>.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
<span class="grey">Daboo Standards Track [Page 1]</span>
</pre><pre class="newpage"><a name="page-2" id="page-2" href="http://tools.ietf.org/html/rfc6352#page-2" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="http://tools.ietf.org/html/rfc6352#section-1">1</a>. Introduction and Overview . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-4">4</a>
<a href="http://tools.ietf.org/html/rfc6352#section-2">2</a>. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-5">5</a>
<a href="http://tools.ietf.org/html/rfc6352#section-3">3</a>. Requirements Overview . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-6">6</a>
<a href="http://tools.ietf.org/html/rfc6352#section-4">4</a>. Address Book Data Model . . . . . . . . . . . . . . . . . . . <a href="./rfc6352-CardDAV-Spec_files/rfc6352-CardDAV-Spec.html">7</a>
<a href="http://tools.ietf.org/html/rfc6352#section-4.1">4.1</a>. Address Book Server . . . . . . . . . . . . . . . . . . . <a href="./rfc6352-CardDAV-Spec_files/rfc6352-CardDAV-Spec.html">7</a>
<a href="http://tools.ietf.org/html/rfc6352#section-5">5</a>. Address Book Resources . . . . . . . . . . . . . . . . . . . . <a href="./rfc6352-CardDAV-Spec_files/rfc6352-CardDAV-Spec.html">7</a>
<a href="http://tools.ietf.org/html/rfc6352#section-5.1">5.1</a>. Address Object Resources . . . . . . . . . . . . . . . . . <a href="./rfc6352-CardDAV-Spec_files/rfc6352-CardDAV-Spec.html">7</a>
<a href="http://tools.ietf.org/html/rfc6352#section-5.1.1">5.1.1</a>. Data Type Conversion . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-8">8</a>
<a href="http://tools.ietf.org/html/rfc6352#section-5.1.1.1">5.1.1.1</a>. Additional Precondition for GET . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-8">8</a>
<a href="http://tools.ietf.org/html/rfc6352#section-5.2">5.2</a>. Address Book Collections . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-9">9</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6">6</a>. Address Book Feature . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-10">10</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.1">6.1</a>. Address Book Support . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-10">10</a>
6.1.1. Example: Using OPTIONS for the Discovery of
Support for CardDAV . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-10">10</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.2">6.2</a>. Address Book Properties . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-10">10</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.2.1">6.2.1</a>. CARDDAV:addressbook-description Property . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-10">10</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.2.2">6.2.2</a>. CARDDAV:supported-address-data Property . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-11">11</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.2.3">6.2.3</a>. CARDDAV:max-resource-size Property . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-12">12</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.3">6.3</a>. Creating Resources . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-13">13</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.3.1">6.3.1</a>. Extended MKCOL Method . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-13">13</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.3.1.1">6.3.1.1</a>. Example - Successful MKCOL Request . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-14">14</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.3.2">6.3.2</a>. Creating Address Object Resources . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-15">15</a>
6.3.2.1. Additional Preconditions for PUT, COPY, and
MOVE . . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-16">16</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.3.2.2">6.3.2.2</a>. Non-Standard vCard Properties and Parameters . . . <a href="http://tools.ietf.org/html/rfc6352#page-17">17</a>
<a href="http://tools.ietf.org/html/rfc6352#section-6.3.2.3">6.3.2.3</a>. Address Object Resource Entity Tag . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-18">18</a>
<a href="http://tools.ietf.org/html/rfc6352#section-7">7</a>. Address Book Access Control . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-18">18</a>
<a href="http://tools.ietf.org/html/rfc6352#section-7.1">7.1</a>. Additional Principal Properties . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-18">18</a>
<a href="http://tools.ietf.org/html/rfc6352#section-7.1.1">7.1.1</a>. CARDDAV:addressbook-home-set Property . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-19">19</a>
<a href="http://tools.ietf.org/html/rfc6352#section-7.1.2">7.1.2</a>. CARDDAV:principal-address Property . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-19">19</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8">8</a>. Address Book Reports . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-20">20</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.1">8.1</a>. REPORT Method . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-20">20</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.2">8.2</a>. Ordinary Collections . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-21">21</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.3">8.3</a>. Searching Text: Collations . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-21">21</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.3.1">8.3.1</a>. CARDDAV:supported-collation-set Property . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-22">22</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.4">8.4</a>. Partial Retrieval . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-23">23</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.5">8.5</a>. Non-Standard Properties and Parameters . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-23">23</a>
<span class="grey">Daboo Standards Track [Page 2]</span>
</pre><pre class="newpage"><a name="page-3" id="page-3" href="http://tools.ietf.org/html/rfc6352#page-3" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
<a href="http://tools.ietf.org/html/rfc6352#section-8.6">8.6</a>. CARDDAV:addressbook-query Report . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-23">23</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.6.1">8.6.1</a>. Limiting Results . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-25">25</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.6.2">8.6.2</a>. Truncation of Results . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-25">25</a>
8.6.3. Example: Partial Retrieval of vCards Matching
NICKNAME . . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-26">26</a>
8.6.4. Example: Partial Retrieval of vCards Matching a
Full Name or Email Address . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-27">27</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.6.5">8.6.5</a>. Example: Truncated Results . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-29">29</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.7">8.7</a>. CARDDAV:addressbook-multiget Report . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-31">31</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.7.1">8.7.1</a>. Example: CARDDAV:addressbook-multiget Report . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-32">32</a>
<a href="http://tools.ietf.org/html/rfc6352#section-8.7.2">8.7.2</a>. Example: CARDDAV:addressbook-multiget Report . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-33">33</a>
<a href="http://tools.ietf.org/html/rfc6352#section-9">9</a>. Client Guidelines . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-34">34</a>
<a href="http://tools.ietf.org/html/rfc6352#section-9.1">9.1</a>. Restrict the Properties Returned . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-34">34</a>
<a href="http://tools.ietf.org/html/rfc6352#section-9.2">9.2</a>. Avoiding Lost Updates . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-35">35</a>
<a href="http://tools.ietf.org/html/rfc6352#section-9.3">9.3</a>. Client Configuration . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-35">35</a>
<a href="http://tools.ietf.org/html/rfc6352#section-9.4">9.4</a>. Finding Other Users' Address Books . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-35">35</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10">10</a>. XML Element Definitions . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-36">36</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.1">10.1</a>. CARDDAV:addressbook XML Element . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-36">36</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.2">10.2</a>. CARDDAV:supported-collation XML Element . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-36">36</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.3">10.3</a>. CARDDAV:addressbook-query XML Element . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-37">37</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.4">10.4</a>. CARDDAV:address-data XML Element . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-37">37</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.4.1">10.4.1</a>. CARDDAV:allprop XML Element . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-39">39</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.4.2">10.4.2</a>. CARDDAV:prop XML Element . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-39">39</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.5">10.5</a>. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-40">40</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.5.1">10.5.1</a>. CARDDAV:prop-filter XML Element . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-40">40</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.5.2">10.5.2</a>. CARDDAV:param-filter XML Element . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-41">41</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.5.3">10.5.3</a>. CARDDAV:is-not-defined XML Element . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-42">42</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.5.4">10.5.4</a>. CARDDAV:text-match XML Element . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-42">42</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.6">10.6</a>. CARDDAV:limit XML Element . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-43">43</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.6.1">10.6.1</a>. CARDDAV:nresults XML Element . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-44">44</a>
<a href="http://tools.ietf.org/html/rfc6352#section-10.7">10.7</a>. CARDDAV:addressbook-multiget XML Element . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-44">44</a>
<a href="http://tools.ietf.org/html/rfc6352#section-11">11</a>. Service Discovery via SRV Records . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-45">45</a>
<a href="http://tools.ietf.org/html/rfc6352#section-12">12</a>. Internationalization Considerations . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-45">45</a>
<a href="http://tools.ietf.org/html/rfc6352#section-13">13</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-45">45</a>
<a href="http://tools.ietf.org/html/rfc6352#section-14">14</a>. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-46">46</a>
<a href="http://tools.ietf.org/html/rfc6352#section-14.1">14.1</a>. Namespace Registration . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-46">46</a>
<a href="http://tools.ietf.org/html/rfc6352#section-15">15</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-46">46</a>
<a href="http://tools.ietf.org/html/rfc6352#section-16">16</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-47">47</a>
<a href="http://tools.ietf.org/html/rfc6352#section-16.1">16.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-47">47</a>
<a href="http://tools.ietf.org/html/rfc6352#section-16.2">16.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="http://tools.ietf.org/html/rfc6352#page-48">48</a>
<span class="grey">Daboo Standards Track [Page 3]</span>
</pre><pre class="newpage"><a name="page-4" id="page-4" href="http://tools.ietf.org/html/rfc6352#page-4" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
<span class="h2"><h2><a name="section-1">1</a>. Introduction and Overview</h2></span>
Address books containing contact information are a key component of
personal information management tools, such as email, calendaring and
scheduling, and instant messaging clients. To date several protocols
have been used for remote access to contact data, including the
Lightweight Directory Access Protocol (LDAP) [<a href="http://tools.ietf.org/html/rfc4510" title=""Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map"">RFC4510</a>], Internet
Message Support Protocol [<a href="http://tools.ietf.org/html/rfc6352#ref-IMSP" title=""IMSP - Internet Message Support Protocol"">IMSP</a>], and Application Configuration Access
Protocol (ACAP) [<a href="http://tools.ietf.org/html/rfc2244" title=""ACAP -- Application Configuration Access Protocol"">RFC2244</a>], together with SyncML used for
synchronization of such data.
WebDAV [<a href="http://tools.ietf.org/html/rfc4918" title=""HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)"">RFC4918</a>] offers a number of advantages as a framework or
basis for address book access and management. Most of these
advantages boil down to a significant reduction in the costs of
design, implementation, interoperability testing, and deployment.
The key features of address book support with WebDAV are:
1. Ability to use multiple address books with hierarchical layout.
2. Ability to control access to individual address books and address
entries as per WebDAV Access Control List (ACL) [<a href="http://tools.ietf.org/html/rfc3744" title=""Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol"">RFC3744</a>].
3. Principal collections can be used to enumerate and query other
users on the system as per WebDAV ACL [<a href="http://tools.ietf.org/html/rfc3744" title=""Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol"">RFC3744</a>].
4. Server-side searching of address data, avoiding the need for
clients to download an entire address book in order to do a quick
address 'expansion' operation.
5. Well-defined internationalization support through WebDAV's use of
XML.
6. Use of vCards [<a href="http://tools.ietf.org/html/rfc2426" title=""vCard MIME Directory Profile"">RFC2426</a>] for well-defined address schema to
enhance client interoperability.
7. Many limited clients (e.g., mobile devices) contain an HTTP stack
that makes implementing WebDAV much easier than other protocols.
The key disadvantage of address book support in WebDAV is:
1. Lack of change notification. Many of the alternative protocols
also lack this ability. However, an extension for push
notifications could easily be developed.
vCard is a MIME directory profile aimed at encapsulating personal
addressing and contact information about people. The specification
of vCard was originally done by the Versit consortium, with a
<span class="grey">Daboo Standards Track [Page 4]</span>
</pre><pre class="newpage"><a name="page-5" id="page-5" href="http://tools.ietf.org/html/rfc6352#page-5" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
subsequent 3.0 version standardized by the IETF [<a href="http://tools.ietf.org/html/rfc2426" title=""vCard MIME Directory Profile"">RFC2426</a>]. vCard is
in widespread use in email clients and mobile devices as a means of
encapsulating address information for transport via email or for
import/export and synchronization operations.
An update to vCard -- vCard v4 -- is currently being developed
[<a href="http://tools.ietf.org/html/rfc6350" title=""vCard Format Specification"">RFC6350</a>] and is compatible with this specification.
<span class="h2"><h2><a name="section-2">2</a>. Conventions</h2></span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="http://tools.ietf.org/html/rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
The term "protected" is used in the Conformance field of property
definitions as defined in <a href="http://tools.ietf.org/html/rfc4918#section-15">Section 15 of [RFC4918]</a>.
This document uses XML DTD fragments ([<a href="http://tools.ietf.org/html/rfc6352#ref-W3C.REC-xml-20081126">W3C.REC-xml-20081126</a>], <a href="http://tools.ietf.org/html/rfc6352#section-3.2">Section</a>
<a href="http://tools.ietf.org/html/rfc6352#section-3.2">3.2</a>) as a purely notational convention. WebDAV request and response
bodies cannot be validated by a DTD due to the specific extensibility
rules defined in <a href="http://tools.ietf.org/html/rfc4918#section-17">Section 17 of [RFC4918]</a> and due to the fact that all
XML elements defined by that specification use the XML namespace name
"DAV:". In particular:
1. Element names use the "DAV:" namespace.
2. Element ordering is irrelevant unless explicitly stated.
3. Extension elements (elements not already defined as valid child
elements) may be added anywhere, except when explicitly stated
otherwise.
4. Extension attributes (attributes not already defined as valid for
this element) may be added anywhere, except when explicitly
stated otherwise.
The namespace "urn:ietf:params:xml:ns:carddav" is reserved for the
XML elements defined in this specification, its revisions, and
related CardDAV specifications. XML elements defined by individual
implementations MUST NOT use the "urn:ietf:params:xml:ns:carddav"
namespace, and instead should use a namespace that they control.
When XML element types in the namespaces "DAV:" and
"urn:ietf:params:xml:ns:carddav" are referenced in this document
outside of the context of an XML fragment, the strings "DAV:" and
"CARDDAV:" will be prefixed to the element types, respectively.
<span class="grey">Daboo Standards Track [Page 5]</span>
</pre><pre class="newpage"><a name="page-6" id="page-6" href="http://tools.ietf.org/html/rfc6352#page-6" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
This document inherits, and sometimes extends, DTD productions from
<a href="http://tools.ietf.org/html/rfc4918#section-14">Section 14 of [RFC4918]</a>.
Also, note that some CardDAV XML element names are identical to
WebDAV XML element names, though their namespace differs. Care must
be taken not to confuse the two sets of names.
<span class="h2"><h2><a name="section-3">3</a>. Requirements Overview</h2></span>
This section lists what functionality is required of a CardDAV
server. To advertise support for CardDAV, a server:
o MUST support vCard v3 [<a href="http://tools.ietf.org/html/rfc2426" title=""vCard MIME Directory Profile"">RFC2426</a>] as a media type for the address
object resource format;
o MUST support WebDAV Class 3 [<a href="http://tools.ietf.org/html/rfc4918" title=""HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)"">RFC4918</a>];
o MUST support WebDAV ACL [<a href="http://tools.ietf.org/html/rfc3744" title=""Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol"">RFC3744</a>];
o MUST support secure transport as defined in [<a href="http://tools.ietf.org/html/rfc2818" title=""HTTP Over TLS"">RFC2818</a>] using
Transport Layer Security (TLS) [<a href="http://tools.ietf.org/html/rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] and using the certificate
validation procedures described in [<a href="http://tools.ietf.org/html/rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>];
o MUST support ETags [<a href="http://tools.ietf.org/html/rfc2616" title=""Hypertext Transfer Protocol -- HTTP/1.1"">RFC2616</a>] with additional requirements
specified in <a href="http://tools.ietf.org/html/rfc6352#section-6.3.2.3">Section 6.3.2.3</a> of this document;
o MUST support all address book reports defined in <a href="http://tools.ietf.org/html/rfc6352#section-8">Section 8</a> of this
document; and
o MUST advertise support on all address book collections and address
object resources for the address book reports in the
DAV:supported-report-set property, as defined in Versioning
Extensions to WebDAV [<a href="http://tools.ietf.org/html/rfc3253" title=""Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)"">RFC3253</a>].
In addition, a server:
o SHOULD support vCard v4 [<a href="http://tools.ietf.org/html/rfc6350" title=""vCard Format Specification"">RFC6350</a>] as a media type for the address
object resource format;
o SHOULD support the extended MKCOL method [<a href="http://tools.ietf.org/html/rfc5689" title=""Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)"">RFC5689</a>] to create
address book collections as defined in <a href="http://tools.ietf.org/html/rfc6352#section-6.3.1">Section 6.3.1</a> of this
document.
o SHOULD support the DAV:current-user-principal-URL property as
defined in [<a href="http://tools.ietf.org/html/rfc5397" title=""WebDAV Current Principal Extension"">RFC5397</a>] to give clients a fast way to locate user
principals.
<span class="grey">Daboo Standards Track [Page 6]</span>
</pre><pre class="newpage"><a name="page-7" id="page-7" href="./rfc6352-CardDAV-Spec_files/rfc6352-CardDAV-Spec.html" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
<span class="h2"><h2><a name="section-4">4</a>. Address Book Data Model</h2></span>
As a brief overview, a CardDAV address book is modeled as a WebDAV
collection with a well-defined structure; each of these address book
collections contains a number of resources representing address
objects as their direct child resources. Each resource representing
an address object is called an "address object resource". Each
address object resource and each address book collection can be
individually locked and have individual WebDAV properties.
Requirements derived from this model are provided in Sections <a href="http://tools.ietf.org/html/rfc6352#section-5.1">5.1</a> and
5.2.
<span class="h3"><h3><a name="section-4.1">4.1</a>. Address Book Server</h3></span>
A CardDAV server is an address-aware engine combined with a WebDAV
server. The server may include address data in some parts of its URL
namespace and non-address data in other parts.
A WebDAV server can advertise itself as a CardDAV server if it
supports the functionality defined in this specification at any point
within the root of its repository. That might mean that address data
is spread throughout the repository and mixed with non-address data
in nearby collections (e.g., address data may be found in /lisa/
addressbook/ as well as in /bernard/addressbook/, and non-address
data in /lisa/calendars/). Or, it might mean that address data can
be found only in certain sections of the repository (e.g.,
/addressbooks/user/). Address book features are only required in the
repository sections that are or contain address objects. So, a
repository confining address data to the /carddav/ collection would
only need to support the CardDAV required features within that
collection.
The CardDAV server is the canonical location for address data and
state information. Clients may submit requests to change data or
download data. Clients may store address objects offline and attempt
to synchronize at a later time. Address data on the server can
change between the time of last synchronization and when attempting
an update, as address book collections may be shared and accessible
via multiple clients. Entity tags and locking help this work.
<span class="h2"><h2><a name="section-5">5</a>. Address Book Resources</h2></span>
<span class="h3"><h3><a name="section-5.1">5.1</a>. Address Object Resources</h3></span>
This specification uses vCard as the default format for address or
contact information being stored on the server. However, this
specification does allow other formats for address data provided that
the server advertises support for those additional formats as
<span class="grey">Daboo Standards Track [Page 7]</span>
</pre><pre class="newpage"><a name="page-8" id="page-8" href="http://tools.ietf.org/html/rfc6352#page-8" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
described below. The requirements in this section pertain to vCard
address data or formats that follow the semantics of vCard data.
Address object resources contained in address book collections MUST
contain a single vCard component only.
vCard components in an address book collection MUST have a UID
property value that MUST be unique in the scope of the address book
collection in which it is contained.
<span class="h4"><h4><a name="section-5.1.1">5.1.1</a>. Data Type Conversion</h4></span>
Servers might support more than one primary media type for address
object resources, for example, vCard v3.0 and vCard v4.0. In such
cases, servers have to accept all media types that they advertise via
the CARDDAV:supported-address-data WebDAV property (see
<a href="http://tools.ietf.org/html/rfc6352#section-6.2.2">Section 6.2.2</a>).
However, clients can use standard HTTP content negotiation behavior
(the Accept request header defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.1">Section 14.1 of [RFC2616]</a>) to
request that an address object resource's data be returned in a
specific media type format. For example, a client merely capable of
handling vCard v3.0 would only want to have address object resources
returned in v3.0 format.
Additionally, REPORT requests, defined later in this specification,
allow for the return of address object resource data within an XML
response body. Again, the client can use content negotiation to
request that data be returned in a specific media type by specifying
appropriate attributes on the CARDDAV:address-data XML element used
in the request body (see <a href="http://tools.ietf.org/html/rfc6352#section-10.4">Section 10.4</a>).
In some cases, it might not be possible for a server to convert from
one media type to another. When that happens, the server MUST return
the CARDDAV:supported-address-data-conversion precondition (see
below) in the response body (when the failure to convert applies to
the entire response) or use that same precondition code in the
DAV:response XML element in the response for the targeted address
object resource when one of the REPORTs defined below is used. See
<a href="http://tools.ietf.org/html/rfc6352#section-8.7.2">Section 8.7.2</a> for an example of this.
<span class="h5"><h5><a name="section-5.1.1.1">5.1.1.1</a>. Additional Precondition for GET</h5></span>
This specification creates additional preconditions for the GET
method.
<span class="grey">Daboo Standards Track [Page 8]</span>
</pre><pre class="newpage"><a name="page-9" id="page-9" href="http://tools.ietf.org/html/rfc6352#page-9" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
The new precondition is:
(CARDDAV:supported-address-data-conversion): The resource targeted
by the GET request can be converted to the media type specified in
the Accept request header included with the request.
<span class="h3"><h3><a name="section-5.2">5.2</a>. Address Book Collections</h3></span>
Address book collections appear to clients as a WebDAV collection
resource, identified by a URL. An address book collection MUST
report the DAV:collection and CARDDAV:addressbook XML elements in the
value of the DAV:resourcetype property. The element type declaration
for CARDDAV:addressbook is:
<!ELEMENT addressbook EMPTY>
An address book collection can be created through provisioning (e.g.,
automatically created when a user's account is provisioned), or it
can be created with the extended MKCOL method (see <a href="http://tools.ietf.org/html/rfc6352#section-6.3.1">Section 6.3.1</a>).
This can be used by a user to create additional address books (e.g.,
"soccer team members") or for users to share an address book (e.g.,
"sales team contacts"). However, note that this document doesn't
define what extra address book collections are for. Users must rely
on non-standard cues to find out what an address book collection is
for, or use the CARDDAV:addressbook-description property defined in
<a href="http://tools.ietf.org/html/rfc6352#section-6.2.1">Section 6.2.1</a> to provide such a cue.
The following restrictions are applied to the resources within an
address book collection:
a. Address book collections MUST only contain address object
resources and collections that are not address book collections.
That is, the only "top-level" non-collection resources allowed in
an address book collection are address object resources. This
ensures that address book clients do not have to deal with non-
address data in an address book collection, though they do have
to distinguish between address object resources and collections
when using standard WebDAV techniques to examine the contents of
a collection.
b. Collections contained in address book collections MUST NOT
contain address book collections at any depth. That is,
"nesting" of address book collections within other address book
collections at any depth is not allowed. This specification does
not define how collections contained in an address book
collection are used or how they relate to any address object
resources contained in the address book collection.
<span class="grey">Daboo Standards Track [Page 9]</span>
</pre><pre class="newpage"><a name="page-10" id="page-10" href="http://tools.ietf.org/html/rfc6352#page-10" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
Multiple address book collections MAY be children of the same
collection.
<span class="h2"><h2><a name="section-6">6</a>. Address Book Feature</h2></span>
<span class="h3"><h3><a name="section-6.1">6.1</a>. Address Book Support</h3></span>
A server supporting the features described in this document MUST
include "addressbook" as a field in the DAV response header from an
OPTIONS request on any resource that supports any address book
properties, reports, or methods. A value of "addressbook" in the DAV
response header MUST indicate that the server supports all MUST level
requirements and REQUIRED features specified in this document.
<span class="h4"><h4><a name="section-6.1.1">6.1.1</a>. Example: Using OPTIONS for the Discovery of Support for CardDAV</h4></span>
>> Request <<
OPTIONS /addressbooks/users/ HTTP/1.1
Host: addressbook.example.com
>> Response <<
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, 3, access-control, addressbook
DAV: extended-mkcol
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Length: 0
In this example, the OPTIONS response indicates that the server
supports CardDAV in this namespace; therefore, the '/addressbooks/
users/' collection may be used as a parent for address book
collections as the extended MKCOL method is available and as a
possible target for REPORT requests for address book reports.
<span class="h3"><h3><a name="section-6.2">6.2</a>. Address Book Properties</h3></span>
<span class="h4"><h4><a name="section-6.2.1">6.2.1</a>. CARDDAV:addressbook-description Property</h4></span>
Name: addressbook-description
Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Provides a human-readable description of the address book
collection.
<span class="grey">Daboo Standards Track [Page 10]</span>
</pre><pre class="newpage"><a name="page-11" id="page-11" href="http://tools.ietf.org/html/rfc6352#page-11" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
Value: Any text.
Protected: SHOULD NOT be protected so that users can specify a
description.
COPY/MOVE behavior: This property value SHOULD be preserved in COPY
and MOVE operations.
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request.
Description: This property contains a description of the address
book collection that is suitable for presentation to a user. The
xml:lang attribute can be used to add a language tag for the value
of this property.
Definition:
<!ELEMENT addressbook-description (#PCDATA)>
<!-- PCDATA value: string -->
Example:
<C:addressbook-description xml:lang="fr-CA"
xmlns:C="urn:ietf:params:xml:ns:carddav"
>Adresses de Oliver Daboo</C:addressbook-description>
<span class="h4"><h4><a name="section-6.2.2">6.2.2</a>. CARDDAV:supported-address-data Property</h4></span>
Name: supported-address-data
Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Specifies what media types are allowed for address object
resources in an address book collection.
Protected: MUST be protected as it indicates the level of support
provided by the server.
COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations.
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request.
Description: The CARDDAV:supported-address-data property is used to
specify the media type supported for the address object resources
contained in a given address book collection (e.g., vCard version
<span class="grey">Daboo Standards Track [Page 11]</span>
</pre><pre class="newpage"><a name="page-12" id="page-12" href="http://tools.ietf.org/html/rfc6352#page-12" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
3.0). Any attempt by the client to store address object resources
with a media type not listed in this property MUST result in an
error, with the CARDDAV:supported-address-data precondition
(<a href="http://tools.ietf.org/html/rfc6352#section-6.3.2.1">Section 6.3.2.1</a>) being violated. In the absence of this
property, the server MUST only accept data with the media type
"text/vcard" and vCard version 3.0, and clients can assume that is
all the server will accept.
Definition:
<!ELEMENT supported-address-data (address-data-type+)>
<!ELEMENT address-data-type EMPTY>
<!ATTLIST address-data-type content-type CDATA "text/vcard"
version CDATA "3.0">
<!-- content-type value: a MIME media type -->
<!-- version value: a version string -->
Example:
<C:supported-address-data
xmlns:C="urn:ietf:params:xml:ns:carddav">
<C:address-data-type content-type="text/vcard" version="3.0"/>
</C:supported-address-data>
<span class="h4"><h4><a name="section-6.2.3">6.2.3</a>. CARDDAV:max-resource-size Property</h4></span>
Name: max-resource-size
Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Provides a numeric value indicating the maximum size in
octets of a resource that the server is willing to accept when an
address object resource is stored in an address book collection.
Value: Any text representing a numeric value.
Protected: MUST be protected as it indicates limits provided by the
server.
COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations.
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request.
<span class="grey">Daboo Standards Track [Page 12]</span>
</pre><pre class="newpage"><a name="page-13" id="page-13" href="http://tools.ietf.org/html/rfc6352#page-13" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
Description: The CARDDAV:max-resource-size is used to specify a
numeric value that represents the maximum size in octets that the
server is willing to accept when an address object resource is
stored in an address book collection. Any attempt to store an
address book object resource exceeding this size MUST result in an
error, with the CARDDAV:max-resource-size precondition
(<a href="http://tools.ietf.org/html/rfc6352#section-6.3.2.1">Section 6.3.2.1</a>) being violated. In the absence of this
property, the client can assume that the server will allow storing
a resource of any reasonable size.
Definition:
<!ELEMENT max-resource-size (#PCDATA)>
<!-- PCDATA value: a numeric value (positive decimal integer) -->
Example:
<C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:carddav"
>102400</C:max-resource-size>
<span class="h3"><h3><a name="section-6.3">6.3</a>. Creating Resources</h3></span>
Address book collections and address object resources may be created
by either a CardDAV client or the CardDAV server. This specification
defines restrictions and a data model that both clients and servers
MUST adhere to when manipulating such address data.
<span class="h4"><h4><a name="section-6.3.1">6.3.1</a>. Extended MKCOL Method</h4></span>
An HTTP request using the extended MKCOL method [<a href="http://tools.ietf.org/html/rfc5689" title=""Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)"">RFC5689</a>] can be used
to create a new address book collection resource. A server MAY
restrict address book collection creation to particular collections.
To create an address book, the client sends an extended MKCOL request
to the server and in the body of the request sets the
DAV:resourcetype property to the resource type for an address book
collection as defined in <a href="http://tools.ietf.org/html/rfc6352#section-5.2">Section 5.2</a>.
Support for creating address books on the server is only RECOMMENDED
and not REQUIRED because some address book stores only support one
address book per user (or principal), and those are typically pre-
created for each account. However, servers and clients are strongly
encouraged to support address book creation whenever possible to
allow users to create multiple address book collections to help
organize their data better.
<span class="grey">Daboo Standards Track [Page 13]</span>
</pre><pre class="newpage"><a name="page-14" id="page-14" href="http://tools.ietf.org/html/rfc6352#page-14" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
The DAV:displayname property can be used for a human-readable name of
the address book. Clients can either specify the value of the
DAV:displayname property in the request body of the extended MKCOL
request or, alternatively, issue a PROPPATCH request to change the
DAV:displayname property to the appropriate value immediately after
using the extended MKCOL request. When displaying address book
collections to users, clients SHOULD check the DAV:displayname
property and use that value as the name of the address book. In the
event that the DAV:displayname property is not set, the client MAY
use the last part of the address book collection URI as the name;
however, that path segment may be "opaque" and not represent any
meaningful human-readable text.
<span class="h5"><h5><a name="section-6.3.1.1">6.3.1.1</a>. Example - Successful MKCOL Request</h5></span>
This example creates an address book collection called /home/lisa/
addressbook/ on the server addressbook.example.com with specific
values for the properties DAV:resourcetype, DAV:displayname, and
CARDDAV:addressbook-description.
>> Request <<
MKCOL /home/lisa/addressbook/ HTTP/1.1
Host: addressbook.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:mkcol xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:set>
<D:prop>
<D:resourcetype>
<D:collection/>
<C:addressbook/>
</D:resourcetype>
<D:displayname>Lisa's Contacts</D:displayname>
<C:addressbook-description xml:lang="en"
>My primary address book.</C:addressbook-description>
</D:prop>
</D:set>
</D:mkcol>
<span class="grey">Daboo Standards Track [Page 14]</span>
</pre><pre class="newpage"><a name="page-15" id="page-15" href="http://tools.ietf.org/html/rfc6352#page-15" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
>> Response <<
HTTP/1.1 201 Created
Cache-Control: no-cache
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:mkcol-response xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:propstat>
<D:prop>
<D:resourcetype/>
<D:displayname/>
<C:addressbook-description/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:mkcol-response>
<span class="h4"><h4><a name="section-6.3.2">6.3.2</a>. Creating Address Object Resources</h4></span>
Clients populate address book collections with address object
resources. The URL for each address object resource is entirely
arbitrary and does not need to bear a specific relationship (but
might) to the address object resource's vCard properties or other
metadata. New address object resources MUST be created with a PUT
request targeted at an unmapped URI. A PUT request targeted at a
mapped URI updates an existing address object resource.
When servers create new resources, it's not hard for the server to
choose a unique URL. It's slightly tougher for clients, because a
client might not want to examine all resources in the collection and
might not want to lock the entire collection to ensure that a new one
isn't created with a name collision. However, there is an HTTP
feature to mitigate this. If the client intends to create a new
address resource, the client SHOULD use the HTTP header "If-None-
Match: *" on the PUT request. The Request-URI on the PUT request
MUST include the target collection, where the resource is to be
created, plus the name of the resource in the last path segment. The
"If-None-Match" header ensures that the client will not inadvertently
overwrite an existing resource even if the last path segment turned
out to already be used.
<span class="grey">Daboo Standards Track [Page 15]</span>
</pre><pre class="newpage"><a name="page-16" id="page-16" href="http://tools.ietf.org/html/rfc6352#page-16" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
>> Request <<
PUT /lisa/addressbook/newvcard.vcf HTTP/1.1
If-None-Match: *
Host: addressbook.example.com
Content-Type: text/vcard
Content-Length: xxx
BEGIN:VCARD
VERSION:3.0
FN:Cyrus Daboo
N:Daboo;Cyrus
ADR;TYPE=POSTAL:;2822 Email HQ;Suite 2821;RFCVille;PA;15213;USA
EMAIL;TYPE=INTERNET,PREF:cyrus@example.com
NICKNAME:me
NOTE:Example VCard.
ORG:Self Employed
TEL;TYPE=WORK,VOICE:412 605 0499
TEL;TYPE=FAX:412 605 0705
URL:http://www.example.com
UID:1234-5678-9000-1
END:VCARD
>> Response <<
HTTP/1.1 201 Created
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Length: 0
ETag: "123456789-000-111"
The request to change an existing address object resource without
overwriting a change made on the server uses a specific ETag in an
"If-Match" header, rather than the "If-None-Match" header.
File names for vCards are commonly suffixed by ".vcf", and clients
may choose to use the same convention for URLs.
<span class="h5"><h5><a name="section-6.3.2.1">6.3.2.1</a>. Additional Preconditions for PUT, COPY, and MOVE</h5></span>
This specification creates additional preconditions for the PUT,
COPY, and MOVE methods. These preconditions apply:
o When a PUT operation of an address object resource into an address
book collection occurs.
o When a COPY or MOVE operation of an address object resource into
an address book collection occurs.
<span class="grey">Daboo Standards Track [Page 16]</span>
</pre><pre class="newpage"><a name="page-17" id="page-17" href="http://tools.ietf.org/html/rfc6352#page-17" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
The new preconditions are:
(CARDDAV:supported-address-data): The resource submitted in the
PUT request, or targeted by a COPY or MOVE request, MUST be a
supported media type (i.e., vCard) for address object resources.
(CARDDAV:valid-address-data): The resource submitted in the PUT
request, or targeted by a COPY or MOVE request, MUST be valid data
for the media type being specified (i.e., MUST contain valid vCard
data).
(CARDDAV:no-uid-conflict): The resource submitted in the PUT
request, or targeted by a COPY or MOVE request, MUST NOT specify a
vCard UID property value already in use in the targeted address
book collection or overwrite an existing address object resource
with one that has a different UID property value. Servers SHOULD
report the URL of the resource that is already making use of the
same UID property value in the DAV:href element.
<!ELEMENT no-uid-conflict (DAV:href)>
(CARDDAV:addressbook-collection-location-ok): In a COPY or MOVE
request, when the Request-URI is an address book collection, the
URI targeted by the Destination HTTP Request header MUST identify
a location where an address book collection can be created.
(CARDDAV:max-resource-size): The resource submitted in the PUT
request, or targeted by a COPY or MOVE request, MUST have a size
in octets less than or equal to the value of the
CARDDAV:max-resource-size property value (<a href="http://tools.ietf.org/html/rfc6352#section-6.2.3">Section 6.2.3</a>) on the
address book collection where the resource will be stored.
<span class="h5"><h5><a name="section-6.3.2.2">6.3.2.2</a>. Non-Standard vCard Properties and Parameters</h5></span>
vCard provides a "standard mechanism for doing non-standard things".
This extension support allows implementers to make use of non-
standard vCard properties and parameters whose names are prefixed
with the text "X-".
Servers MUST support the use of non-standard properties and
parameters in address object resources stored via the PUT method.
Servers may need to enforce rules for their own "private" properties
or parameters, so servers MAY reject any attempt by the client to
change those or use values for those outside of any restrictions the
server may have. A server SHOULD ensure that any "private"
<span class="grey">Daboo Standards Track [Page 17]</span>
</pre><pre class="newpage"><a name="page-18" id="page-18" href="http://tools.ietf.org/html/rfc6352#page-18" class="invisible"> </a>
<span class="grey"><a href="http://tools.ietf.org/html/rfc6352">RFC 6352</a> CardDAV August 2011</span>
properties or parameters it uses follow the convention of including a
vendor ID in the "X-" name, as described in <a href="http://tools.ietf.org/html/rfc2426#section-3.8">Section 3.8 of [RFC2426]</a>,
e.g., "X-ABC-PRIVATE".
<span class="h5"><h5><a name="section-6.3.2.3">6.3.2.3</a>. Address Object Resource Entity Tag</h5></span>
The DAV:getetag property MUST be defined and set to a strong entity
tag on all address object resources.
A response to a GET request targeted at an address object resource
MUST contain an ETag response header field indicating the current
value of the strong entity tag of the address object resource.
Servers SHOULD return a strong entity tag (ETag header) in a PUT
response when the stored address object resource is equivalent by
octet equality to the address object resource submitted in the body