draft-ietf-vcarddav-carddav-02.txt   draft-ietf-vcarddav-carddav-03.txt 
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Standards Track November 24, 2008 Intended status: Standards Track November 30, 2008
Expires: May 28, 2009 Expires: June 3, 2009
vCard Extensions to WebDAV (CardDAV) vCard Extensions to WebDAV (CardDAV)
draft-ietf-vcarddav-carddav-02 draft-ietf-vcarddav-carddav-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 May 28, 2009. This Internet-Draft will expire on June 3, 2009.
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.
Discussion of this Internet-Draft is taking place on the mailing list Discussion of this Internet-Draft is taking place on the mailing list
<http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>. <http://lists.osafoundation.org/mailman/listinfo/ietf-carddav>.
skipping to change at page 2, line 38 skipping to change at page 2, line 38
6.3.2. Creating Address Object Resources . . . . . . . . . . 14 6.3.2. Creating Address Object Resources . . . . . . . . . . 14
6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 15 6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 15
6.3.2.2. Non-Standard vCard Properties, and Parameters . . 16 6.3.2.2. Non-Standard vCard Properties, and Parameters . . 16
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 . . . . . . . . . . . . . . . . . 17
7.1. Additional Principal Properties . . . . . . . . . . . . . 17 7.1. Additional Principal Properties . . . . . . . . . . . . . 17
7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 17 7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 17
7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 18 7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 18
8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 19 8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 19
8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 19 8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . 22
8.6.1. Example: Partial retrieval of vCards matching 8.6.1. Limiting Results . . . . . . . . . . . . . . . . . . . 24
8.6.2. Truncation of Results . . . . . . . . . . . . . . . . 24
8.6.3. Example: Partial Retrieval of vCards Matching
NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 24 NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 24
8.6.2. 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 . . . . . . . . . . . . . . 26
8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 29 8.6.5. Example: Truncated Results . . . . . . . . . . . . . . 29
8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 30 8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 30
9. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 32
9.1. Restrict the Properties Returned . . . . . . . . . . . . . 31 9. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Restrict the Properties Returned . . . . . . . . . . . . . 33
9.3. Finding address books . . . . . . . . . . . . . . . . . . 32 9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 34
10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 34 9.3. Finding Address Books . . . . . . . . . . . . . . . . . . 34
10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 34 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36
10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 34 10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 36
10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 34 10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 36
10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 35 10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 36
10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 36 10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 37
10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 37 10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 38
10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 38 10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 39
10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 38 10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 40
10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 39 10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 40
10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 40 10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 41
10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 40 10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 42
10.6. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 42 10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 42
11. Service Discovery via SRV records . . . . . . . . . . . . . . 42 10.6. CARDDAV:limit XML Element . . . . . . . . . . . . . . . . 44
12. Internationalization Considerations . . . . . . . . . . . . . 42 10.6.1. CARDDAV:nresults XML Element . . . . . . . . . . . . . 44
13. Security Considerations . . . . . . . . . . . . . . . . . . . 43 10.7. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 44
14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 43 11. Service Discovery via SRV Records . . . . . . . . . . . . . . 45
14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 43 12. Internationalization Considerations . . . . . . . . . . . . . 45
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 46
16.1. Normative References . . . . . . . . . . . . . . . . . . . 44 14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 46
16.2. Informative References . . . . . . . . . . . . . . . . . . 45 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
16.1. Normative References . . . . . . . . . . . . . . . . . . . 47
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) . . . . . . . . . . . . . . . 46 publication as an RFC) . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . . . . 49 Intellectual Property and Copyright Statements . . . . . . . . . . 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
skipping to change at page 6, line 10 skipping to change at page 6, line 10
CardDAV XML element type. Some of the declarations refer to XML CardDAV XML element type. Some of the declarations refer to XML
elements defined by WebDAV [RFC4918] which use the "DAV:" namespace. elements defined by WebDAV [RFC4918] which use the "DAV:" namespace.
Wherever such XML elements appear, they are explicitly prefixed with Wherever such XML elements appear, they are explicitly prefixed with
"DAV:" to avoid confusion. "DAV:" to avoid confusion.
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 Processing of XML by CardDAV clients and servers MUST follow the
rules described in Appendix A of [RFC4918]. 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];
skipping to change at page 20, line 13 skipping to change at page 20, line 13
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]).
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
skipping to change at page 22, line 18 skipping to change at page 22, line 18
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 property or parameter
names in the CARDDAV:address-data XML element in address book REPORT names in the CARDDAV:address-data XML element in address book REPORT
requests to allow clients to request that non-standard properties and requests to allow clients to request that non-standard properties and
parameters be returned in the address data provided in the response. 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 property or parameter
names in the CARDDAV:prop-filter and CARDDAV:param-filter XML names in the CARDDAV:prop-filter and CARDDAV:param-filter XML
elements specified in the CARDDAV:filter XML element of address book elements specified in the CARDDAV:filter XML element of address book
REPORT requests. REPORT requests.
skipping to change at page 24, line 16 skipping to change at page 24, line 16
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
large number of responses. large number of responses.
8.6.1. Example: Partial retrieval of vCards matching NICKNAME 8.6.1. Limiting Results
A client can limit the number of results returned by the server
through use of the CARDDAV:limit element in the request body. This
is useful when clients are only interested in the first few matches,
or only have limited space to display results to users and thus don't
need the overhead of receiving more than that. When the results are
truncated by the server, the server MUST follow the rules below for
indicating a result set truncation to the client.
8.6.2. Truncation of Results
A server MAY limit the number of resources in a response, for
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
so, the response MUST use status code 207, return a DAV:multistatus
response body, and indicate a status of 507 (Insufficient Storage)
for the request URI. That DAV:response element SHOULD include a DAV:
error element with the DAV:number-of-matches-within-limits pre-
condition, as defined in [RFC3744] (Section 9.2).
The server SHOULD also include the partial results in additional DAV:
response elements. If a client requested limit is being applied, the
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
returned, and multiple matches are present, then the DAV:multistatus
response will include one DAV:response for the matching resource and
one DAV:response for the 507 status on the request URI).
8.6.3. Example: Partial Retrieval of vCards Matching NICKNAME
In this example, the client requests the server to search for address In this example, the client requests the server to search for address
object resources that contain a NICKNAME property whose value equals object resources that contain a NICKNAME property whose value equals
some specific text, and to return specific vCard properties for those some specific text, and to return specific vCard properties for those
vCards found. In addition the DAV:getetag property is also requested vCards found. In addition the DAV:getetag property is also requested
and returned as part of the response. and returned as part of the response.
>> Request << >> Request <<
REPORT /home/bernard/addressbook/ HTTP/1.1 REPORT /home/bernard/addressbook/ HTTP/1.1
skipping to change at page 26, line 33 skipping to change at page 26, line 33
FN:Cyrus Daboo FN:Cyrus Daboo
EMAIL:daboo@example.com EMAIL:daboo@example.com
END:VCARD END:VCARD
</C:address-data> </C:address-data>
</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:multistatus> </D:multistatus>
8.6.2. Example: Partial retrieval of vCards matching a full name or 8.6.4. Example: Partial Retrieval of vCards Matching a Full Name or
email address Email Address
In this example, the client requests the server to search for address In this example, the client requests the server to search for address
object resources that contain a FN property whose value contains some object resources that contain a FN property whose value contains some
specific text or that contain an EMAIL property whose value contains specific text or that contain an EMAIL property whose value contains
other text, and to return specific vCard properties for those vCards other text, and to return specific vCard properties for those vCards
found. In addition the DAV:getetag property is also requested and found. In addition the DAV:getetag property is also requested and
returned as part of the response. returned as part of the response.
>> Request << >> Request <<
skipping to change at page 29, line 5 skipping to change at page 29, line 5
FN:Oliver Daboo FN:Oliver Daboo
EMAIL:oliver@example.com EMAIL:oliver@example.com
END:VCARD END:VCARD
</C:address-data> </C:address-data>
</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:multistatus> </D:multistatus>
8.6.5. Example: Truncated Results
In this example, the client requests the server to search for address
object resources that contain a FN property whose value contains some
specific text, and to return the DAV:getetag property for the first
two results only. The server response includes a 507 status for the
request URI indicating that there were more than two resources that
matched the query, but that the server truncated the result set as
requested by the client.
>> 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-query xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:prop>
<D:getetag/>
</D:prop>
<C:filter test="anyof">
<C:prop-filter name="FN">
<C:text-match collation="i;unicode-casemap"
match-type="contains"
>daboo</C:text-match>
</C:prop-filter>
</C:filter>
<C:limit>
<C:nresults>2</C:nresults>
</C:limit>
</C:addressbook-query>
>> 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:href>/home/bernard/addressbook/</D:href>
<D:status>HTTP/1.1 507 OK</D:status>
<D:error><D:number-of-matches-within-limits/></D:error>
<D:responsedescription xml:lang="en">
Only first two matching records were returned
</D:responsedescription>
</D:response>
<D:response>
<D:href>/home/bernard/addressbook/v102.vcf</D:href>
<D:propstat>
<D:prop>
<D:getetag>"23ba4d-ff11fb"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/home/bernard/addressbook/v104.vcf</D:href>
<D:propstat>
<D:prop>
<D:getetag>"23ba4d-ff11fc"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
8.7. CARDDAV:addressbook-multiget Report 8.7. CARDDAV:addressbook-multiget Report
The CARDDAV:addressbook-multiget REPORT is used to retrieve specific The CARDDAV:addressbook-multiget REPORT is used to retrieve specific
address object resources from within a collection, if the Request-URI address object resources from within a collection, if the Request-URI
is a collection, or to retrieve a specific address object resource, is a collection, or to retrieve a specific address object resource,
if the Request-URI is a address object resource. This report is if the Request-URI is a address object resource. This report is
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.6, 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 the Request-URI is a collection
resource, then the DAV:href elements MUST refer to resources resource, then the DAV:href elements MUST refer to resources
within that collection, and they MAY refer to resources at any within that collection, and they MAY refer to resources at any
depth within the collection. As a result the "Depth" header MUST depth within the collection. As a result the "Depth" header MUST
be ignored by the server and SHOULD NOT be sent by the client. If be ignored by the server and SHOULD NOT be sent by the client. If
the Request-URI refers to a non-collection resource, then there the Request-URI refers to a non-collection resource, then there
MUST be a single DAV:href element that is equivalent to the MUST be a single DAV:href element that is equivalent to the
Request-URI. Request-URI.
skipping to change at page 32, line 34 skipping to change at page 34, line 34
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
timeout should be short (and the client can always refresh the lock timeout should be short (and the client can always refresh the lock
should it need to). A short lock timeout means that if the client is should it need to). A short lock timeout means that if the client is
unable to remove the lock, the other address book users aren't unable to remove the lock, the other address book users aren't
prevented from making changes. prevented from making changes.
9.3. Finding address books 9.3. Finding Address Books
Much of the time an address book client (or agent) will discover a Much of the time an address book client (or agent) will discover a
new address book's location by being provided directly with the URL. new address book's location by being provided directly with the URL.
E.g. a user will type his or her own address book location into E.g. a user will type his or her own address book location into
client configuration information, or cut and paste a URL from email client configuration information, or cut and paste a URL from email
into the address book application. The client need only confirm that into the address book application. The client need only confirm that
the URL points to a resource which is an address book. The client the URL points to a resource which is an address book. The client
may also be able to browse WebDAV collections to find address book may also be able to browse WebDAV collections to find address book
collections. collections.
skipping to change at page 35, line 10 skipping to change at page 37, line 10
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Defines a report for querying address book data Purpose: Defines a report for querying address book data
Description: See Section 8.6. Description: See Section 8.6.
Definition: Definition:
<!ELEMENT addressbook-query ((DAV:allprop | <!ELEMENT addressbook-query ((DAV:allprop |
DAV:propname | DAV:propname |
DAV:prop)?, filter)> 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. A supported media type for address object resources when
skipping to change at page 42, line 5 skipping to change at page 44, line 5
Definition: Definition:
<!ELEMENT text-match (#PCDATA)> <!ELEMENT text-match (#PCDATA)>
<!-- PCDATA value: string --> <!-- PCDATA value: string -->
<!ATTLIST text-match <!ATTLIST text-match
collation CDATA "i;unicode-casemap" collation CDATA "i;unicode-casemap"
negate-condition (yes | no) "no" negate-condition (yes | no) "no"
match-type (equals|contains|starts-with|ends-with) "contains"> match-type (equals|contains|starts-with|ends-with) "contains">
10.6. CARDDAV:addressbook-multiget XML Element 10.6. CARDDAV:limit XML Element
Name: limit
Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Specifies different types of limits that can be applied to
the results returned by the server.
Description: The CARDDAV:limit XML element can be used to specify
different types of limits that the client can request the server
to apply to the results returned by the server. Currently only
the CARDDAV:nresults limit can be used, other types of limit could
be defined in the future.
Definition:
<!ELEMENT limit (nresults)>
10.6.1. CARDDAV:nresults XML Element
Name: nresults
Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Specifies a limit on the number of results returned by the
server.
Description: The CARDDAV:nresults XML element contains a requested
maximum number of DAV:response elements to be returned in the
response body of a query. The server MAY disregard this limit.
The value of this element is an unsigned integer.
Definition:
<!ELEMENT nresults (#PCDATA)>
<!-- nresults value: unsigned integer, must be digits -->
10.7. CARDDAV:addressbook-multiget XML Element
Name: addressbook-multiget Name: addressbook-multiget
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: CardDAV report used to retrieve specific address objects Purpose: CardDAV report used to retrieve specific address objects
via their URIs. via their URIs.
Description: See Section 8.7. Description: See Section 8.7.
Definition: Definition:
<!ELEMENT addressbook-multiget ((DAV:allprop | <!ELEMENT addressbook-multiget ((DAV:allprop |
DAV:propname | DAV:propname |
DAV:prop)?, DAV:prop)?,
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 SSL.
carddavs: Identifies a CardDAV server that uses HTTP with SSL. carddavs: Identifies a CardDAV server that uses HTTP with SSL.
skipping to change at page 44, line 28 skipping to change at page 47, line 24
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-05 (work in Specification", draft-ietf-vcarddav-vcardrev-05 (work in
progress), November 2008. progress), November 2008.
[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-00 (work in progress), draft-ietf-vcarddav-webdav-mkcol-02 (work in progress),
May 2008. November 2008.
[I-D.sanchez-webdav-current-principal] [I-D.sanchez-webdav-current-principal]
Sanchez, W. and C. Daboo, "WebDAV Current Principal Sanchez, W. and C. Daboo, "WebDAV Current Principal
Extension", draft-sanchez-webdav-current-principal-02 Extension", draft-sanchez-webdav-current-principal-02
(work in progress), October 2008. (work in progress), October 2008.
[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.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
skipping to change at page 46, line 8 skipping to change at page 48, line 47
[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 from -02
1. Added limit element to addressbook-query.
2. Specified how a server signals that query results have been
truncated.
3. Minor stylistic changes.
Changes from -01 Changes from -01
1. Added text to CARDDAV:prop and CARDDAV:prop-filter elements to 1. Added text to CARDDAV:prop and CARDDAV:prop-filter elements to
explain how vCard "group" prefix on property names is handled. explain how vCard "group" prefix on property names is handled.
Changes from -00 Changes from -00
1. Added section on SRV records. 1. Added section on SRV records.
Changes from draft-daboo-carddav-04 Changes from draft-daboo-carddav-04
 End of changes. 21 change blocks. 
53 lines changed or deleted 207 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/