draft-ietf-vcarddav-carddav-08.txt   draft-ietf-vcarddav-carddav-09.txt 
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Standards Track September 1, 2009 Intended status: Standards Track September 16, 2009
Expires: March 5, 2010 Expires: March 20, 2010
vCard Extensions to WebDAV (CardDAV) vCard Extensions to WebDAV (CardDAV)
draft-ietf-vcarddav-carddav-08 draft-ietf-vcarddav-carddav-09
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 March 5, 2010. This Internet-Draft will expire on March 20, 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 22 skipping to change at page 2, line 22
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
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 . . . . . . . . . . . . . . . . . . . . 8
5.1. Address Object Resources . . . . . . . . . . . . . . . . . 8 5.1. Address Object Resources . . . . . . . . . . . . . . . . . 8
5.2. Address Book Collections . . . . . . . . . . . . . . . . . 8 5.1.1. Data Type Conversion . . . . . . . . . . . . . . . . . 8
6. Address Book Feature . . . . . . . . . . . . . . . . . . . . . 9 5.1.1.1. Additional Precondition for GET . . . . . . . . . 9
6.1. Address Book Support . . . . . . . . . . . . . . . . . . . 9 5.2. Address Book Collections . . . . . . . . . . . . . . . . . 9
6. Address Book Feature . . . . . . . . . . . . . . . . . . . . . 10
6.1. Address Book Support . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . 10
6.2. Address Book Properties . . . . . . . . . . . . . . . . . 10 6.2. Address Book Properties . . . . . . . . . . . . . . . . . 10
6.2.1. CARDDAV:addressbook-description Property . . . . . . . 10 6.2.1. CARDDAV:addressbook-description Property . . . . . . . 11
6.2.2. CARDDAV:supported-address-data Property . . . . . . . 10 6.2.2. CARDDAV:supported-address-data Property . . . . . . . 11
6.2.3. CARDDAV:max-resource-size Property . . . . . . . . . . 11 6.2.3. CARDDAV:max-resource-size Property . . . . . . . . . . 12
6.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 12 6.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 13
6.3.1. Extended MKCOL Method . . . . . . . . . . . . . . . . 12 6.3.1. Extended MKCOL Method . . . . . . . . . . . . . . . . 13
6.3.1.1. Example - Successful MKCOL request . . . . . . . . 13 6.3.1.1. Example - Successful MKCOL request . . . . . . . . 14
6.3.2. Creating Address Object Resources . . . . . . . . . . 15 6.3.2. Creating Address Object Resources . . . . . . . . . . 16
6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 16 6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 17
6.3.2.2. Non-Standard vCard Properties, and Parameters . . 17 6.3.2.2. Non-Standard vCard Properties, and Parameters . . 18
6.3.2.3. Address Object Resource Entity Tag . . . . . . . . 17 6.3.2.3. Address Object Resource Entity Tag . . . . . . . . 18
7. Address Book Access Control . . . . . . . . . . . . . . . . . 18 7. Address Book Access Control . . . . . . . . . . . . . . . . . 19
7.1. Additional Principal Properties . . . . . . . . . . . . . 18 7.1. Additional Principal Properties . . . . . . . . . . . . . 19
7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 18 7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 19
7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 19 7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 20
8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 20 8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 21
8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 20 8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Ordinary Collections . . . . . . . . . . . . . . . . . . . 20 8.2. Ordinary Collections . . . . . . . . . . . . . . . . . . . 21
8.3. Searching Text: Collations . . . . . . . . . . . . . . . . 20 8.3. Searching Text: Collations . . . . . . . . . . . . . . . . 21
8.3.1. CARDDAV:supported-collation-set Property . . . . . . . 21 8.3.1. CARDDAV:supported-collation-set Property . . . . . . . 22
8.4. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 22
8.5. Non-standard Properties and Parameters . . . . . . . . . . 22 8.4. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 23
8.6. CARDDAV:addressbook-query Report . . . . . . . . . . . . . 23 8.5. Non-standard Properties and Parameters . . . . . . . . . . 23
8.6.1. Limiting Results . . . . . . . . . . . . . . . . . . . 24 8.6. CARDDAV:addressbook-query Report . . . . . . . . . . . . . 24
8.6.2. Truncation of Results . . . . . . . . . . . . . . . . 25 8.6.1. Limiting Results . . . . . . . . . . . . . . . . . . . 25
8.6.2. Truncation of Results . . . . . . . . . . . . . . . . 26
8.6.3. Example: Partial Retrieval of vCards Matching 8.6.3. Example: Partial Retrieval of vCards Matching
NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 25 NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . . 27 Full Name or Email Address . . . . . . . . . . . . . . 28
8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 30 8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 31
8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 31 8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 32
8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 33 8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 34
9. Client Guidelines . . . . . . . . . . . . . . . . . . . . . . 34 8.7.2. Example: CARDDAV:addressbook-multiget Report . . . . . 35
9.1. Restrict the Properties Returned . . . . . . . . . . . . . 34 9. Client Guidelines . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Restrict the Properties Returned . . . . . . . . . . . . . 37
9.3. Client Configuration . . . . . . . . . . . . . . . . . . . 35 9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 37
9.4. Finding Other Users' Address Books . . . . . . . . . . . . 36 9.3. Client Configuration . . . . . . . . . . . . . . . . . . . 37
10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36 9.4. Finding Other Users' Address Books . . . . . . . . . . . . 38
10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 36 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 38
10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 37 10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 38
10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 37 10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 39
10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 37 10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 39
10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 39 10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 40
10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 39 10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 41
10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 40 10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 42
10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 41 10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 42
10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 42 10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 43
10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 43 10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 44
10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 43 10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 45
10.6. CARDDAV:limit XML Element . . . . . . . . . . . . . . . . 44 10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 45
10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 44 10.6. CARDDAV:limit XML Element . . . . . . . . . . . . . . . . 46
10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 45 10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 47
11. Service Discovery via SRV Records . . . . . . . . . . . . . . 45 10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 47
12. Internationalization Considerations . . . . . . . . . . . . . 46 11. Service Discovery via SRV Records . . . . . . . . . . . . . . 47
13. Security Considerations . . . . . . . . . . . . . . . . . . . 46 12. Internationalization Considerations . . . . . . . . . . . . . 48
14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 47 13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 47 14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 49
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 49
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
16.1. Normative References . . . . . . . . . . . . . . . . . . . 47 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
16.2. Informative References . . . . . . . . . . . . . . . . . . 49 16.1. Normative References . . . . . . . . . . . . . . . . . . . 49
16.2. Informative References . . . . . . . . . . . . . . . . . . 51
Appendix A. Change History (to be removed prior to Appendix A. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 49 publication as an RFC) . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55
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) [RFC4510], Internet Lightweight Directory Access Protocol (LDAP) [RFC4510], 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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
requests. requests.
vCard is a MIME directory profile aimed at encapsulating personal vCard is a MIME directory profile aimed at encapsulating personal
addressing and contact information about people. The specification addressing and contact information about people. The specification
of vCard was originally done by the Versit consortium, with a of vCard was originally done by the Versit consortium, with a
subsequent 3.0 version standardized by the IETF [RFC2426]. vCard is subsequent 3.0 version standardized by the IETF [RFC2426]. vCard is
in wide spread use in email clients and mobile devices as a means of in wide spread use in email clients and mobile devices as a means of
encapsulating address information for transport via email, or for encapsulating address information for transport via email, or for
import/export and synchronization operations. import/export and synchronization operations.
An update to vCard is currently being developed An update to vCard - vCard v4 - 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
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
skipping to change at page 6, line 22 skipping to change at page 6, line 22
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.
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 v3 [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] and using the certificate validation procedures [RFC5246] and using the certificate validation procedures
described in [RFC5280]; described in [RFC5280];
skipping to change at page 6, line 46 skipping to change at page 6, line 46
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 address book collections and address o MUST advertise support on all address book collections and address
object resources for the address book reports in the DAV: object resources for the address book reports in the DAV:
supported-report-set property, as defined in Versioning Extensions supported-report-set property, as defined in Versioning Extensions
to WebDAV [RFC3253]. to WebDAV [RFC3253].
In addition, a server: In addition, a server:
o SHOULD support vCard v4 [I-D.ietf-vcarddav-vcardrev] as a media
type for the address object resource format;
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.
4. Address Book Data Model 4. Address Book Data Model
skipping to change at page 8, line 20 skipping to change at page 8, line 23
described below. The requirements in this section pertain to vCard described below. The requirements in this section pertain to vCard
address data, or formats that follow the semantics of vCard data. address data, or formats that follow the semantics of vCard data.
Address object resources contained in address book collections MUST Address object resources contained in address book collections MUST
contain a single vCard component only. contain a single vCard component only.
vCard components in an address book collection MUST have a UID vCard components in an address book collection MUST have a UID
property value that MUST be unique in the scope of the address book property value that MUST be unique in the scope of the address book
collection in which it is contained. collection in which it is contained.
5.1.1. Data Type Conversion
Servers might support more than one primary media type for address
object resources, for example vCard v3.0 and vCard v4.0. In such
cases servers have to accept all media types that they advertise via
the CARDDAV:supported-address-data WebDAV property (see
Section 6.2.2).
However, clients can use standard HTTP content negotiation behavior
(the Accept request header defined in Section 14.1 of [RFC2616]) to
request that an address object resource's data be returned in a
specific media type format. For example, a client only capable of
handling vCard v3.0 would only want to have address object resources
returned in v3.0 format.
Additionally, REPORT requests, defined later in this specification,
allow for the return of address object resource data within an XML
response body. Again, the client can use content negotiation to
request that data be returned in a specific media type by specifying
appropriate attributes on the CARDDAV:address-data XML element used
in the request body (see Section 10.4).
In some cases it might not be possible for a server to convert from
one media type to another. When that happens, the server MUST return
the CARDDAV:supported-address-data-conversion precondition (see
below) in the response body (when the failure to convert applies to
the entire response) or use that same precondition code in the DAV:
response XML element in the response for the targeted address object
resource when one of the REPORTs defined below is used. See
Section 8.7.2 for an example of this.
5.1.1.1. Additional Precondition for GET
This specification creates additional preconditions for the GET
method.
The new precondition is:
(CARDDAV:supported-address-data-conversion): The resource targeted
by the GET request can be converted to the media type specified in
the Accept request header included with the request;
5.2. Address Book Collections 5.2. Address Book Collections
Address book collections appear to clients as a WebDAV collection Address book collections appear to clients as a WebDAV collection
resource, identified by a URL. An address book collection MUST resource, identified by a URL. An address book collection MUST
report the DAV:collection and CARDDAV:addressbook XML elements in the report the DAV:collection and CARDDAV:addressbook XML elements in the
value of the DAV:resourcetype property. The element type declaration value of the DAV:resourcetype property. The element type declaration
for CARDDAV:addressbook is: for CARDDAV:addressbook is:
<!ELEMENT addressbook EMPTY> <!ELEMENT addressbook EMPTY>
skipping to change at page 25, line 15 skipping to change at page 26, line 15
indicating a result set truncation to the client. indicating a result set truncation to the client.
8.6.2. Truncation of Results 8.6.2. Truncation of Results
A server MAY limit the number of resources in a response, for A server MAY limit the number of resources in a response, for
example, to limit the amount of work expended in processing a query, example, to limit the amount of work expended in processing a query,
or as the result of an explicit limit set by the client. If it does or as the result of an explicit limit set by the client. If it does
so, the response MUST use status code 207, return a DAV:multistatus so, the response MUST use status code 207, return a DAV:multistatus
response body, and indicate a status of 507 (Insufficient Storage) response body, and indicate a status of 507 (Insufficient Storage)
for the request URI. That DAV:response element SHOULD include a DAV: for the request URI. That DAV:response element SHOULD include a DAV:
error element with the DAV:number-of-matches-within-limits pre- error element with the DAV:number-of-matches-within-limits
condition, as defined in [RFC3744] (Section 9.2). precondition, as defined in [RFC3744] (Section 9.2).
The server SHOULD also include the partial results in additional DAV: The server SHOULD also include the partial results in additional DAV:
response elements. If a client requested limit is being applied, the response elements. If a client requested limit is being applied, the
507 response for the request URI MUST NOT be included in calculating 507 response for the request URI MUST NOT be included in calculating
the limit (e.g., if the client requests that only a single result be the limit (e.g., if the client requests that only a single result be
returned, and multiple matches are present, then the DAV:multistatus returned, and multiple matches are present, then the DAV:multistatus
response will include one DAV:response for the matching resource and response will include one DAV:response for the matching resource and
one DAV:response for the 507 status on the request URI). one DAV:response for the 507 status on the request URI).
8.6.3. Example: Partial Retrieval of vCards Matching NICKNAME 8.6.3. Example: Partial Retrieval of vCards Matching NICKNAME
skipping to change at page 34, line 37 skipping to change at page 35, line 37
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href>/home/bernard/addressbook/vcf1.vcf</D:href> <D:href>/home/bernard/addressbook/vcf1.vcf</D:href>
<D:status>HTTP/1.1 404 Resource not found</D:status> <D:status>HTTP/1.1 404 Resource not found</D:status>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
9. Client Guidelines 8.7.2. Example: CARDDAV:addressbook-multiget Report
In this example, the client requests the server to return vCard v4.0
data of the address components referenced by specific URIs. In
addition the DAV:getetag property is also requested and returned as
part of the response. Note that in this example, the resource at
http://addressbook.example.com/home/bernard/addressbook/vcf3.vcf
exists but in a media type format that the server is unable to
convert, resulting in an error status response.
>> Request <<
REPORT /home/bernard/addressbook/ HTTP/1.1
Host: addressbook.example.com
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<C:addressbook-multiget xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:prop>
<D:getetag/>
<C:address-data type='text/vcard' version='4.0'/>
</D:prop>
<D:href>/home/bernard/addressbook/vcf3.vcf</D:href>
</C:addressbook-multiget>
>> Response <<
HTTP/1.1 207 Multi-Status
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:response>
<D:response>
<D:href>/home/bernard/addressbook/vcf3.vcf</D:href>
<D:status>HTTP/1.1 415 Unsupported Media Type</D:status>
<D:error><C:supported-address-data-conversion/></D:error>
<D:responsedescription>Unable to convert from vCard v3.0
to vCard v4.0</D:responsedescription>
</D:response>
</D:multistatus>
9. Client Guidelines
9.1. Restrict the Properties Returned 9.1. Restrict the Properties Returned
Clients may not need all the properties in a vCard object when Clients may not need all the properties in a vCard object when
presenting information to the user, or looking up specific items for presenting information to the user, or looking up specific items for
their email address, for example. Since some property data can be their email address, for example. Since some property data can be
large (e.g., PHOTO or SOUND with inline content) clients can choose large (e.g., PHOTO or SOUND with inline content) clients can choose
to ignore those by only requesting the specific items it knows it to ignore those by only requesting the specific items it knows it
will use, through use of the CARDDAV:address-data XML element in the will use, through use of the CARDDAV:address-data XML element in the
relevant reports. relevant reports.
skipping to change at page 49, line 30 skipping to change at page 51, line 36
[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.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
June 2006. 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 -09
1. AD Review: support for vCard v4 is now a SHOULD.
2. As a result of the above, added a sub-section on content
conversion that defines a new precondition, and added an example
of a conversion failure when doing a multiget.
Changes in -08 Changes in -08
1. AD Review: added references to list in section 1. 1. AD Review: added references to list in section 1.
2. AD Review: added reference to RFC5280 for cert validation 2. AD Review: added reference to RFC5280 for cert validation
procedures. procedures.
3. AD Review: added additional comment in addressbook-description 3. AD Review: added additional comment in addressbook-description
property relating to use of xml:lang attribute. property relating to use of xml:lang attribute.
 End of changes. 18 change blocks. 
74 lines changed or deleted 178 lines changed or added

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