Support for creating address book collections via extended MKCOL is RECOMMENDED but not REQUIRED because some servers only support one address book per user and pre-create it, making creation support unnecessary in those deployments.

WebDAV was chosen as the CardDAV foundation because it significantly reduces design, implementation, interoperability testing, and deployment costs. Many limited clients (mobile devices) already have HTTP stacks, making WebDAV easier to implement than LDAP or ACAP.

CARDDAV:allprop and CARDDAV:prop share names with DAV:allprop and DAV:prop but use the 'urn:ietf:params:xml:ns:carddav' namespace rather than 'DAV:'. Implementations must distinguish between the two namespaces to avoid misinterpreting WebDAV versus CardDAV elements.

Servers supporting multiple vCard versions must accept all advertised media types on input. Clients may request a specific version via the HTTP Accept header on GET or via CARDDAV:address-data attributes in REPORT. When conversion is impossible, the server returns the CARDDAV:supported-address-data-conversion precondition (HTTP 415 per-resource in multiget).

http

A CardDAV server MUST include 'addressbook' in the DAV response header to OPTIONS requests on any resource supporting address book properties, reports, or methods; this token asserts full compliance with all MUST-level requirements.

A CardDAV server MUST support vCard v3 (RFC 2426), WebDAV Class 3, WebDAV ACL, secure transport via TLS with certificate validation, ETags, all address book reports in Section 8, and MUST advertise those reports in DAV:supported-report-set.

tls, security

Address object resources contained in address book collections MUST contain a single vCard component only.

An address book collection MUST report both DAV:collection and CARDDAV:addressbook in the DAV:resourcetype property. Address book collections MUST only contain address object resources and non-address-book collections; nesting of address book collections is prohibited at any depth.

CardDAV servers MUST support and adhere to WebDAV ACL (RFC 3744) to provide access control over address book collections and individual address object resources.

security

Clients SHOULD use the If-Match header with the previously retrieved ETag on PUT requests to avoid lost updates when multiple clients may modify the same address object resource concurrently.

http

In the absence of CARDDAV:supported-address-data, a server MUST only accept 'text/vcard' at version 3.0. Any attempt to store a resource with an unsupported media type MUST fail with the CARDDAV:supported-address-data precondition.

New address object resources MUST be created via PUT to an unmapped URI. Clients SHOULD use 'If-None-Match: *' on such PUT requests to avoid inadvertently overwriting an existing resource.

http

Servers are REQUIRED to support the 'i;ascii-casemap' and 'i;unicode-casemap' collations for text matching in reports. In the absence of a client-specified collation, the server MUST default to 'i;unicode-casemap'. An unsupported collation MUST result in a CARDDAV:supported-collation precondition error.

Servers MUST support CARDDAV:addressbook-query and CARDDAV:addressbook-multiget REPORT requests and MUST advertise this support on all address book collections and address object resources via DAV:supported-report-set.

Servers MUST support the use of non-standard vCard properties and parameters (X- prefixed) in address object resources stored via PUT.

The DAV:getetag property MUST be defined and set to a strong entity tag on every address object resource; a GET response on such a resource MUST include an ETag header with the current strong entity tag.

http

vCard components in an address book collection MUST have a UID property value that MUST be unique within the scope of the containing address book collection.

When a query result set is truncated, the response MUST use HTTP 207 (Multi-Status) with a 507 (Insufficient Storage) status on the Request-URI and SHOULD include a DAV:error element with the DAV:number-of-matches-within-limits precondition.

http

When the data stored by the server after a PUT is not octet-equal to what the client submitted, a strong entity tag MUST NOT be returned in the PUT response, signaling the client that it must re-retrieve the resource before further changes.

http

CARDDAV:addressbook-description is a per-collection WebDAV property (SHOULD NOT be protected) providing a human-readable description of the address book, with optional xml:lang attribute for language tagging.

CARDDAV:addressbook-home-set is a principal property containing one or more DAV:href values identifying collections that own or contain address book collections for that principal, enabling client discovery.

CARDDAV:addressbook-multiget REPORT retrieves specific address object resources by providing an explicit list of DAV:href elements; requires Depth: 0 and returns a DAV:multistatus with per-resource status and optional address data.

CARDDAV:addressbook-query REPORT performs a server-side search using a CARDDAV:filter element and returns matching address object resources with optional partial vCard data and WebDAV properties; Depth header determines scope.

CARDDAV:max-resource-size is a protected WebDAV property carrying a positive decimal integer (octet count); exceeding it on PUT/COPY/MOVE triggers the CARDDAV:max-resource-size precondition error.

CARDDAV:principal-address is a principal property containing a single DAV:href identifying the address object resource (vCard) that corresponds to the user represented by the principal.

CARDDAV:supported-address-data is a protected WebDAV property on address book collections listing the supported media types and versions (e.g., text/vcard 3.0) via CARDDAV:address-data-type child elements with content-type and version attributes.

RFC 6352 registers the XML namespace 'urn:ietf:params:xml:ns:carddav' for all CardDAV XML elements defined in this specification. Implementations MUST NOT use this namespace for privately defined elements.

registry

CardDAV stores personal contact information that is sensitive. Servers MUST support TLS (RFC 5246) with certificate validation per RFC 5280. WebDAV ACL provides per-collection and per-resource access control. Clients should use authenticated sessions and validate server certificates to prevent interception or spoofing.

security, tls

CARDDAV:address-data XML element carries vCard data in REPORT responses and specifies partial retrieval in requests. Attributes: content-type (default 'text/vcard') and version (default '3.0'). Child CARDDAV:prop elements with 'name' and optional 'novalue' attributes select individual vCard properties.

CARDDAV:filter element contains CARDDAV:prop-filter children and a 'test' attribute (anyof|allof). CARDDAV:prop-filter targets a named vCard property and may contain CARDDAV:text-match and CARDDAV:param-filter; CARDDAV:param-filter targets a specific vCard parameter within that property.

CARDDAV:limit/CARDDAV:nresults elements allow a client to request a maximum number of DAV:response elements; the server MAY disregard the limit. The nresults value is an unsigned integer.

CARDDAV:text-match element specifies text comparison with attributes: collation (default 'i;unicode-casemap'), negate-condition (yes|no, default 'no'), and match-type (equals|contains|starts-with|ends-with, default 'contains').