draft-ietf-vcarddav-carddav-07.txt   draft-ietf-vcarddav-carddav-08.txt 
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Standards Track July 13, 2009 Intended status: Standards Track September 1, 2009
Expires: January 14, 2010 Expires: March 5, 2010
vCard Extensions to WebDAV (CardDAV) vCard Extensions to WebDAV (CardDAV)
draft-ietf-vcarddav-carddav-07 draft-ietf-vcarddav-carddav-08
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 January 14, 2010. This Internet-Draft will expire on March 5, 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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . . . 7
5.1. Address Object Resources . . . . . . . . . . . . . . . . . 7 5.1. Address Object Resources . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . 15 6.3.2. Creating Address Object Resources . . . . . . . . . . 15
6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 16 6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 16
6.3.2.2. Non-Standard vCard Properties, and Parameters . . 17 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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
8.6. CARDDAV:addressbook-query Report . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . 27 Full Name or Email Address . . . . . . . . . . . . . . 27
8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 30 8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 30
8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 31 8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 31
8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 33 8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 33
9. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Client Guidelines . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Restrict the Properties Returned . . . . . . . . . . . . . 34 9.1. Restrict the Properties Returned . . . . . . . . . . . . . 34
9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 35 9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 35
9.3. Client Configuration . . . . . . . . . . . . . . . . . . . 35 9.3. Client Configuration . . . . . . . . . . . . . . . . . . . 35
9.4. Finding Other Users' Address Books . . . . . . . . . . . . 36 9.4. Finding Other Users' Address Books . . . . . . . . . . . . 36
10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36
10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 36 10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 36
10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 37 10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 37
10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 37 10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 37
10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 37 10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 37
10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 39 10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 39
skipping to change at page 3, line 42 skipping to change at page 3, line 42
10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 44 10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 44
10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 45 10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 45
11. Service Discovery via SRV Records . . . . . . . . . . . . . . 45 11. Service Discovery via SRV Records . . . . . . . . . . . . . . 45
12. Internationalization Considerations . . . . . . . . . . . . . 46 12. Internationalization Considerations . . . . . . . . . . . . . 46
13. Security Considerations . . . . . . . . . . . . . . . . . . . 46 13. Security Considerations . . . . . . . . . . . . . . . . . . . 46
14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 47 14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 47 14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 47
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
16.1. Normative References . . . . . . . . . . . . . . . . . . . 47 16.1. Normative References . . . . . . . . . . . . . . . . . . . 47
16.2. Informative References . . . . . . . . . . . . . . . . . . 48 16.2. Informative References . . . . . . . . . . . . . . . . . . 49
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) . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
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) [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
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:
1. Ability to use multiple address books with hierarchical layout. 1. Ability to use multiple address books with hierarchical layout.
2. Ability to control access to individual address books and address 2. Ability to control access to individual address books and address
entries. entries as per WebDAV ACL [RFC3744].
3. Principal namespace can be used to enumerate and find other users 3. Principal collections can be used to enumerate and query other
on the system. users on the system as per WebDAV ACL [RFC3744].
4. Server-side searching of address data, avoiding the need for 4. Server-side searching of address data, avoiding the need for
clients to download an entire address book in order to do a quick clients to download an entire address book in order to do a quick
address 'expansion' operation. address 'expansion' operation.
5. Well-defined internationalization support through standard HTTP. 5. Well-defined internationalization support through WebDAV's use of
XML.
6. Use of vCards for well defined address schema to enhance client 6. Use of vCards [RFC2426] for well defined address schema to
interoperability. enhance client interoperability.
7. Many limited clients (e.g. mobile devices) contain an HTTP stack 7. Many limited clients (e.g. mobile devices) contain an HTTP stack
which makes implementing WebDAV much easier than other protocols. which makes implementing WebDAV much easier than other protocols.
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.
skipping to change at page 6, line 28 skipping to change at page 6, line 30
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] and using the certificate validation procedures
described in [RFC5280];
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 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
skipping to change at page 10, line 26 skipping to change at page 10, line 28
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 NOT 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. The
xml:lang attribute can be used to add a language tag for the value
of this property.
Definition: Definition:
<!ELEMENT addressbook-description (#PCDATA)> <!ELEMENT addressbook-description (#PCDATA)>
<!-- PCDATA value: string --> <!-- PCDATA value: string -->
Example: Example:
<C:addressbook-description xml:lang="fr-CA" <C:addressbook-description xml:lang="fr-CA"
xmlns:C="urn:ietf:params:xml:ns:carddav" xmlns:C="urn:ietf:params:xml:ns:carddav"
skipping to change at page 12, line 29 skipping to change at page 12, line 29
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
resource of any reasonable size. resource of any reasonable size.
Definition: Definition:
<!ELEMENT max-resource-size (#PCDATA)> <!ELEMENT max-resource-size (#PCDATA)>
<!-- PCDATA value: a numeric value (positive integer) --> <!-- PCDATA value: a numeric value (positive decimal integer) -->
Example: Example:
<C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:carddav" <C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:carddav"
>102400</C:max-resource-size> >102400</C:max-resource-size>
6.3. Creating Resources 6.3. Creating Resources
Address book collections and address object resources may be created Address book collections and address object resources may be created
by either a CardDAV client or by the CardDAV server. This by either a CardDAV client or by the CardDAV server. This
skipping to change at page 22, line 9 skipping to change at page 22, line 9
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 NOT 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 two or more CARDDAV:supported-collation elements which specify the
the collection identifiers of the collations supported by the identifiers of the collations supported by the server.
server.
Definition: Definition:
<!ELEMENT supported-collation-set (supported-collation*)> <!ELEMENT supported-collation-set (
supported-collation
supported-collation
supported-collation*)>
<!-- Both "i;ascii-casemap" and "i;unicode-casemap"
will be present -->
<!ELEMENT supported-collation (#PCDATA)> <!ELEMENT supported-collation (#PCDATA)>
Example: Example:
<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>
skipping to change at page 34, line 37 skipping to change at page 34, 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. Guidelines 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.
However, if a client needs to make a change to a vCard, it can only However, if a client needs to make a change to a vCard, it can only
change the entire vCard data via a PUT request. There is no way to change the entire vCard data via a PUT request. There is no way to
incrementally make a change to a set of properties within a vCard incrementally make a change to a set of properties within a vCard
object resource. As a result the client will have to cache the object resource. As a result the client will have to cache the
entire set of properties on a resource that is being changed. entire set of properties on a resource that is being changed.
9.2. Use of Locking 9.2. Use of Locking
WebDAV locks can be used to prevent two clients modifying the same WebDAV [RFC4918] locks can be used to prevent two clients modifying
resource from either overwriting each others' changes (though that the same resource from either overwriting each others' changes
problem can also be solved by using ETags) and also to prevent the (though that problem can also be solved by using ETags) and also to
user from making changes that will conflict with another set of prevent the user from making changes that will conflict with another
changes. In a multi-user address book system, the address book set of changes. In a multi-user address book system, the address
client could lock an address object resource while the user is book client could lock an address object resource while the user is
editing the vCard data, and unlock the address object resource when editing the vCard data, and unlock the address object resource when
the user finishes or cancels. Locks can also be used to prevent the user finishes or cancels. Locks can also be used to prevent
changes while data is being reorganized. For example, an address changes while data is being reorganized. For example, an address
book client might lock two address book collections prior to moving a book client might lock two address book collections prior to moving a
bunch of address object resources from one to another. bunch of address object resources from one to another.
Clients may request a lock timeout period that is appropriate to the Clients may request a lock timeout period that is appropriate to the
use case. When the user explicitly decides to reserve a resource and use case. When the user explicitly decides to reserve a resource and
prevent other changes, a long timeout might be appropriate, but in prevent other changes, a long timeout might be appropriate, but in
cases when the client automatically decides to lock the resource the cases when the client automatically decides to lock the resource the
skipping to change at page 36, line 8 skipping to change at page 36, line 8
take the host name and do an SRV lookup to locate the CardDAV server, take the host name and do an SRV lookup to locate the CardDAV server,
then execute an authenticated PROPFIND on the root / resource looking then execute an authenticated PROPFIND on the root / resource looking
for the DAV:current-user-principal-URL property. The value returned for the DAV:current-user-principal-URL property. The value returned
gives the client direct access to the user's principal-URL and from gives the client direct access to the user's principal-URL and from
there all the related CardDAV properties needed to locate address there all the related CardDAV properties needed to locate address
books. books.
9.4. Finding Other Users' Address Books 9.4. Finding Other Users' Address Books
For address book sharing use cases, one might wish to find the For address book sharing use cases, one might wish to find the
address book belonging to another user. If the other user has an address book belonging to another user. To find other users' address
address book in the same repository, that address book can be found books on the same server, the DAV:principal-property-search REPORT
by using the principal namespace required by WebDAV ACL support. [RFC3744] can be used to filter on some properties and return others.
To find other users' address books, the DAV:principal-property-search
REPORT can be used to filter on some properties and return others.
To search for an address book owned by a user named "Laurie", the To search for an address book owned by a user named "Laurie", the
REPORT request body would look like this: REPORT request body would look like this:
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:principal-property-search xmlns:D="DAV:"> <D:principal-property-search xmlns:D="DAV:">
<D:property-search> <D:property-search>
<D:prop> <D:prop>
<D:displayname/> <D:displayname/>
</D:prop> </D:prop>
<D:match>Laurie</D:match> <D:match>Laurie</D:match>
skipping to change at page 41, line 35 skipping to change at page 41, line 35
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Limits the search to specific vCard 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 vCard 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: specified CARDDAV:text-match or CARDDAV:param-filter
param-filter child elements also match. The "test" attribute conditions. The "test" attribute specifies whether any
specifies whether any (logical OR) or all (logical AND) of the (logical OR) or all (logical AND) of the text-filter and param-
text-filter and param-filter tests need to match in order for filter tests need to match in order for the overall filter to
the overall filter to match. match.
or: or:
* A vCard property of the type specified by the "name" attribute * A vCard property of the type specified by the "name" attribute
does not exist, and the CARDAV:is-not-defined element is does not exist, and the CARDAV:is-not-defined element is
specified. 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
skipping to change at page 45, line 43 skipping to change at page 45, line 43
DAV:href+)> DAV:href+)>
11. Service Discovery via SRV Records 11. Service Discovery via SRV Records
[RFC2782] defines a DNS-based service discovery protocol that has [RFC2782] defines a DNS-based service discovery protocol that has
been widely adopted as a means of locating particular services within been widely adopted as a means of locating particular services within
a local area network and beyond, using SRV RR records. a local area network and beyond, using SRV RR records.
This specification adds two service types for use with SRV records: This specification adds two service types for use with SRV records:
carddav: Identifies a CardDAV server that uses HTTP without SSL. carddav: Identifies a CardDAV server that uses HTTP without TLS
[RFC2818].
carddavs: Identifies a CardDAV server that uses HTTP with SSL. carddavs: Identifies a CardDAV server that uses HTTP with TLS
[RFC2818].
Example: non-SSL service record Example: non-TLS service record
_carddav._tcp SRV 0 1 80 addressbook.example.com. _carddav._tcp SRV 0 1 80 addressbook.example.com.
Example: SSL service Example: TLS 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 [RFC2617] is available, the server MUST
to be used at the same time, and SHOULD prevent use of Basic allow TLS to be used at the same time, and SHOULD prevent use of
authentication when TLS is not in use. Basic authentication when TLS is not in use.
With the ACL extension present, WebDAV allows control over who can With the ACL extension [RFC3744] present, WebDAV allows control over
access (read or write) any resource on the WebDAV server. In who can access (read or write) any resource on the WebDAV server. In
addition, WebDAV ACL provides for an "inheritance" mechanism, whereby addition, WebDAV ACL provides for an "inheritance" mechanism, whereby
resources may inherit access privileges from other resources. Often resources may inherit access privileges from other resources. Often
the "other" resource is a parent collection of the resource itself. the "other" resource is a parent collection of the resource itself.
Clients MUST take care to ensure users are aware of which address Clients MUST take care to ensure users are aware of which address
books may be "private" (i.e. only accessible to them) and which are books may be "private" (i.e. only accessible to them) and which are
"shared" (i.e. accessible to others). "shared" (i.e. accessible to others).
Since web servers are often the target of automated indexing Since web servers are often the target of automated indexing
applications that gather data from the server, analyze it and extract applications that gather data from the server, analyze it and extract
'interesting' parts, great care must be taken when allowing 'interesting' parts, great care must be taken when allowing
unauthenticated access to any address book or address object data. unauthenticated access to any address book or address object data.
Clients MAY choose to warn users when they create address data in a Clients MAY choose to warn users when they create address data in a
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 [RFC2617] as well as TLS [RFC2818] using client-side
certificates.
14. IANA Consideration 14. IANA Consideration
This document uses a URN to describe a new XML namespace conforming This document uses a URN to describe a new XML namespace conforming
to the registry mechanism described in [RFC3688]. to the registry mechanism described in [RFC3688].
14.1. Namespace Registration 14.1. Namespace Registration
Registration request for the carddav namespace: Registration request for the carddav namespace:
skipping to change at page 47, line 41 skipping to change at page 47, line 44
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-08 (work in Specification", draft-ietf-vcarddav-vcardrev-08 (work in
progress), July 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-04 (work in progress), draft-ietf-vcarddav-webdav-mkcol-06 (work in progress),
March 2009. August 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.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
Whitehead, "Versioning Extensions to WebDAV Whitehead, "Versioning Extensions to WebDAV
(Web Distributed Authoring and Versioning)", RFC 3253, (Web Distributed Authoring and Versioning)", RFC 3253,
March 2002. March 2002.
skipping to change at page 48, line 38 skipping to change at page 48, line 48
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007. Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 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-20081126] [W3C.REC-xml-20081126]
Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C., Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C.,
and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <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 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): Technical Specification Road Map", RFC 4510,
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 -08
1. AD Review: added references to list in section 1.
2. AD Review: added reference to RFC5280 for cert validation
procedures.
3. AD Review: added additional comment in addressbook-description
property relating to use of xml:lang attribute.
4. AD Review: max-resource-size now explicitly stated to be a
decimal integer.
5. AD Review: tweaked text for supported-collation-set to make it
clear two will always be present.
6. AD Review: section title change to "Client Guidelines".
7. AD Review: finding address books section re-worded and reference
added.
8. AD Review: re-worded prop-filter description to better explain
that text-match and param-filter can be specified independently
of each other.
9. AD Review: references added to security considerations.
10. AD Review: changed to RFC4510 reference.
Changes in -07 Changes in -07
1. WGLC: changed all alprop behaviors to SHOULD NOT return in 1. WGLC: changed all alprop behaviors to SHOULD NOT return in
allprop PROPFIND. allprop PROPFIND.
2. WGLC: Reworked XML conventions section to come into line with 2. WGLC: Reworked XML conventions section to come into line with
text in extended MKCOL, and also updated W3C reference. text in extended MKCOL, and also updated W3C reference.
3. WGLC: Changed a couple of examples to use absolute path DAV:href 3. WGLC: Changed a couple of examples to use absolute path DAV:href
values. values.
 End of changes. 34 change blocks. 
55 lines changed or deleted 103 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/