draft-ietf-vcarddav-carddav-03.txt   draft-ietf-vcarddav-carddav-04.txt 
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Standards Track November 30, 2008 Intended status: Standards Track February 10, 2009
Expires: June 3, 2009 Expires: August 14, 2009
vCard Extensions to WebDAV (CardDAV) vCard Extensions to WebDAV (CardDAV)
draft-ietf-vcarddav-carddav-03 draft-ietf-vcarddav-carddav-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 3, 2009. This Internet-Draft will expire on August 14, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 3, line 35 skipping to change at page 4, line 4
13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45
14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 46 14. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 46
14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 46 14.1. Namespace Registration . . . . . . . . . . . . . . . . . . 46
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 . . . . . . . . . . . . . . . . . . 48
Appendix A. Change History (to be removed prior to Appendix A. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 48 publication as an RFC) . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
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 25 skipping to change at page 6, line 25
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
v1.0 [RFC2246] or a subsequent standards-track version of TLS; [RFC5246];
o MUST support ETags [RFC2616] with additional requirements o MUST support ETags [RFC2616] with additional requirements
specified in Section 6.3.2.3 of this document; specified in Section 6.3.2.3 of this document;
o MUST support all address book REPORTs defined in Section 8 of this o MUST support all address book REPORTs defined in Section 8 of this
document; and document; and
o MUST advertise support on all addressbook collections and address o MUST advertise support on all addressbook collections and address
object resources for the addressbook reports in the DAV:supported- object resources for the addressbook reports in the DAV:supported-
report-set property, as defined in Versioning Extensions to WebDAV report-set property, as defined in Versioning Extensions to WebDAV
[RFC3253]. [RFC3253].
In addition, a server: In addition, a server:
o SHOULD support the extended MKCOL method o SHOULD support the extended MKCOL method
[I-D.ietf-vcarddav-webdav-mkcol] to create address book [I-D.ietf-vcarddav-webdav-mkcol] to create address book
collections as defined in Section 6.3.1 of this document. collections as defined in Section 6.3.1 of this document.
o SHOULD support the DAV:current-user-principal-URL property as o SHOULD support the DAV:current-user-principal-URL property as
defined in [I-D.sanchez-webdav-current-principal] to give clients defined in [RFC5397] to give clients a fast way to locate user
a fast way to locate user principals. principals.
4. Address Book Data Model 4. Address Book Data Model
As a brief overview, a CardDAV address book is modeled as a WebDAV As a brief overview, a CardDAV address book is modeled as a WebDAV
collection with a well defined structure; each of these address book collection with a well defined structure; each of these address book
collections contain a number of resources representing address collections contain a number of resources representing address
objects as their direct child resources. Each resource representing objects as their direct child resources. Each resource representing
an address object is called an "address object resource". Each an address object is called an "address object resource". Each
address object resource and each address book collection can be address object resource and each address book collection can be
individually locked and have individual WebDAV properties. individually locked and have individual WebDAV properties.
skipping to change at page 24, line 20 skipping to change at page 24, line 20
(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. Limiting Results 8.6.1. Limiting Results
A client can limit the number of results returned by the server A client can limit the number of results returned by the server
through use of the CARDDAV:limit element in the request body. This through use of the CARDDAV:limit element in the request body. This
is useful when clients are only interested in the first few matches, is useful when clients are only interested in a few matches, or only
or only have limited space to display results to users and thus don't have limited space to display results to users and thus don't need
need the overhead of receiving more than that. When the results are the overhead of receiving more than that. When the results are
truncated by the server, the server MUST follow the rules below for truncated by the server, the server MUST follow the rules below for
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)
skipping to change at page 29, line 9 skipping to change at page 29, line 9
</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 8.6.5. Example: Truncated Results
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, and to return the DAV:getetag property for the first specific text, and to return the DAV:getetag property for two results
two results only. The server response includes a 507 status for the only. The server response includes a 507 status for the request URI
request URI indicating that there were more than two resources that indicating that there were more than two resources that matched the
matched the query, but that the server truncated the result set as query, but that the server truncated the result set as requested by
requested by the client. the client.
>> Request << >> Request <<
REPORT /home/bernard/addressbook/ HTTP/1.1 REPORT /home/bernard/addressbook/ HTTP/1.1
Host: addressbook.example.com Host: addressbook.example.com
Depth: 1 Depth: 1
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
skipping to change at page 30, line 19 skipping to change at page 30, line 19
Content-Length: xxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" <D:multistatus xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:carddav"> xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:response> <D:response>
<D:href>/home/bernard/addressbook/</D:href> <D:href>/home/bernard/addressbook/</D:href>
<D:status>HTTP/1.1 507 OK</D:status> <D:status>HTTP/1.1 507 OK</D:status>
<D:error><D:number-of-matches-within-limits/></D:error> <D:error><D:number-of-matches-within-limits/></D:error>
<D:responsedescription xml:lang="en"> <D:responsedescription xml:lang="en">
Only first two matching records were returned Only two matching records were returned
</D:responsedescription> </D:responsedescription>
</D:response> </D:response>
<D:response> <D:response>
<D:href>/home/bernard/addressbook/v102.vcf</D:href> <D:href>/home/bernard/addressbook/v102.vcf</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:getetag>"23ba4d-ff11fb"</D:getetag> <D:getetag>"23ba4d-ff11fb"</D:getetag>
</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>
skipping to change at page 41, line 10 skipping to change at page 41, line 10
Namespace: urn:ietf:params:xml:ns:carddav Namespace: urn:ietf:params:xml:ns:carddav
Purpose: Limits the search to specific properties. Purpose: Limits the search to specific properties.
Description: The CARDDAV:prop-filter XML element specifies a search Description: The CARDDAV:prop-filter XML element specifies a search
criteria on a specific vCard property (e.g., NICKNAME). An criteria on a specific vCard property (e.g., NICKNAME). An
address object is said to match a CARDDAV:prop-filter if: address object is said to match a CARDDAV:prop-filter if:
* A property of the type specified by the "name" attribute * A property of the type specified by the "name" attribute
exists, and the CARDDAV:prop-filter is empty, or it matches the exists, and the CARDDAV:prop-filter is empty, or it matches any
CARDDAV:text-match conditions if specified, and that CARDDAV: CARDDAV:text-match conditions if specified, and that CARDDAV:
param-filter child elements also match. The "test" attribute param-filter child elements also match. The "test" attribute
specifies whether any (logical OR) or all (logical AND) of the specifies whether any (logical OR) or all (logical AND) of the
text-filter and param-filter tests needs to match in order for text-filter and param-filter tests need to match in order for
the overall filter to match. the overall filter to match.
or: or:
* A property of the type specified by the "name" attribute does * A property of the type specified by the "name" attribute does
not exist, and the CARDAV:is-not-defined element is specified. not exist, and the CARDAV:is-not-defined element is specified.
vCard allows a "group" prefix to appear before a property name in vCard allows a "group" prefix to appear before a property name in
the vCard data. When the "name" attribute does not specify a the vCard data. When the "name" attribute does not specify a
group prefix, it MUST match properties in the vCard data without a group prefix, it MUST match properties in the vCard data without a
group prefix or with any group prefix. When the "name" attribute group prefix or with any group prefix. When the "name" attribute
includes a group prefix, it MUST match properties that have includes a group prefix, it MUST match properties that have
exactly the same group prefix and name. e.g.: a "name" set to exactly the same group prefix and name. e.g.: a "name" set to
"TEL" will match "TEL", "X-ABC.TEL", "X-ABC-1.TEL" vCard "TEL" will match "TEL", "X-ABC.TEL", "X-ABC-1.TEL" vCard
properties. A "name" set to "X-ABC.TEL" will match an "X-ABC.TEL" properties. A "name" set to "X-ABC.TEL" will match an "X-ABC.TEL"
vCard property only, it will not match "TEL" or "X-ABC-1.TEL". vCard property only, it will not match "TEL" or "X-ABC-1.TEL".
Definition: Definition:
<!ELEMENT prop-filter (is-not-defined | <!ELEMENT prop-filter (is-not-defined |
(text-match?, param-filter*))> (text-match*, param-filter*))>
<!ATTLIST prop-filter name CDATA #REQUIRED <!ATTLIST prop-filter name CDATA #REQUIRED
test (anyof | allof) "anyof"> test (anyof | allof) "anyof">
<!-- name value: a vCard property name (e.g., "NICKNAME") <!-- name value: a vCard property name (e.g., "NICKNAME")
test value: test value:
anyof logical OR for text-match/param-filter matches anyof logical OR for text-match/param-filter matches
allof logical AND for text-match/param-filter matches --> allof logical AND for text-match/param-filter matches -->
10.5.2. CARDDAV:param-filter XML Element 10.5.2. CARDDAV:param-filter XML Element
skipping to change at page 47, line 24 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-02 (work in progress), draft-ietf-vcarddav-webdav-mkcol-03 (work in progress),
November 2008. February 2009.
[I-D.sanchez-webdav-current-principal]
Sanchez, W. and C. Daboo, "WebDAV Current Principal
Extension", draft-sanchez-webdav-current-principal-02
(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",
RFC 2246, January 1999.
[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.
[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.
skipping to change at page 48, line 26 skipping to change at page 48, line 17
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
March 2007. March 2007.
[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
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5397] Sanchez, W. and C. Daboo, "WebDAV Current Principal
Extension", RFC 5397, December 2008.
[W3C.REC-xml-20060816] [W3C.REC-xml-20060816]
Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C., Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C.,
and E. Maler, "Extensible Markup Language (XML) 1.0 and E. Maler, "Extensible Markup Language (XML) 1.0
(Fourth Edition)", World Wide Web Consortium (Fourth Edition)", World Wide Web Consortium
Recommendation REC-xml-20060816, August 2006, FirstEdition REC-xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>. <http://www.w3.org/TR/2006/REC-xml-20060816>.
16.2. Informative References 16.2. Informative References
[IMSP] Myers, J., "IMSP - Internet Message Support Protocol", [IMSP] Myers, J., "IMSP - Internet Message Support Protocol",
June 1995. June 1995.
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application [RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
Appendix A. Change History (to be removed prior to publication as an Appendix A. Change History (to be removed prior to publication as an
RFC) RFC)
Changes from -03
1. Tweaked limit element text to not imply any formal ordering of
results.
2. Changed prop-filter element to allow zero or more text-match
elements rather than zero or one.
3. Updated to RFC5397 reference.
4. Updated TLS reference to latest version RFC5246.
5. Boiler plate update.
Changes from -02 Changes from -02
1. Added limit element to addressbook-query. 1. Added limit element to addressbook-query.
2. Specified how a server signals that query results have been 2. Specified how a server signals that query results have been
truncated. truncated.
3. Minor stylistic changes. 3. Minor stylistic changes.
Changes from -01 Changes from -01
skipping to change at page 52, line 4 skipping to change at line 2267
Author's Address Author's Address
Cyrus Daboo Cyrus Daboo
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Email: cyrus@daboo.name Email: cyrus@daboo.name
URI: http://www.apple.com/ URI: http://www.apple.com/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 20 change blocks. 
36 lines changed or deleted 57 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/