draft-ietf-vcarddav-carddav-06.txt   draft-ietf-vcarddav-carddav-07.txt 
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Standards Track March 9, 2009 Intended status: Standards Track July 13, 2009
Expires: September 10, 2009 Expires: January 14, 2010
vCard Extensions to WebDAV (CardDAV) vCard Extensions to WebDAV (CardDAV)
draft-ietf-vcarddav-carddav-06 draft-ietf-vcarddav-carddav-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Abstract Abstract
This document defines extensions to the Web Distributed Authoring and This document defines extensions to the Web Distributed Authoring and
Versioning (WebDAV) protocol to specify a standard way of accessing, Versioning (WebDAV) protocol to specify a standard way of accessing,
managing, and sharing contact information based on the vCard format. managing, and sharing contact information based on the vCard format.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
2.2. XML Namespaces and Processing . . . . . . . . . . . . . . 5
3. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6
4. Address Book Data Model . . . . . . . . . . . . . . . . . . . 7 4. Address Book Data Model . . . . . . . . . . . . . . . . . . . 7
4.1. Address Book Server . . . . . . . . . . . . . . . . . . . 7 4.1. Address Book Server . . . . . . . . . . . . . . . . . . . 7
5. Address Book Resources . . . . . . . . . . . . . . . . . . . . 7 5. Address Book Resources . . . . . . . . . . . . . . . . . . . . 7
5.1. Address Object Resources . . . . . . . . . . . . . . . . . 7 5.1. Address Object Resources . . . . . . . . . . . . . . . . . 7
5.2. Address Book Collections . . . . . . . . . . . . . . . . . 8 5.2. Address Book Collections . . . . . . . . . . . . . . . . . 8
6. Address Book Feature . . . . . . . . . . . . . . . . . . . . . 9 6. Address Book Feature . . . . . . . . . . . . . . . . . . . . . 9
6.1. Address Book Support . . . . . . . . . . . . . . . . . . . 9 6.1. Address Book Support . . . . . . . . . . . . . . . . . . . 9
6.1.1. Example: Using OPTIONS for the Discovery of 6.1.1. Example: Using OPTIONS for the Discovery of
Support for CardDAV . . . . . . . . . . . . . . . . . 9 Support for CardDAV . . . . . . . . . . . . . . . . . 9
6.2. Address Book Properties . . . . . . . . . . . . . . . . . 9 6.2. Address Book Properties . . . . . . . . . . . . . . . . . 9
6.2.1. CARDDAV:addressbook-description Property . . . . . . . 10 6.2.1. CARDDAV:addressbook-description Property . . . . . . . 10
6.2.2. CARDDAV:supported-address-data Property . . . . . . . 10 6.2.2. CARDDAV:supported-address-data Property . . . . . . . 10
6.2.3. CARDDAV:max-resource-size Property . . . . . . . . . . 11 6.2.3. CARDDAV:max-resource-size Property . . . . . . . . . . 11
6.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 12 6.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 12
6.3.1. Extended MKCOL Method . . . . . . . . . . . . . . . . 12 6.3.1. Extended MKCOL Method . . . . . . . . . . . . . . . . 12
6.3.1.1. Example - Successful MKCOL request . . . . . . . . 13 6.3.1.1. Example - Successful MKCOL request . . . . . . . . 13
6.3.2. Creating Address Object Resources . . . . . . . . . . 14 6.3.2. Creating Address Object Resources . . . . . . . . . . 15
6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 15 6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 16
6.3.2.2. Non-Standard vCard Properties, and Parameters . . 16 6.3.2.2. Non-Standard vCard Properties, and Parameters . . 17
6.3.2.3. Address Object Resource Entity Tag . . . . . . . . 17 6.3.2.3. Address Object Resource Entity Tag . . . . . . . . 17
7. Address Book Access Control . . . . . . . . . . . . . . . . . 17 7. Address Book Access Control . . . . . . . . . . . . . . . . . 18
7.1. Additional Principal Properties . . . . . . . . . . . . . 17 7.1. Additional Principal Properties . . . . . . . . . . . . . 18
7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 17 7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 18
7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 18 7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 19
8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 19 8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 20
8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 19 8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Ordinary Collections . . . . . . . . . . . . . . . . . . . 20 8.2. Ordinary Collections . . . . . . . . . . . . . . . . . . . 20
8.3. Searching Text: Collations . . . . . . . . . . . . . . . . 20 8.3. Searching Text: Collations . . . . . . . . . . . . . . . . 20
8.3.1. CARDDAV:supported-collation-set Property . . . . . . . 21 8.3.1. CARDDAV:supported-collation-set Property . . . . . . . 21
8.4. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 22 8.4. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 22
8.5. Non-standard Properties and Parameters . . . . . . . . . . 22 8.5. Non-standard Properties and Parameters . . . . . . . . . . 22
8.6. CARDDAV:addressbook-query Report . . . . . . . . . . . . . 22 8.6. CARDDAV:addressbook-query Report . . . . . . . . . . . . . 23
8.6.1. Limiting Results . . . . . . . . . . . . . . . . . . . 24 8.6.1. Limiting Results . . . . . . . . . . . . . . . . . . . 24
8.6.2. Truncation of Results . . . . . . . . . . . . . . . . 24 8.6.2. Truncation of Results . . . . . . . . . . . . . . . . 25
8.6.3. Example: Partial Retrieval of vCards Matching 8.6.3. Example: Partial Retrieval of vCards Matching
NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 24 NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 25
8.6.4. Example: Partial Retrieval of vCards Matching a 8.6.4. Example: Partial Retrieval of vCards Matching a
Full Name or Email Address . . . . . . . . . . . . . . 26 Full Name or Email Address . . . . . . . . . . . . . . 27
8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 29 8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 30
8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 30 8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 31
8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 32 8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 33
9. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Restrict the Properties Returned . . . . . . . . . . . . . 33 9.1. Restrict the Properties Returned . . . . . . . . . . . . . 34
9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 34 9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 35
9.3. Client Configuration . . . . . . . . . . . . . . . . . . . 34 9.3. Client Configuration . . . . . . . . . . . . . . . . . . . 35
9.4. Finding Other Users' Address Books . . . . . . . . . . . . 35 9.4. Finding Other Users' Address Books . . . . . . . . . . . . 36
10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 35 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36
10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 35 10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 36
10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 36 10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 37
10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 36 10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 37
10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 36 10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 37
10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 38 10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 39
10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 39 10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 39
10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 39 10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 40
10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 40 10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 41
10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 41 10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 42
10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 42 10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 43
10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 42 10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 43
10.6. CARDDAV:limit XML Element . . . . . . . . . . . . . . . . 43 10.6. CARDDAV:limit XML Element . . . . . . . . . . . . . . . . 44
10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 44 10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 44
10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 44 10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 45
11. Service Discovery via SRV Records . . . . . . . . . . . . . . 44 11. Service Discovery via SRV Records . . . . . . . . . . . . . . 45
12. Internationalization Considerations . . . . . . . . . . . . . 45 12. Internationalization Considerations . . . . . . . . . . . . . 46
13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 13. Security Considerations . . . . . . . . . . . . . . . . . . . 46
14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 46 14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 46 14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 47
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
16.1. Normative References . . . . . . . . . . . . . . . . . . . 46 16.1. Normative References . . . . . . . . . . . . . . . . . . . 47
16.2. Informative References . . . . . . . . . . . . . . . . . . 48 16.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. Change History (to be removed prior to Appendix A. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 48 publication as an RFC) . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction and Overview 1. Introduction and Overview
Address books containing contact information are a key component of Address books containing contact information are a key component of
personal information management tools, such as email, calendaring and personal information management tools, such as email, calendaring and
scheduling, and instant messaging clients. To date several protocols scheduling, and instant messaging clients. To date several protocols
have been used for remote access to contact data, including have been used for remote access to contact data, including
Lightweight Directory Access Protocol LDAP [RFC4511], Internet Lightweight Directory Access Protocol (LDAP) [RFC4511], Internet
Message Support Protocol IMSP [IMSP] and Application Configuration Message Support Protocol (IMSP) [IMSP] and Application Configuration
Access Protocol ACAP [RFC2244], together with SyncML used for Access Protocol (ACAP) [RFC2244], together with SyncML used for
synchronization of such data. synchronization of such data.
WebDAV [RFC4918] offers a number of advantages as a framework or WebDAV [RFC4918] offers a number of advantages as a framework or
basis for address book access and management. Most of these basis for address book access and management. Most of these
advantages boil down to a significant reduction in design costs, advantages boil down to a significant reduction in design costs,
implementation costs, interoperability test costs and deployment implementation costs, interoperability test costs and deployment
costs. costs.
The key features of address book support with WebDAV are: The key features of address book support with WebDAV are:
skipping to change at page 5, line 5 skipping to change at page 5, line 5
The key disadvantages of address book support in WebDAV are: The key disadvantages of address book support in WebDAV are:
1. Lack of change notification. Many of the alternative protocols 1. Lack of change notification. Many of the alternative protocols
also lack this ability. However, an extension for push also lack this ability. However, an extension for push
notifications could easily be developed. notifications could easily be developed.
2. Stateless nature of protocol can result in more data being sent 2. Stateless nature of protocol can result in more data being sent
with each transaction to maintain per-user session across with each transaction to maintain per-user session across
requests. requests.
vCard [RFC2426] is a MIME directory profile aimed at encapsulating vCard is a MIME directory profile aimed at encapsulating personal
personal addressing and contact information about people. The addressing and contact information about people. The specification
specification of vCard was originally done by the Versit consortium, of vCard was originally done by the Versit consortium, with a
with a subsequent 3.0 version standardized by the IETF [RFC2426]. subsequent 3.0 version standardized by the IETF [RFC2426]. vCard is
vCard is in wide spread use in email clients and mobile devices as a in wide spread use in email clients and mobile devices as a means of
means of encapsulating address information for transport via email, encapsulating address information for transport via email, or for
or for import/export and synchronization operations. import/export and synchronization operations.
An update to vCard is currently being developed An update to vCard is currently being developed
[I-D.ietf-vcarddav-vcardrev] and is compatible with this [I-D.ietf-vcarddav-vcardrev] and is compatible with this
specification. specification.
2. Conventions 2. Conventions
2.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The term "protected" is used in the Conformance field of property The term "protected" is used in the Conformance field of property
definitions as defined in Section 15 of [RFC4918]. definitions as defined in Section 15 of [RFC4918].
When XML element types in the namespaces "DAV:" and This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section
"urn:ietf:params:xml:ns:carddav" are referenced in this document 3.2) as a purely notational convention. WebDAV request and response
outside of the context of an XML fragment, the string "DAV:" and bodies cannot be validated by a DTD due to the specific extensibility
"CARDDAV:" will be prefixed to the element type names, respectively. rules defined in Section 17 of [RFC4918] and due to the fact that all
XML elements defined by this specification use the XML namespace name
"DAV:". In particular:
2.2. XML Namespaces and Processing 1. element names use the "DAV:" namespace,
Definitions of XML elements in this document use XML element type 2. element ordering is irrelevant unless explicitly stated,
declarations (as found in XML Document Type Declarations), described
in Section 3.2 of [W3C.REC-xml-20060816]. 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 The namespace "urn:ietf:params:xml:ns:carddav" is reserved for the
XML elements defined in this specification, its revisions, and XML elements defined in this specification, its revisions, and
related CardDAV specifications. XML elements defined by individual related CardDAV specifications. XML elements defined by individual
implementations MUST NOT use the "urn:ietf:params:xml:ns:carddav" implementations MUST NOT use the "urn:ietf:params:xml:ns:carddav"
namespace, and instead should use a namespace that they control. namespace, and instead should use a namespace that they control.
The XML declarations used in this document do not include namespace When XML element types in the namespaces "DAV:" and
information. Thus, implementers must not use these declarations as "urn:ietf:params:xml:ns:carddav" are referenced in this document
the only way to create valid CardDAV properties or to validate outside of the context of an XML fragment, the strings "DAV:" and
CardDAV XML element type. Some of the declarations refer to XML "CARDDAV:" will be prefixed to the element types, resposectively.
elements defined by WebDAV [RFC4918] which use the "DAV:" namespace.
Wherever such XML elements appear, they are explicitly prefixed with This document inherits, and sometimes extends, DTD productions from
"DAV:" to avoid confusion. Section 14 of [RFC4918].
Also note that some CardDAV XML element names are identical to WebDAV Also note that some CardDAV XML element names are identical to WebDAV
XML element names, though their namespace differs. Care must be XML element names, though their namespace differs. Care must be
taken not to confuse the two sets of names. taken not to confuse the two sets of names.
Processing of XML by CardDAV clients and servers MUST follow the
rules described in Section 17 of [RFC4918].
3. Requirements Overview 3. Requirements Overview
This section lists what functionality is required of a CardDAV This section lists what functionality is required of a CardDAV
server. To advertise support for CardDAV, a server: server. To advertise support for CardDAV, a server:
o MUST support vCard [RFC2426] as a media type for the address o MUST support vCard [RFC2426] as a media type for the address
object resource format; object resource format;
o MUST support WebDAV Class 3 [RFC4918]; o MUST support WebDAV Class 3 [RFC4918];
o MUST support WebDAV ACL [RFC3744]; o MUST support WebDAV ACL [RFC3744];
o MUST support secure transport as defined in [RFC2818] using TLS o MUST support secure transport as defined in [RFC2818] using TLS
[RFC5246]; [RFC5246];
o MUST support ETags [RFC2616] with additional requirements o MUST support ETags [RFC2616] with additional requirements
specified in Section 6.3.2.3 of this document; specified in Section 6.3.2.3 of this document;
o MUST support all address book REPORTs defined in Section 8 of this o MUST support all address book reports defined in Section 8 of this
document; and document; and
o MUST advertise support on all addressbook collections and address o MUST advertise support on all addressbook collections and address
object resources for the addressbook reports in the DAV:supported- object resources for the address book reports in the DAV:
report-set property, as defined in Versioning Extensions to WebDAV supported-report-set property, as defined in Versioning Extensions
[RFC3253]. to WebDAV [RFC3253].
In addition, a server: In addition, a server:
o SHOULD support the extended MKCOL method o SHOULD support the extended MKCOL method
[I-D.ietf-vcarddav-webdav-mkcol] to create address book [I-D.ietf-vcarddav-webdav-mkcol] to create address book
collections as defined in Section 6.3.1 of this document. collections as defined in Section 6.3.1 of this document.
o SHOULD support the DAV:current-user-principal-URL property as o SHOULD support the DAV:current-user-principal-URL property as
defined in [RFC5397] to give clients a fast way to locate user defined in [RFC5397] to give clients a fast way to locate user
principals. principals.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
be found only in certain sections of the repository (e.g. be found only in certain sections of the repository (e.g.
/addressbooks/user/). Address book features are only required in the /addressbooks/user/). Address book features are only required in the
repository sections that are or contain address objects. So a repository sections that are or contain address objects. So a
repository confining address data to the /carddav/ collection would repository confining address data to the /carddav/ collection would
only need to support the CardDAV required features within that only need to support the CardDAV required features within that
collection. collection.
The CardDAV server is the canonical location for address data and The CardDAV server is the canonical location for address data and
state information. Clients may submit requests to change data or state information. Clients may submit requests to change data or
download data. Clients may store address objects offline and attempt download data. Clients may store address objects offline and attempt
to synchronize at a later time. However, clients MUST be prepared to synchronize at a later time. Address data on the server can
for address data on the server to change between the time of last change between the time of last synchronization and when attempting
synchronization and when attempting an update, as address book an update, as address book collections may be shared and accessible
collections may be shared and accessible via multiple clients. via multiple clients. Entity tags and locking help this work.
Entity tags and other features help this work.
5. Address Book Resources 5. Address Book Resources
5.1. Address Object Resources 5.1. Address Object Resources
This specification uses vCard as the default format for address or This specification uses vCard as the default format for address or
contact information being stored on the server. However, this contact information being stored on the server. However, this
specification does allow other formats for address data provided that specification does allow other formats for address data provided that
the server advertises support for those additional formats as the server advertises support for those additional formats as
described below. The requirements in this section pertain to vCard described below. The requirements in this section pertain to vCard
skipping to change at page 10, line 22 skipping to change at page 10, line 22
collection. collection.
Value: Any text. Value: Any text.
Protected: SHOULD NOT be protected so that users can specify a Protected: SHOULD NOT be protected so that users can specify a
description. description.
COPY/MOVE behavior: This property value SHOULD be preserved in COPY COPY/MOVE behavior: This property value SHOULD be preserved in COPY
and MOVE operations. and MOVE operations.
allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request. request.
Description: This property contains a description of the address Description: This property contains a description of the address
book collection that is suitable for presentation to a user. book collection that is suitable for presentation to a user.
Definition: Definition:
<!ELEMENT addressbook-description (#PCDATA)> <!ELEMENT addressbook-description (#PCDATA)>
<!-- PCDATA value: string --> <!-- PCDATA value: string -->
skipping to change at page 11, line 8 skipping to change at page 11, line 8
Purpose: Specifies what media types are allowed for address object Purpose: Specifies what media types are allowed for address object
resources in an address book collection. resources in an address book collection.
Protected: MUST be protected as it indicates the level of support Protected: MUST be protected as it indicates the level of support
provided by the server. provided by the server.
COPY/MOVE behavior: This property value MUST be preserved in COPY COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations. and MOVE operations.
allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request. request.
Description: The CARDDAV:supported-address-data property is used to Description: The CARDDAV:supported-address-data property is used to
specify the media type supported for the address object resources specify the media type supported for the address object resources
contained in a given address book collection (e.g., vCard version contained in a given address book collection (e.g., vCard version
3.0). Any attempt by the client to store address object resources 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 with a media type not listed in this property MUST result in an
error, with the CARDDAV:supported-address-data precondition error, with the CARDDAV:supported-address-data precondition
(Section 6.3.2.1) being violated. In the absence of this property (Section 6.3.2.1) being violated. In the absence of this property
the server MUST only accept data with the media type "text/vcard" the server MUST only accept data with the media type "text/vcard"
and vCard version 3.0, and clients can assume that. and vCard version 3.0, and clients can assume that.
Definition: Definition:
<!ELEMENT supported-address-data (address-data+)> <!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: Example:
<C:supported-address-data <C:supported-address-data
xmlns:C="urn:ietf:params:xml:ns:carddav"> xmlns:C="urn:ietf:params:xml:ns:carddav">
<C:address-data content-type="text/vcard" version="3.0"/> <C:address-data-type content-type="text/vcard" version="3.0"/>
</C:supported-address-data> </C:supported-address-data>
6.2.3. CARDDAV:max-resource-size Property 6.2.3. CARDDAV:max-resource-size Property
Name: max-resource-size Name: max-resource-size
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Provides a numeric value indicating the maximum size of a Purpose: Provides a numeric value indicating the maximum size in
resource in octets that the server is willing to accept when an octets of a resource that the server is willing to accept when an
address object resource is stored in an address book collection. address object resource is stored in an address book collection.
Value: Any text representing a numeric value. Value: Any text representing a numeric value.
Protected: MUST be protected as it indicates limits provided by the Protected: MUST be protected as it indicates limits provided by the
server. server.
COPY/MOVE behavior: This property value MUST be preserved in COPY COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations. and MOVE operations.
allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request. request.
Description: The CARDDAV:max-resource-size is used to specify a Description: The CARDDAV:max-resource-size is used to specify a
numeric value that represents the maximum size in octets that the numeric value that represents the maximum size in octets that the
server is willing to accept when an address object resource is server is willing to accept when an address object resource is
stored in an address book collection. Any attempt to store an stored in an address book collection. Any attempt to store an
address book object resource exceeding this size MUST result in an address book object resource exceeding this size MUST result in an
error, with the CARDDAV:max-resource-size precondition error, with the CARDDAV:max-resource-size precondition
(Section 6.3.2.1) being violated. In the absence of this property (Section 6.3.2.1) being violated. In the absence of this property
the client can assume that the server will allow storing a the client can assume that the server will allow storing a
skipping to change at page 13, line 6 skipping to change at page 13, line 14
collection as defined in Section 5.2. collection as defined in Section 5.2.
Support for creating address books on the server is only RECOMMENDED Support for creating address books on the server is only RECOMMENDED
and not REQUIRED because some address book stores only support one and not REQUIRED because some address book stores only support one
address book per user (or principal), and those are typically pre- address book per user (or principal), and those are typically pre-
created for each account. However, servers and clients are strongly created for each account. However, servers and clients are strongly
encouraged to support address book creation whenever possible to encouraged to support address book creation whenever possible to
allow users to create multiple address book collections to help allow users to create multiple address book collections to help
organize their data better. organize their data better.
Clients SHOULD use the DAV:displayname property for a human-readable The DAV:displayname property can be used for a human-readable name of
name of the address book. Clients can either specify the value of the address book. Clients can either specify the value of the DAV:
the DAV:displayname property in the request body of the extended displayname property in the request body of the extended MKCOL
MKCOL request, or alternatively issue a PROPPATCH request to change request, or alternatively issue a PROPPATCH request to change the
the DAV:displayname property to the appropriate value immediately DAV:displayname property to the appropriate value immediately after
after using the extended MKCOL request. Clients SHOULD NOT set the using the extended MKCOL request. When displaying address book
DAV:displayname property to be the same as any other address book
collection at the same URI "level". When displaying address book
collections to users, clients SHOULD check the DAV:displayname collections to users, clients SHOULD check the DAV:displayname
property and use that value as the name of the address book. In the 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 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, use the last part of the address book collection URI as the name,
however that path segment may be "opaque" and not represent any however that path segment may be "opaque" and not represent any
meaningful human-readable text. meaningful human-readable text.
6.3.1.1. Example - Successful MKCOL request 6.3.1.1. Example - Successful MKCOL request
This example creates an address book collection called /home/lisa/ This example creates an address book collection called /home/lisa/
skipping to change at page 15, line 27 skipping to change at page 16, line 4
ADR;TYPE=POSTAL:;2822 Email HQ;Suite 2821;RFCVille;PA;15213;USA ADR;TYPE=POSTAL:;2822 Email HQ;Suite 2821;RFCVille;PA;15213;USA
EMAIL;TYPE=INTERNET,PREF:cyrus@example.com EMAIL;TYPE=INTERNET,PREF:cyrus@example.com
NICKNAME:me NICKNAME:me
NOTE:Example VCard. NOTE:Example VCard.
ORG:Self Employed ORG:Self Employed
TEL;TYPE=WORK,VOICE:412 605 0499 TEL;TYPE=WORK,VOICE:412 605 0499
TEL;TYPE=FAX:412 605 0705 TEL;TYPE=FAX:412 605 0705
URL:http://www.example.com URL:http://www.example.com
UID:1234-5678-9000-1 UID:1234-5678-9000-1
END:VCARD END:VCARD
>> Response << >> Response <<
HTTP/1.1 201 Created HTTP/1.1 201 Created
Date: Thu, 02 Sep 2004 16:53:32 GMT Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Length: 0 Content-Length: 0
ETag: "123456789-000-111" ETag: "123456789-000-111"
The request to change an existing address object resource is the The request to change an existing address object resource without
same, but with a specific ETag in the "If-Match" header, rather than overwriting a change made on the server, uses a specific ETag in an
the "If-None-Match" header. "If-Match" header, rather than the "If-None-Match" header.
File names for vCards are commonly suffixed by ".vcf", and clients File names for vCards are commonly suffixed by ".vcf", and clients
may choose to use the same convention for URLs. may choose to use the same convention for URLs.
6.3.2.1. Additional Preconditions for PUT, COPY and MOVE 6.3.2.1. Additional Preconditions for PUT, COPY and MOVE
This specification creates additional Preconditions for PUT, COPY and This specification creates additional Preconditions for PUT, COPY and
MOVE methods. These preconditions apply: MOVE methods. These preconditions apply:
o When a PUT operation of an address object resource into an address o When a PUT operation of an address object resource into an address
skipping to change at page 16, line 25 skipping to change at page 17, line 4
(CARDDAV:no-uid-conflict): The resource submitted in the PUT (CARDDAV:no-uid-conflict): The resource submitted in the PUT
request, or targeted by a COPY or MOVE request MUST NOT specify a request, or targeted by a COPY or MOVE request MUST NOT specify a
vCard UID property value already in use in the targeted address vCard UID property value already in use in the targeted address
book collection or overwrite an existing address object resource book collection or overwrite an existing address object resource
with one that has a different UID property value. Servers SHOULD with one that has a different UID property value. Servers SHOULD
report the URL of the resource that is already making use of the report the URL of the resource that is already making use of the
same UID property value in the DAV:href element; same UID property value in the DAV:href element;
<!ELEMENT no-uid-conflict (DAV:href)> <!ELEMENT no-uid-conflict (DAV:href)>
(CARDDAV:addressbook-collection-location-ok): In a COPY or MOVE (CARDDAV:addressbook-collection-location-ok): In a COPY or MOVE
request, when the Request-URI is an address book collection, the request, when the Request-URI is an address book collection, the
URI targeted by the Destination HTTP Request header MUST identify URI targeted by the Destination HTTP Request header MUST identify
a location where an address book collection can be created; a location where an address book collection can be created;
(CARDDAV:max-resource-size): The resource submitted in the PUT (CARDDAV:max-resource-size): The resource submitted in the PUT
request, or targeted by a COPY or MOVE request MUST have an octet request, or targeted by a COPY or MOVE request MUST have a size in
size less than or equal to the value of the CARDDAV:max-resource- octets less than or equal to the value of the CARDDAV:max-
size property value (Section 6.2.3) on the address book collection resource-size property value (Section 6.2.3) on the address book
where the resource will be stored; collection where the resource will be stored;
6.3.2.2. Non-Standard vCard Properties, and Parameters 6.3.2.2. Non-Standard vCard Properties, and Parameters
vCard provides a "standard mechanism for doing non-standard things". vCard provides a "standard mechanism for doing non-standard things".
This extension support allows implementers to make use of non- This extension support allows implementers to make use of non-
standard properties and parameters whose names are prefixed with the standard vCard properties and parameters whose names are prefixed
text "X-". with the text "X-".
Servers MUST support the use of non-standard properties and Servers MUST support the use of non-standard properties and
parameters in address object resources stored via the PUT method. parameters in address object resources stored via the PUT method.
Servers may need to enforce rules for their own "private" properties Servers may need to enforce rules for their own "private" properties
or parameters, so servers MAY reject any attempt by the client to or parameters, so servers MAY reject any attempt by the client to
change those or use values for those outside of any restrictions the change those or use values for those outside of any restrictions the
server may have. Servers SHOULD ensure that any "private" properties server may have. Servers SHOULD ensure that any "private" properties
or parameters it uses follow the convention of including a vendor id or parameters it uses follow the convention of including a vendor id
in the "X-" name, as described in Section 3.8 of [RFC2426], e.g., in the "X-" name, as described in Section 3.8 of [RFC2426], e.g.,
skipping to change at page 18, line 37 skipping to change at page 19, line 13
descendant address book collections owned by the principal. descendant address book collections owned by the principal.
Definition: Definition:
<!ELEMENT addressbook-home-set (DAV:href*)> <!ELEMENT addressbook-home-set (DAV:href*)>
Example: Example:
<C:addressbook-home-set xmlns:D="DAV:" <C:addressbook-home-set xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav"> xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:href>http://addressbook.example.com/bernard/addresses/< <D:href>/bernard/addresses/</D:href>
/D:href>
</C:addressbook-home-set> </C:addressbook-home-set>
7.1.2. CARDDAV:principal-address Property 7.1.2. CARDDAV:principal-address Property
Name: principal-address Name: principal-address
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Identifies the URL of an address object resource that Purpose: Identifies the URL of an address object resource that
corresponds to the user represented by the principal. corresponds to the user represented by the principal.
Protected: MAY be protected if the server provides a fixed location Protected: MAY be protected if the server provides a fixed location
for principal addresses. for principal addresses.
COPY/MOVE behavior: This property value MUST be preserved in COPY COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations. and MOVE operations.
allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request. request.
Description: The CARDDAV:principal-address property is meant to Description: The CARDDAV:principal-address property is meant to
allow users to easily find contact information for users allow users to easily find contact information for users
represented by principals on the system. This property specifies represented by principals on the system. This property specifies
the URL of the resource containing the corresponding contact the URL of the resource containing the corresponding contact
information. The resource could be an address object resource in information. The resource could be an address object resource in
an address book collection, or it could be a resource in a an address book collection, or it could be a resource in a
"regular" collection. "regular" collection.
Definition: Definition:
<!ELEMENT principal-address (DAV:href)> <!ELEMENT principal-address (DAV:href)>
Example: Example:
<C:principal-address xmlns:D="DAV:" <C:principal-address xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav"> xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:href>http://addressbook.example.com/system/cyrus.vcf< <D:href>/system/cyrus.vcf</D:href>
/D:href>
</C:principal-address> </C:principal-address>
8. Address Book Reports 8. Address Book Reports
This section defines the reports that CardDAV servers MUST support on This section defines the reports that CardDAV servers MUST support on
address book collections and address object resources. address book collections and address object resources.
CardDAV servers MUST advertise support for these REPORTs on all CardDAV servers MUST advertise support for these reports on all
address book collections and address object resources with the DAV: address book collections and address object resources with the DAV:
supported-report-set property defined in Section 3.1.5 of [RFC3253]. supported-report-set property defined in Section 3.1.5 of [RFC3253].
CardDAV servers MAY also advertise support for these REPORTs on CardDAV servers MAY also advertise support for these reports on
ordinary collections. ordinary collections.
Some of these REPORTs allow address data (from possibly multiple Some of these reports allow address data (from possibly multiple
resources) to be returned. resources) to be returned.
8.1. REPORT Method 8.1. REPORT Method
The REPORT method (defined in Section 3.6 of [RFC3253]) provides an The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
extensible mechanism for obtaining information about a resource. extensible mechanism for obtaining information about a resource.
Unlike the PROPFIND method, which returns the value of one or more Unlike the PROPFIND method, which returns the value of one or more
named properties, the REPORT method can involve more complex named properties, the REPORT method can involve more complex
processing. REPORT is valuable in cases where the server has access processing. REPORT is valuable in cases where the server has access
to all of the information needed to perform the complex request (such to all of the information needed to perform the complex request (such
as a query), and where it would require multiple requests for the as a query), and where it would require multiple requests for the
client to retrieve the information needed to perform the same client to retrieve the information needed to perform the same
request. request.
A server that supports this specification MUST support the DAV: A server that supports this specification MUST support the DAV:
expand-property report (defined in Section 3.8 of [RFC3253]). expand-property report (defined in Section 3.8 of [RFC3253]).
skipping to change at page 20, line 18 skipping to change at page 20, line 36
to all of the information needed to perform the complex request (such to all of the information needed to perform the complex request (such
as a query), and where it would require multiple requests for the as a query), and where it would require multiple requests for the
client to retrieve the information needed to perform the same client to retrieve the information needed to perform the same
request. request.
A server that supports this specification MUST support the DAV: A server that supports this specification MUST support the DAV:
expand-property report (defined in Section 3.8 of [RFC3253]). expand-property report (defined in Section 3.8 of [RFC3253]).
8.2. Ordinary Collections 8.2. Ordinary Collections
Servers MAY support the REPORTs defined in this document on ordinary Servers MAY support the reports defined in this document on ordinary
collections (collections that are not address book collections) in collections (collections that are not address book collections) in
addition to address book collections or address object resources. In addition to address book collections or address object resources. In
computing responses to the REPORTs on ordinary collections, servers computing responses to the reports on ordinary collections, servers
MUST only consider address object resources contained in address book MUST only consider address object resources contained in address book
collections that are targeted by the REPORT based on the value of the collections that are targeted by the REPORT based on the value of the
Depth request header. Depth request header.
8.3. Searching Text: Collations 8.3. Searching Text: Collations
Some of the reports defined in this section do text matches of Some of the reports defined in this section do text matches of
character strings provided by the client and compared to stored character strings provided by the client and compared to stored
address data. Since vCard data is by default encoded in the UTF-8 address data. Since vCard data is by default encoded in the UTF-8
charset and may include characters outside of the US-ASCII charset charset and may include characters outside of the US-ASCII charset
skipping to change at page 21, line 32 skipping to change at page 22, line 5
Purpose: Identifies the set of collations supported by the server Purpose: Identifies the set of collations supported by the server
for text matching operations. for text matching operations.
Protected: MUST be protected as it indicates support provided by the Protected: MUST be protected as it indicates support provided by the
server. server.
COPY/MOVE behavior: This property value MUST be preserved in COPY COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations. and MOVE operations.
allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request. request.
Description: The CARDDAV:supported-collation-set property contains Description: The CARDDAV:supported-collation-set property contains
zero or more CARDDAV:supported-collation elements which specify zero or more CARDDAV:supported-collation elements which specify
the collection identifiers of the collations supported by the the collection identifiers of the collations supported by the
server. server.
Definition: Definition:
<!ELEMENT supported-collation-set (supported-collation*)> <!ELEMENT supported-collation-set (supported-collation*)>
skipping to change at page 22, line 8 skipping to change at page 22, line 30
<C:supported-collation-set <C:supported-collation-set
xmlns:C="urn:ietf:params:xml:ns:carddav"> xmlns:C="urn:ietf:params:xml:ns:carddav">
<C:supported-collation>i;ascii-casemap</C:supported-collation> <C:supported-collation>i;ascii-casemap</C:supported-collation>
<C:supported-collation>i;octet</C:supported-collation> <C:supported-collation>i;octet</C:supported-collation>
<C:supported-collation>i;unicode-casemap</C:supported-collation> <C:supported-collation>i;unicode-casemap</C:supported-collation>
</C:supported-collation-set> </C:supported-collation-set>
8.4. Partial Retrieval 8.4. Partial Retrieval
Some address book REPORTs defined in this document allow partial Some address book reports defined in this document allow partial
retrieval of address object resources. A CardDAV client can specify retrieval of address object resources. A CardDAV client can specify
what information to return in the body of an address book REPORT what information to return in the body of an address book REPORT
request. request.
A CardDAV client can request particular WebDAV property values, all A CardDAV client can request particular WebDAV property values, all
WebDAV property values, or a list of the names of the resource's WebDAV property values, or a list of the names of the resource's
WebDAV properties. A CardDAV client can also request address data to WebDAV properties. A CardDAV client can also request address data to
be returned and whether all vCard properties should be returned or be returned and whether all vCard properties should be returned or
only particular ones. See CARDDAV:address-data in Section 10.4. only particular ones. See CARDDAV:address-data in Section 10.4.
8.5. Non-standard Properties and Parameters 8.5. Non-standard Properties and Parameters
Servers MUST support the use of non-standard property or parameter Servers MUST support the use of non-standard vCard property or
names in the CARDDAV:address-data XML element in address book REPORT parameter names in the CARDDAV:address-data XML element in address
requests to allow clients to request that non-standard properties and book REPORT requests to allow clients to request that non-standard
parameters be returned in the address data provided in the response. properties and parameters be returned in the address data provided in
the response.
Servers MAY support the use of non-standard property or parameter Servers MAY support the use of non-standard vCard property or
names in the CARDDAV:prop-filter and CARDDAV:param-filter XML parameter names in the CARDDAV:prop-filter and CARDDAV:param-filter
elements specified in the CARDDAV:filter XML element of address book XML elements specified in the CARDDAV:filter XML element of address
REPORT requests. book REPORT requests.
Servers MUST fail with the CARDDAV:supported-filter precondition if Servers MUST fail with the CARDDAV:supported-filter precondition if
an address book REPORT request uses a CARDDAV:prop-filter or CARDDAV: an address book REPORT request uses a CARDDAV:prop-filter or CARDDAV:
param-filter XML element that makes reference to a non-standard param-filter XML element that makes reference to a non-standard vCard
property or parameter name which the server does not support queries property or parameter name which the server does not support queries
on. on.
8.6. CARDDAV:addressbook-query Report 8.6. CARDDAV:addressbook-query Report
The CARDDAV:addressbook-query REPORT performs a search for all The CARDDAV:addressbook-query REPORT performs a search for all
address object resources that match a specified filter. The response address object resources that match a specified filter. The response
of this REPORT will contain all the WebDAV properties and address of this report will contain all the WebDAV properties and address
object resource data specified in the request. In the case of the object resource data specified in the request. In the case of the
CARDDAV:address-data XML element, one can explicitly specify the CARDDAV:address-data XML element, one can explicitly specify the
vCard properties that should be returned in the address object vCard properties that should be returned in the address object
resource data that matches the filter. resource data that matches the filter.
The format of this report is modeled on the PROPFIND method. The The format of this report is modeled on the PROPFIND method. The
request and response bodies of the CARDAV:addressbook-query report request and response bodies of the CARDAV:addressbook-query report
use XML elements that are also used by PROPFIND. In particular the use XML elements that are also used by PROPFIND. In particular the
request can include XML elements to request WebDAV properties to be request can include XML elements to request WebDAV properties to be
returned. When that occurs the response should follow the same returned. When that occurs the response should follow the same
behavior as PROPFIND with respect to the DAV:multistatus response behavior as PROPFIND with respect to the DAV:multistatus response
elements used to return specific property results. For instance, a elements used to return specific WebDAV property results. For
request to retrieve the value of a property which does not exist is instance, a request to retrieve the value of a WebDAV property which
an error and MUST be noted with a response XML element which contains does not exist is an error and MUST be noted with a response XML
a 404 (Not Found) status value. element which contains a 404 (Not Found) status value.
Support for the CARDDAV:addressbook-query REPORT is REQUIRED. Support for the CARDDAV:addressbook-query REPORT is REQUIRED.
Marshalling: Marshalling:
The request body MUST be a CARDDAV:addressbook-query XML element The request body MUST be a CARDDAV:addressbook-query XML element
as defined in Section 10.3. as defined in Section 10.3.
The request MAY include a Depth header. If no Depth header is The request MUST include a Depth header. The scope of the query
included, Depth:0 is assumed. is determined by the value of the Depth header. e.g., to query all
address object resources in an address book collection, the REPORT
would use the address book collection as the request-URI and
specify a Depth of 1 or infinity.
The response body for a successful request MUST be a DAV: The response body for a successful request MUST be a DAV:
multistatus XML element (i.e., the response uses the same format multistatus XML element (i.e., the response uses the same format
as the response for PROPFIND). In the case where there are no as the response for PROPFIND). In the case where there are no
response elements, the returned DAV:multistatus XML element is response elements, the returned DAV:multistatus XML element is
empty. empty.
The response body for a successful CARDDAV:addressbook-query The response body for a successful CARDDAV:addressbook-query
REPORT request MUST contain a DAV:response element for each REPORT request MUST contain a DAV:response element for each
address object that matched the search filter. address data is address object that matched the search filter. address data is
skipping to change at page 23, line 42 skipping to change at page 24, line 18
Preconditions: Preconditions:
(CARDDAV:supported-address-data): The attributes "content-type" (CARDDAV:supported-address-data): The attributes "content-type"
and "version" of the CARDDAV:address-data XML element (see and "version" of the CARDDAV:address-data XML element (see
Section 10.4) specify a media type supported by the server for Section 10.4) specify a media type supported by the server for
address object resources. address object resources.
(CARDDAV:supported-filter): The CARDDAV:prop-filter (see (CARDDAV:supported-filter): The CARDDAV:prop-filter (see
Section 10.5.1) and CARDDAV:param-filter (see Section 10.5.2) XML Section 10.5.1) and CARDDAV:param-filter (see Section 10.5.2) XML
elements used in the CARDDAV:filter XML element (see Section 10.5) elements used in the CARDDAV:filter XML element (see Section 10.5)
in the REPORT request only make reference to properties and in the REPORT request only make reference to vCard properties and
parameters for which queries are supported by the server. i.e., if parameters for which queries are supported by the server. i.e., if
the CARDDAV:filter element attempts to reference an unsupported the CARDDAV:filter element attempts to reference an unsupported
property or parameter, this precondition is violated. Servers vCard property or parameter, this precondition is violated.
SHOULD report the CARDDAV:prop-filter or CARDDAV:param-filter for Servers SHOULD report the CARDDAV:prop-filter or CARDDAV:param-
which it does not provide support. filter for which it does not provide support.
<!ELEMENT supported-filter (prop-filter*, <!ELEMENT supported-filter (prop-filter*,
param-filter*)> param-filter*)>
(CARDDAV:supported-collation): Any XML attribute specifying a (CARDDAV:supported-collation): Any XML attribute specifying a
collation MUST specify a collation supported by the server as collation MUST specify a collation supported by the server as
described in Section 8.3. described in Section 8.3.
Postconditions: Postconditions:
(DAV:number-of-matches-within-limits): The number of matching (DAV:number-of-matches-within-limits): The number of matching
address object resources must fall within server-specific, address object resources must fall within server-specific,
predefined limits. For example, this condition might be triggered predefined limits. For example, this condition might be triggered
if a search specification would cause the return of an extremely if a search specification would cause the return of an extremely
skipping to change at page 31, line 12 skipping to change at page 32, line 12
similar to the CARDDAV:addressbook-query REPORT (see Section 8.6), similar to the CARDDAV:addressbook-query REPORT (see Section 8.6),
except that it takes a list of DAV:href elements instead of a except that it takes a list of DAV:href elements instead of a
CARDDAV:filter element to determine which address object resources to CARDDAV:filter element to determine which address object resources to
return. return.
Support for the addressbook-multiget REPORT is REQUIRED. Support for the addressbook-multiget REPORT is REQUIRED.
Marshalling: Marshalling:
The request body MUST be a CARDDAV:addressbook-multiget XML The request body MUST be a CARDDAV:addressbook-multiget XML
element (see Section 10.7, which MUST contain at least one DAV: element (see Section 10.7), which MUST contain at least one DAV:
href XML element, and one optional CARDDAV:address-data element as href XML element, and one optional CARDDAV:address-data element as
defined in Section 10.4. If the Request-URI is a collection defined in Section 10.4. If DAV:href elements are present, the
resource, then the DAV:href elements MUST refer to resources scope of the request is the set of resources identified by these
within that collection, and they MAY refer to resources at any elements, which all need to be members (not necessarily internal
depth within the collection. As a result the "Depth" header MUST members) of the resource identified by the Request-URI.
be ignored by the server and SHOULD NOT be sent by the client. If Otherwise, the scope is the resource identified by the Request-URI
the Request-URI refers to a non-collection resource, then there itself.
MUST be a single DAV:href element that is equivalent to the
Request-URI. The request MUST include a Depth: 0 header, however the actual
scope of the REPORT is determined as described above.
The response body for a successful request MUST be a DAV: The response body for a successful request MUST be a DAV:
multistatus XML element. multistatus XML element.
The response body for a successful CARDDAV:addressbook-multiget The response body for a successful CARDDAV:addressbook-multiget
REPORT request MUST contain a DAV:response element for each REPORT request MUST contain a DAV:response element for each
address object resource referenced by the provided set of DAV:href address object resource referenced by the provided set of DAV:href
elements. Address data is returned in the CARDDAV:address-data elements. Address data is returned in the CARDDAV:address-data
element inside the DAV:prop element. element inside the DAV:prop element.
skipping to change at page 32, line 8 skipping to change at page 33, line 8
Section 10.4) specify a media type supported by the server for Section 10.4) specify a media type supported by the server for
address object resources. address object resources.
Postconditions: Postconditions:
None. None.
8.7.1. Example: CARDDAV:addressbook-multiget Report 8.7.1. Example: CARDDAV:addressbook-multiget Report
In this example, the client requests the server to return specific In this example, the client requests the server to return specific
properties of the address components referenced by specific URIs. In vCard properties of the address components referenced by specific
addition the DAV:getetag property is also requested and returned as URIs. In addition the DAV:getetag property is also requested and
part of the response. Note that in this example, the resource at returned as part of the response. Note that in this example, the
resource at
http://addressbook.example.com/home/bernard/addressbook/vcf1.vcf does http://addressbook.example.com/home/bernard/addressbook/vcf1.vcf does
not exist, resulting in an error status response. not exist, resulting in an error status response.
>> Request << >> Request <<
REPORT /home/bernard/addressbook/ HTTP/1.1 REPORT /home/bernard/addressbook/ HTTP/1.1
Host: addressbook.example.com Host: addressbook.example.com
Depth: 1
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<C:addressbook-multiget xmlns:D="DAV:" <C:addressbook-multiget xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav"> xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:prop> <D:prop>
<D:getetag/> <D:getetag/>
<C:address-data> <C:address-data>
<C:prop name="VERSION"/> <C:prop name="VERSION"/>
skipping to change at page 36, line 50 skipping to change at page 37, line 50
DAV:prop)?, filter, limit?)> DAV:prop)?, filter, limit?)>
10.4. CARDDAV:address-data XML Element 10.4. CARDDAV:address-data XML Element
Name: address-data Name: address-data
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Specifies one of the following: Purpose: Specifies one of the following:
1. A supported media type for address object resources when 1. The parts of an address object resource which should be
nested in the CARDDAV:supported-address-data property; returned by a given address book REPORT request, and the media
2. The parts of an address object resource should be returned by type and version for the returned data;
a given address book REPORT; 2. The content of an address object resource in a response to an
address book REPORT request.
3. The content of an address object resource in a response to an
address book REPORT.
Description: When nested in the CARDDAV:supported-address-data
property, the CARDDAV:address-data XML element specifies a media
type supported by the CardDAV server for address object resources.
When used in an address book REPORT request, the CARDDAV:address- Description: When used in an address book REPORT request, the
data XML element specifies which parts of address object resources CARDDAV:address-data XML element specifies which parts of address
need to be returned in the response. If the CARDDAV:address-data object resources need to be returned in the response. If the
XML element doesn't contain any CARDDAV:prop elements, address CARDDAV:address-data XML element doesn't contain any CARDDAV:prop
object resources will be returned in their entirety. elements, address object resources will be returned in their
entirety. Additionally a media type and version can be specified
to request that the server return the data in that format if
possible.
Finally, when used in an address book REPORT response, the Finally, when used in an address book REPORT response, the
CARDDAV:address-data XML element specifies the content of a CARDDAV:address-data XML element specifies the content of a
address object resource. Given that XML parsers normalize the address object resource. Given that XML parsers normalize the
two-character sequence CRLF (US-ASCII decimal 13 and US-ASCII two-character sequence CRLF (US-ASCII decimal 13 and US-ASCII
decimal 10) to a single LF character (US-ASCII decimal 10), the CR decimal 10) to a single LF character (US-ASCII decimal 10), the CR
character (US-ASCII decimal 13) MAY be omitted in address object character (US-ASCII decimal 13) MAY be omitted in address object
resources specified in the CARDDAV:address-data XML element. resources specified in the CARDDAV:address-data XML element.
Furthermore, address object resources specified in the CARDDAV: Furthermore, address object resources specified in the CARDDAV:
address-data XML element MAY be invalid per their media type address-data XML element MAY be invalid per their media type
specification if the CARDAV:address-data XML element part of the specification if the CARDAV:address-data XML element part of the
address book REPORT request did not specify required properties address book REPORT request did not specify required vCard
(e.g., UID, etc.) or specified a CARDDAV:prop XML element with the properties (e.g., UID, etc.) or specified a CARDDAV:prop XML
"novalue" attribute set to "yes". element with the "novalue" attribute set to "yes".
Note: The CARDDAV:address-data XML element is specified in requests Note: The CARDDAV:address-data XML element is specified in requests
and responses inside the DAV:prop XML element as if it were a and responses inside the DAV:prop XML element as if it were a
WebDAV property. However, the CARDDAV:address-data XML element is WebDAV property. However, the CARDDAV:address-data XML element is
not a WebDAV property and as such it is not returned in PROPFIND not a WebDAV property and as such it is not returned in PROPFIND
responses nor used in PROPPATCH requests. responses nor used in PROPPATCH requests.
Note: The address data embedded within the CARDDAV:address-data XML Note: The address data embedded within the CARDDAV:address-data XML
element MUST follow the standard XML character data encoding element MUST follow the standard XML character data encoding
rules, including use of &lt;, &gt;, &amp; etc entity encoding or rules, including use of &lt;, &gt;, &amp; etc entity encoding or
the use of a <![CDATA[ ... ]]> construct. In the later case the the use of a <![CDATA[ ... ]]> construct. In the later case the
vCard data cannot contain the character sequence "]]>" which is vCard data cannot contain the character sequence "]]>" which is
the end delimiter for the CDATA section. the end delimiter for the CDATA section.
Definition: Definition:
<!ELEMENT address-data EMPTY>
when nested in the CARDDAV:supported-address-data property
to specify a supported media type for address object
resources;
<!ELEMENT address-data (allprop | prop*)> <!ELEMENT address-data (allprop | prop*)>
when nested in the DAV:prop XML element in an addressbook when nested in the DAV:prop XML element in an addressbook
REPORT request to specify which parts of address object REPORT request to specify which parts of address object
resources should be returned in the response; resources should be returned in the response;
<!ELEMENT address-data (#PCDATA)> <!ELEMENT address-data (#PCDATA)>
<!-- PCDATA value: address data --> <!-- PCDATA value: address data -->
when nested in the DAV:prop XML element in an addressbook when nested in the DAV:prop XML element in an addressbook
REPORT response to specify the content of a returned REPORT response to specify the content of a returned
address object resource. address object resource.
<!ATTLIST address-data content-type CDATA "text/vcard" <!ATTLIST address-data content-type CDATA "text/vcard"
version CDATA "3.0"> version CDATA "3.0">
<!-- content-type value: a MIME media type --> <!-- content-type value: a MIME media type -->
<!-- version value: a version string --> <!-- version value: a version string -->
attributes can be used on all three variants of the attributes can be used on each variant of the
CALDAV:address-data XML element. CALDAV:address-data XML element.
10.4.1. CARDDAV:allprop XML Element 10.4.1. CARDDAV:allprop XML Element
Name: allprop Name: allprop
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Specifies that all properties shall be returned. Purpose: Specifies that all vCard properties shall be returned.
Description: This element can be used when the client wants all Description: This element can be used when the client wants all
properties of components returned by a report. vCard properties of components returned by a report.
Definition: Definition:
<!ELEMENT allprop EMPTY> <!ELEMENT allprop EMPTY>
NOTE: The CARDDAV:allprop element defined here has the same name as NOTE: The CARDDAV:allprop element defined here has the same name as
the DAV:allprop element defined in WebDAV. However, the CARDDAV: the DAV:allprop element defined in WebDAV. However, the CARDDAV:
allprop element defined here uses the allprop element defined here uses the
"urn:ietf:params:xml:ns:carddav" namespace, as opposed to the "DAV:" "urn:ietf:params:xml:ns:carddav" namespace, as opposed to the "DAV:"
namespace used for the DAV:allprop element defined in WebDAV. namespace used for the DAV:allprop element defined in WebDAV.
skipping to change at page 39, line 6 skipping to change at page 40, line 4
<!ELEMENT allprop EMPTY> <!ELEMENT allprop EMPTY>
NOTE: The CARDDAV:allprop element defined here has the same name as NOTE: The CARDDAV:allprop element defined here has the same name as
the DAV:allprop element defined in WebDAV. However, the CARDDAV: the DAV:allprop element defined in WebDAV. However, the CARDDAV:
allprop element defined here uses the allprop element defined here uses the
"urn:ietf:params:xml:ns:carddav" namespace, as opposed to the "DAV:" "urn:ietf:params:xml:ns:carddav" namespace, as opposed to the "DAV:"
namespace used for the DAV:allprop element defined in WebDAV. namespace used for the DAV:allprop element defined in WebDAV.
10.4.2. CARDDAV:prop XML Element 10.4.2. CARDDAV:prop XML Element
Name: prop Name: prop
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Defines which properties to return in the response. Purpose: Defines which vCard properties to return in the response.
Description: The "name" attribute specifies the name of the vCard Description: The "name" attribute specifies the name of the vCard
property to return (e.g., "NICKNAME"). The "novalue" attribute property to return (e.g., "NICKNAME"). The "novalue" attribute
can be used by clients to request that the actual value of the can be used by clients to request that the actual value of the
property not be returned (if the "novalue" attribute is set to property not be returned (if the "novalue" attribute is set to
"yes"). In that case the server will return just the vCard "yes"). In that case the server will return just the vCard
property name and any vCard parameters and a trailing ":" without property name and any vCard parameters and a trailing ":" without
the subsequent value data. the subsequent value data.
vCard allows a "group" prefix to appear before a property name in vCard allows a "group" prefix to appear before a property name in
skipping to change at page 40, line 4 skipping to change at page 40, line 46
NOTE: The CARDDAV:prop element defined here has the same name as the NOTE: The CARDDAV:prop element defined here has the same name as the
DAV:prop element defined in WebDAV. However, the CARDDAV:prop DAV:prop element defined in WebDAV. However, the CARDDAV:prop
element defined here uses the "urn:ietf:params:xml:ns:carddav" element defined here uses the "urn:ietf:params:xml:ns:carddav"
namespace, as opposed to the "DAV:" namespace used for the DAV:prop namespace, as opposed to the "DAV:" namespace used for the DAV:prop
element defined in WebDAV. element defined in WebDAV.
10.5. CARDDAV:filter XML Element 10.5. CARDDAV:filter XML Element
Name: filter Name: filter
Namespace: urn:ietf:params:xml:ns:carddav
Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Determines which matching objects are returned. Purpose: Determines which matching objects are returned.
Description: The "filter" element specifies the search filter used Description: The "filter" element specifies the search filter used
to match address objects that should be returned by a report. The to match address objects that should be returned by a report. The
"test" attribute specifies whether any (logical OR) or all "test" attribute specifies whether any (logical OR) or all
(logical AND) of the prop-filter tests needs to match in order for (logical AND) of the prop-filter tests needs to match in order for
the overall filter to match. the overall filter to match.
Definition: Definition:
skipping to change at page 40, line 29 skipping to change at page 41, line 27
<!-- test value: <!-- test value:
anyof logical OR for prop-filter matches anyof logical OR for prop-filter matches
allof logical AND for prop-filter matches --> allof logical AND for prop-filter matches -->
10.5.1. CARDDAV:prop-filter XML Element 10.5.1. CARDDAV:prop-filter XML Element
Name: prop-filter Name: prop-filter
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Limits the search to specific properties. Purpose: Limits the search to specific vCard properties.
Description: The CARDDAV:prop-filter XML element specifies a search Description: The CARDDAV:prop-filter XML element specifies a search
criteria on a specific vCard property (e.g., NICKNAME). An criteria on a specific vCard property (e.g., NICKNAME). An
address object is said to match a CARDDAV:prop-filter if: address object is said to match a CARDDAV:prop-filter if:
* A property of the type specified by the "name" attribute * A vCard property of the type specified by the "name" attribute
exists, and the CARDDAV:prop-filter is empty, or it matches any exists, and the CARDDAV:prop-filter is empty, or it matches any
CARDDAV:text-match conditions if specified, and that CARDDAV: CARDDAV:text-match conditions if specified, and that CARDDAV:
param-filter child elements also match. The "test" attribute param-filter child elements also match. The "test" attribute
specifies whether any (logical OR) or all (logical AND) of the specifies whether any (logical OR) or all (logical AND) of the
text-filter and param-filter tests need to match in order for text-filter and param-filter tests need to match in order for
the overall filter to match. the overall filter to match.
or: or:
* A property of the type specified by the "name" attribute does * A vCard property of the type specified by the "name" attribute
not exist, and the CARDAV:is-not-defined element is specified. does not exist, and the CARDAV:is-not-defined element is
specified.
vCard allows a "group" prefix to appear before a property name in vCard allows a "group" prefix to appear before a property name in
the vCard data. When the "name" attribute does not specify a the vCard data. When the "name" attribute does not specify a
group prefix, it MUST match properties in the vCard data without a group prefix, it MUST match properties in the vCard data without a
group prefix or with any group prefix. When the "name" attribute group prefix or with any group prefix. When the "name" attribute
includes a group prefix, it MUST match properties that have includes a group prefix, it MUST match properties that have
exactly the same group prefix and name. e.g.: a "name" set to exactly the same group prefix and name. e.g.: a "name" set to
"TEL" will match "TEL", "X-ABC.TEL", "X-ABC-1.TEL" vCard "TEL" will match "TEL", "X-ABC.TEL", "X-ABC-1.TEL" vCard
properties. A "name" set to "X-ABC.TEL" will match an "X-ABC.TEL" properties. A "name" set to "X-ABC.TEL" will match an "X-ABC.TEL"
vCard property only, it will not match "TEL" or "X-ABC-1.TEL". vCard property only, it will not match "TEL" or "X-ABC-1.TEL".
skipping to change at page 42, line 18 skipping to change at page 43, line 11
<!ATTLIST param-filter name CDATA #REQUIRED> <!ATTLIST param-filter name CDATA #REQUIRED>
<!-- name value: a property parameter name (e.g., "TYPE") --> <!-- name value: a property parameter name (e.g., "TYPE") -->
10.5.3. CARDDAV:is-not-defined XML Element 10.5.3. CARDDAV:is-not-defined XML Element
Name: is-not-defined Name: is-not-defined
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Specifies that a match should occur if the enclosing Purpose: Specifies that a match should occur if the enclosing vCard
property or parameter does not exist. property or parameter does not exist.
Description: The CARDDAV:is-not-defined XML element specifies that a Description: The CARDDAV:is-not-defined XML element specifies that a
match occurs if the enclosing property or parameter value match occurs if the enclosing vCard property or parameter value
specified in an address book REPORT request does not exist in the specified in an address book REPORT request does not exist in the
address data being tested. address data being tested.
Definition: Definition:
<!ELEMENT is-not-defined EMPTY> <!ELEMENT is-not-defined EMPTY>
10.5.4. CARDDAV:text-match XML Element 10.5.4. CARDDAV:text-match XML Element
Name: text-match Name: text-match
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Specifies a substring match on a property or parameter Purpose: Specifies a substring match on a vCard property or
value. parameter value.
Description: The CARDDAV:text-match XML element specifies text used Description: The CARDDAV:text-match XML element specifies text used
for a substring match against the property or parameter value for a substring match against the vCard property or parameter
specified in an address book REPORT request. value specified in an address book REPORT request.
The "collation" attribute is used to select the collation that the The "collation" attribute is used to select the collation that the
server MUST use for character string matching. In the absence of server MUST use for character string matching. In the absence of
this attribute the server MUST use the "i;unicode-casemap" this attribute the server MUST use the "i;unicode-casemap"
collation. collation.
The "negate-condition" attribute is used to indicate that this The "negate-condition" attribute is used to indicate that this
test returns a match if the text matches, when the attribute value test returns a match if the text matches, when the attribute value
is set to "no", or return a match if the text does not match, if is set to "no", or return a match if the text does not match, if
the attribute value is set to "yes". For example, this can be the attribute value is set to "yes". For example, this can be
skipping to change at page 45, line 22 skipping to change at page 46, line 14
Example: SSL service Example: SSL service
_carddavs._tcp SRV 0 1 443 addressbook.example.com. _carddavs._tcp SRV 0 1 443 addressbook.example.com.
12. Internationalization Considerations 12. Internationalization Considerations
CardDAV allows internationalized strings to be stored and retrieved CardDAV allows internationalized strings to be stored and retrieved
for the description of address book collections (see Section 6.2.1). for the description of address book collections (see Section 6.2.1).
The CARDDAV:addressbook-query report (Section 8.6) includes a text The CARDDAV:addressbook-query REPORT (Section 8.6) includes a text
searching option controlled by the CARDDAV:text-match element and searching option controlled by the CARDDAV:text-match element and
details of character handling are covered in the description of that details of character handling are covered in the description of that
element (see Section 10.5.4). element (see Section 10.5.4).
13. Security Considerations 13. Security Considerations
HTTP protocol transactions are sent in the clear over the network HTTP protocol transactions are sent in the clear over the network
unless protection from snooping is negotiated. This can be unless protection from snooping is negotiated. This can be
accomplished by use of TLS as defined in [RFC2818]. In particular, accomplished by use of TLS as defined in [RFC2818]. In particular,
if HTTP Basic authentication is available, the server MUST allow TLS if HTTP Basic authentication is available, the server MUST allow TLS
skipping to change at page 46, line 13 skipping to change at page 47, line 7
public address book, copy or move address data into public address public address book, copy or move address data into public address
books, or change access privileges in such a way as to expose address books, or change access privileges in such a way as to expose address
data to unauthenticated users. data to unauthenticated users.
This specification currently relies on standard HTTP authentication This specification currently relies on standard HTTP authentication
mechanisms for identifying users. These comprise Basic and Digest mechanisms for identifying users. These comprise Basic and Digest
authentication as well as SSL using client-side certificates. authentication as well as SSL using client-side certificates.
14. IANA Consideration 14. IANA Consideration
In addition to the namespaces defined by RFC4918 [RFC4918] for XML This document uses a URN to describe a new XML namespace conforming
elements, this document uses a URN to describe a new XML namespace to the registry mechanism described in [RFC3688].
conforming to a registry mechanism described in RFC3688 [RFC3688].
All other IANA considerations mentioned in RFC4918 [RFC4918] also
apply to this document.
14.1. Namespace Registration 14.1. Namespace Registration
Registration request for the carddav namespace: Registration request for the carddav namespace:
URI: urn:ietf:params:xml:ns:carddav URI: urn:ietf:params:xml:ns:carddav
Registrant Contact: See the "Author's Address" section of this Registrant Contact: See the "Author's Address" section of this
document. document.
XML: None. Namespace URIs do not represent an XML specification. XML: None - not applicable for namespace registrations.
15. Acknowledgments 15. Acknowledgments
Thanks go to Lisa Dusseault and Bernard Desruisseaux for their work Thanks go to Lisa Dusseault and Bernard Desruisseaux for their work
on CalDAV, on which CardDAV is heavily based. The following on CalDAV, on which CardDAV is heavily based. The following
individuals contributed their ideas and support for writing this individuals contributed their ideas and support for writing this
specification: Mike Douglass, Stefan Eissing, Helge Hess, Arnaud specification: Mike Douglass, Stefan Eissing, Helge Hess, Arnaud
Quillaud, Julian Reschke, Elias Sinderson, Greg Stein, Wilfredo Quillaud, Julian Reschke, Elias Sinderson, Greg Stein, Wilfredo
Sanchez, and Simon Vaillancourt. Sanchez, and Simon Vaillancourt.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-vcarddav-vcardrev] [I-D.ietf-vcarddav-vcardrev]
Perreault, S. and P. Resnick, "vCard Format Perreault, S. and P. Resnick, "vCard Format
Specification", draft-ietf-vcarddav-vcardrev-06 (work in Specification", draft-ietf-vcarddav-vcardrev-08 (work in
progress), March 2009. progress), July 2009.
[I-D.ietf-vcarddav-webdav-mkcol] [I-D.ietf-vcarddav-webdav-mkcol]
Daboo, C., "Extended MKCOL for WebDAV", Daboo, C., "Extended MKCOL for WebDAV",
draft-ietf-vcarddav-webdav-mkcol-03 (work in progress), draft-ietf-vcarddav-webdav-mkcol-04 (work in progress),
February 2009. March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, September 1998. RFC 2426, September 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 48, line 5 skipping to change at page 48, line 41
[RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation
Algorithm", RFC 5051, October 2007. Algorithm", RFC 5051, October 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5397] Sanchez, W. and C. Daboo, "WebDAV Current Principal [RFC5397] Sanchez, W. and C. Daboo, "WebDAV Current Principal
Extension", RFC 5397, December 2008. Extension", RFC 5397, December 2008.
[W3C.REC-xml-20060816] [W3C.REC-xml-20081126]
Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C.,
and E. Maler, "Extensible Markup Language (XML) 1.0 and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
(Fourth Edition)", World Wide Web Consortium Edition)", World Wide Web Consortium Recommendation REC-
FirstEdition REC-xml-20060816, August 2006, xml-20081126, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
16.2. Informative References 16.2. Informative References
[IMSP] Myers, J., "IMSP - Internet Message Support Protocol", [IMSP] Myers, J., "IMSP - Internet Message Support Protocol",
June 1995. June 1995.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
Appendix A. Change History (to be removed prior to publication as an Appendix A. Change History (to be removed prior to publication as an
RFC) RFC)
Changes in -07
1. WGLC: changed all alprop behaviors to SHOULD NOT return in
allprop PROPFIND.
2. WGLC: Reworked XML conventions section to come into line with
text in extended MKCOL, and also updated W3C reference.
3. WGLC: Changed a couple of examples to use absolute path DAV:href
values.
4. WGLC: Simplified IANA Considerations section.
5. WGLC: Added new Client Configuration section and removed
reference to principal-match.
6. address-data element in supported-address-data changed to
address-data-type.
7. REPORTs now require Depth to be present and the scope of matching
resources is determined by the value of the Depth header.
8. Removed requirement that DAV:displayname should be unique at each
level.
Changes in -06 Changes in -06
1. WGLC: addressbook-home-set changed to SHOULD NOT return in 1. WGLC: addressbook-home-set changed to SHOULD NOT return in
allprop PROPFIND. allprop PROPFIND.
2. WGLC: principal-address description changed to note that the 2. WGLC: principal-address description changed to note that the
resource pointed to could be in a regular collection too. resource pointed to could be in a regular collection too.
3. Added new section decribing how SRV and current-user-principal 3. Added new section decribing how SRV and current-user-principal
are used to bootstrap client configuration. are used to bootstrap client configuration.
 End of changes. 85 change blocks. 
218 lines changed or deleted 238 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/