idnits 2.17.1 draft-daboo-carddav-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2157. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2008) is 5900 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple 4 Expires: August 26, 2008 February 23, 2008 6 vCard Extensions to WebDAV (CardDAV) 7 draft-daboo-carddav-04 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 26, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document defines extensions to the Web Distributed Authoring and 41 Versioning (WebDAV) protocol to specify a standard way of accessing, 42 managing, and sharing contact information based on the vCard format. 44 Discussion of this Internet-Draft is taking place on the mailing list 45 . 47 Table of Contents 49 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 50 1.1. IMSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 1.3. LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 1.4. SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 1.5. WebDAV for Address Books . . . . . . . . . . . . . . . . . 6 55 1.6. vCard . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 7 58 2.2. XML Namespaces and Processing . . . . . . . . . . . . . . 8 59 3. Requirements Overview . . . . . . . . . . . . . . . . . . . . 8 60 4. Address Book Data Model . . . . . . . . . . . . . . . . . . . 9 61 4.1. Address Book Server . . . . . . . . . . . . . . . . . . . 9 62 5. Address Book Resources . . . . . . . . . . . . . . . . . . . . 10 63 5.1. Address Object Resources . . . . . . . . . . . . . . . . . 10 64 5.2. Address Book Collections . . . . . . . . . . . . . . . . . 10 65 6. Address Book Feature . . . . . . . . . . . . . . . . . . . . . 11 66 6.1. Address Book Support . . . . . . . . . . . . . . . . . . . 11 67 6.1.1. Example: Using OPTIONS for the Discovery of 68 Support for CardDAV . . . . . . . . . . . . . . . . . 12 69 6.2. Address Book Properties . . . . . . . . . . . . . . . . . 12 70 6.2.1. CARDDAV:addressbook-description Property . . . . . . . 12 71 6.2.2. CARDDAV:supported-address-data Property . . . . . . . 13 72 6.2.3. CARDDAV:max-resource-size Property . . . . . . . . . . 14 73 6.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 15 74 6.3.1. Extended MKCOL Method . . . . . . . . . . . . . . . . 15 75 6.3.1.1. Example - Successful MKCOL request . . . . . . . . 15 76 6.3.2. Creating Address Object Resources . . . . . . . . . . 17 77 6.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 18 78 6.3.2.2. Non-Standard vCard Properties, and Parameters . . 19 79 6.3.2.3. Address Object Resource Entity Tag . . . . . . . . 19 80 7. Address Book Access Control . . . . . . . . . . . . . . . . . 20 81 7.1. Additional Principal Properties . . . . . . . . . . . . . 20 82 7.1.1. CARDDAV:addressbook-home-set Property . . . . . . . . 20 83 7.1.2. CARDDAV:principal-address Property . . . . . . . . . . 21 84 8. Address Book Reports . . . . . . . . . . . . . . . . . . . . . 22 85 8.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 22 86 8.2. Ordinary collections . . . . . . . . . . . . . . . . . . . 22 87 8.3. Searching Text: Collations . . . . . . . . . . . . . . . . 22 88 8.3.1. CARDDAV:supported-collation-set Property . . . . . . . 23 89 8.4. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 24 90 8.5. Non-standard properties and parameters . . . . . . . . . . 24 91 8.6. CARDDAV:addressbook-query Report . . . . . . . . . . . . . 25 92 8.6.1. Example: Partial retrieval of vCards matching a 93 NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 26 94 8.6.2. Example: Partial retrieval of vCards matching a 95 full name . . . . . . . . . . . . . . . . . . . . . . 28 96 8.7. CARDDAV:addressbook-multiget Report . . . . . . . . . . . 31 97 8.7.1. Example: CARDDAV:addressbook-multiget Report . . . . . 32 98 9. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 9.1. Restrict the Properties Returned . . . . . . . . . . . . . 33 100 9.2. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 34 101 9.3. Finding address books . . . . . . . . . . . . . . . . . . 34 102 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 36 103 10.1. CARDDAV:addressbook XML Element . . . . . . . . . . . . . 36 104 10.2. CARDDAV:supported-collation XML Element . . . . . . . . . 36 105 10.3. CARDDAV:addressbook-query XML Element . . . . . . . . . . 36 106 10.4. CARDDAV:address-data XML Element . . . . . . . . . . . . . 37 107 10.4.1. CARDDAV:allprop XML Element . . . . . . . . . . . . . 38 108 10.4.2. CARDDAV:prop XML Element . . . . . . . . . . . . . . . 39 109 10.5. CARDDAV:filter XML Element . . . . . . . . . . . . . . . . 40 110 10.5.1. CARDDAV:prop-filter XML Element . . . . . . . . . . . 40 111 10.5.2. CARDDAV:param-filter XML Element . . . . . . . . . . . 41 112 10.5.3. CARDDAV:is-not-defined XML Element . . . . . . . . . . 41 113 10.5.4. CARDDAV:text-match XML Element . . . . . . . . . . . . 42 114 10.6. CARDDAV:addressbook-multiget XML Element . . . . . . . . . 43 115 11. Internationalization Considerations . . . . . . . . . . . . . 43 116 12. Security Considerations . . . . . . . . . . . . . . . . . . . 43 117 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 44 118 13.1. Namespace Registration . . . . . . . . . . . . . . . . . . 44 119 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 120 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 121 15.1. Normative References . . . . . . . . . . . . . . . . . . . 45 122 15.2. Informative References . . . . . . . . . . . . . . . . . . 46 123 Appendix A. Change History (to be removed prior to 124 publication as an RFC) . . . . . . . . . . . . . . . 46 125 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 126 Intellectual Property and Copyright Statements . . . . . . . . . . 48 128 1. Introduction and Overview 130 Address books containing contact information are a key component of 131 personal information management tools, such as email, calendaring and 132 scheduling, and instant messaging clients. To date several protocols 133 have been used for remote access to contact data, including 134 Lightweight Directory Access Protocol LDAP [RFC2251], Internet 135 Message Support Protocol IMSP [IMSP] and Application Configuration 136 Access Protocol ACAP [RFC2244], together with SyncML used for 137 synchronization of such data. 139 1.1. IMSP 141 IMSP [IMSP], which was the predecessor to ACAP [RFC2244], received 142 limited support from vendors, but those that did implement solutions 143 based on it, found it to be a useful feature for large deployments of 144 email clients at sites where users may roam from machine to machine. 145 IMSP provided for multiple personal, shared or public address books, 146 organized in a hierarchy, and gave individual users the ability to 147 control access to their address books so that they could grant read 148 or write access rights to other specific users or groups. This 149 provided an easy and convenient way for users or workgroups to 150 quickly setup and manage shared address information. Address book 151 support in IMSP suffers from a number of problems, including a 152 limited format for the address data itself, and scalability issues 153 with large address books. 155 The key features of address book support in IMSP are: 157 1. Ability to use multiple address books with hierarchical layout. 159 2. Ability to control access to individual address books. 161 3. Server-side searching of address data, avoiding the need for 162 clients to download an entire address book in order to do a quick 163 address 'expansion' operation. 165 4. Ability to download/upload an individual address in an address 166 book. 168 The key disadvantages of address book support in IMSP are: 170 1. Limited schema for address data. 172 2. Does not scale to large address books (e.g. no way to page 173 through the list of addresses in an address book). 175 3. Does not provide any type of synchronization capability, which 176 easily leads to 'lost update' problems when multiple users are 177 editing the same address book entries. 179 4. Lack of internationalization support. 181 5. Does not provide per-address access control. 183 6. Does not provide a simple way to lookup users on the system. 185 1.2. ACAP 187 ACAP [RFC2244] was meant as the successor to IMSP and as such was 188 designed to be a more 'generic' data access protocol for general 189 application use. ACAP defined specific 'datasets' (basically formal 190 schema definitions) for different anticipated areas of use, including 191 address books, email accounts, application preferences, mime types 192 etc. The use of such formal schema definitions was intended to 193 enhance interoperability between clients. However, ACAP proved 194 difficult to implement due to over complexity in the protocol itself, 195 and this lead to few implementations. 197 The key features of address book support in ACAP are: 199 1. Ability to use multiple address books with hierarchical layout. 201 2. Ability to control access to individual address books and 202 address entries. 204 3. Server-side searching of address data, avoiding the need for 205 clients to download an entire address book in order to do a 206 quick address 'expansion' operation. 208 4. Ability to inherit address book data from others. 210 5. Ability to watch changes in address book data through use of 211 'contexts'. 213 6. Ability to page through address book data through use of 214 'contexts'. 216 7. Internationalization support through use of UTF-8 for all data. 218 8. Well defined address schema to enhance client interoperability. 220 9. Compatibility with vCard data format. 222 10. Users and groups dataset can be used to enumerate and find other 223 users on the system. 225 The key disadvantages of address book support in ACAP are: 227 1. Inheritance, access control and contexts all together is hard, 228 and ultimately proved one of the major hurdles to 229 implementations. 231 1.3. LDAP 233 LDAP [RFC2251] is a generic directory access protocol that is 234 specifically targeted at management applications and browser 235 applications that provide read/write interactive access to 236 directories. Often such directories contain information about 237 people, including contact/address data. 239 The key features of address book support in LDAP are: 241 1. To do. 243 The key disadvantages of address book support in LDAP are: 245 1. Lack of schemas require overly complex client configuration to 246 map expected fields in the client to directory entries in the 247 server. 249 2. General reluctance to give 'ordinary' users write access to even 250 a small portion of the directory as often sensitive information 251 is included in directory entries and a small mistake in 252 configuring access control can lead to a major security breach. 254 1.4. SyncML 256 SyncML is a protocol for synchronizing data, including contacts, 257 between different devices. 259 More... 261 1.5. WebDAV for Address Books 263 WebDAV [RFC4918] offers a number of advantages as a framework or 264 basis for address book access and management. Most of these 265 advantages boil down to a significant reduction in design costs, 266 implementation costs, interoperability test costs and deployment 267 costs. 269 The key features of address book support with WebDAV are: 271 1. Ability to use multiple address books with hierarchical layout. 273 2. Ability to control access to individual address books and address 274 entries. 276 3. Principal namespace can be used to enumerate and find other users 277 on the system. 279 4. Server-side searching of address data, avoiding the need for 280 clients to download an entire address book in order to do a quick 281 address 'expansion' operation. 283 5. Well-defined internationalization support through standard HTTP. 285 6. Use of vCards for well defined address schema to enhance client 286 interoperability. 288 7. Many limited clients (e.g. mobile devices) contain an HTTP stack 289 which makes implementing WebDAV much easier than other protocols. 291 The key disadvantages of address book support in WebDAV are: 293 1. Lack of change notification. 295 2. Stateless nature of protocol can result in more data being sent 296 with each transaction to maintain per-user session across 297 requests. 299 1.6. vCard 301 vCard [RFC2426] is a MIME directory profile aimed at encapsulating 302 personal addressing and contact information about people. The 303 specification of vCard was originally done by the Versit consortium, 304 with a subsequent 3.0 version standardized by the IETF [RFC2426]. 305 vCard is in wide spread use in email clients and mobile devices as a 306 means of encapsulating address information for transport via email, 307 or for import/export and synchronization operations. 309 2. Conventions 311 2.1. Notational Conventions 313 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 314 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 315 document are to be interpreted as described in [RFC2119]. 317 The term "protected" is used in the Conformance field of property 318 definitions as defined in Section 15 of [RFC4918]. 320 When XML element types in the namespaces "DAV:" and 321 "urn:ietf:params:xml:ns:carddav" are referenced in this document 322 outside of the context of an XML fragment, the string "DAV:" and 323 "CARDDAV:" will be prefixed to the element type names, respectively. 325 2.2. XML Namespaces and Processing 327 Definitions of XML elements in this document use XML element type 328 declarations (as found in XML Document Type Declarations), described 329 in Section 3.2 of [W3C.REC-xml-20060816]. 331 The namespace "urn:ietf:params:xml:ns:carddav" is reserved for the 332 XML elements defined in this specification, its revisions, and 333 related CardDAV specifications. XML elements defined by individual 334 implementations MUST NOT use the "urn:ietf:params:xml:ns:carddav" 335 namespace, and instead should use a namespace that they control. 337 The XML declarations used in this document do not include namespace 338 information. Thus, implementers must not use these declarations as 339 the only way to create valid CardDAV properties or to validate 340 CardDAV XML element type. Some of the declarations refer to XML 341 elements defined by WebDAV [RFC4918] which use the "DAV:" namespace. 342 Wherever such XML elements appear, they are explicitly prefixed with 343 "DAV:" to avoid confusion. 345 Also note that some CardDAV XML element names are identical to WebDAV 346 XML element names, though their namespace differs. Care must be 347 taken not to confuse the two sets of names. 349 Processing of XML by CardDAV clients and servers MUST follow the 350 rules described in Appendix A of [RFC4918]. 352 3. Requirements Overview 354 This section lists what functionality is required of a CardDAV 355 server. To advertise support for CardDAV, a server: 357 o MUST support vCard [RFC2426] as a media type for the address 358 object resource format; 360 o MUST support WebDAV Class 3 [RFC4918]; 362 o MUST support WebDAV ACL [RFC3744]; 363 o MUST support secure transport as defined in [RFC2818] using TLS 364 v1.0 [RFC2246] or a subsequent standards-track version of TLS; 366 o MUST support ETags [RFC2616] with additional requirements 367 specified in Section 6.3.2.3 of this document; 369 o MUST support all address book REPORTs defined in Section 8 of this 370 document; and 372 o MUST advertise support on all addressbook collections and address 373 object resources for the addressbook reports in the DAV:supported- 374 report-set property, as defined in Versioning Extensions to WebDAV 375 [RFC3253]. 377 In addition, a server: 379 o SHOULD support the extended MKCOL method 380 [draft-daboo-webdav-mkcol-00] to create address book collections 381 as defined in Section 6.3.1 of this document. 383 4. Address Book Data Model 385 As a brief overview, a CardDAV address book is modeled as a WebDAV 386 collection with a well defined structure; each of these address book 387 collections contain a number of resources representing address 388 objects as their direct child resources. Each resource representing 389 an address object is called an "address object resource". Each 390 address object resource and each address book collection can be 391 individually locked and have individual WebDAV properties. 392 Requirements derived from this model are provided in Section 5.1 and 393 Section 5.2. 395 4.1. Address Book Server 397 A CardDAV server is an address-aware engine combined with a WebDAV 398 server. The server may include address data in some parts of its URL 399 namespace, and non-address data in other parts. 401 A WebDAV server can advertise itself as a CardDAV server if it 402 supports the functionality defined in this specification at any point 403 within the root of its repository. That might mean that address data 404 is spread throughout the repository and mixed with non-address data 405 in nearby collections (e.g. address data may be found in /lisa/ 406 addressbook/ as well as in /bernard/addressbook/, and non-address 407 data in /lisa/calendars/). Or, it might mean that address data can 408 be found only in certain sections of the repository (e.g. 409 /addressbooks/user/). Address book features are only required in the 410 repository sections that are or contain address objects. So a 411 repository confining address data to the /carddav/ collection would 412 only need to support the CardDAV required features within that 413 collection. 415 The CardDAV server is the canonical location for address data and 416 state information. Clients may submit requests to change data or 417 download data. Clients may store address objects offline and attempt 418 to synchronize at a later time. However, clients MUST be prepared 419 for address data on the server to change between the time of last 420 synchronization and when attempting an update, as address book 421 collections may be shared and accessible via multiple clients. 422 Entity tags and other features help this work. 424 5. Address Book Resources 426 5.1. Address Object Resources 428 This specification uses vCard as the default format for address or 429 contact information being stored on the server. However, this 430 specification does allow other formats for address data provided that 431 the server advertises support for those additional formats as 432 described below. The requirements in this section pertain to vCard 433 address data, or formats that follow the semantics of vCard data. 435 Address object resources contained in address book collections MUST 436 contain a single vCard component only. 438 vCard components in an address book collection MUST have a UID 439 property value that MUST be unique in the scope of the address book 440 collection in which it is contained. 442 5.2. Address Book Collections 444 Address book collections appear to clients as a WebDAV collection 445 resource, identified by a URL. An address book collection MUST 446 report the DAV:collection and CARDDAV:addressbook XML elements in the 447 value of the DAV:resourcetype property. The element type declaration 448 for CARDDAV:addressbook is: 450 452 An address book collection can be created through provisioning (e.g., 453 automatically created when a user's account is provisioned), or it 454 can be created with the extended MKCOL method (see Section 6.3.1). 455 This can be used by a user to create additional address books (e.g., 456 "soccer team members") or for users to share an address book (e.g., 457 "sales team contacts"). Note however that this document doesn't 458 define what extra address book collections are for. Users must rely 459 on non-standard cues to find out what an address book collection is 460 for, or use the CARDDAV:addressbook-description property defined in 461 Section 6.2.1 to provide such a cue. 463 The following restrictions are applied to the resources within an 464 address book collection: 466 a. Address book collections MUST only contain address object 467 resources and collections that are not address book collections. 468 i.e., the only "top-level" non-collection resources allowed in an 469 address book collection are address object resources. This 470 ensures that address book clients do not have to deal with non- 471 address data in an address book collection, though they do have 472 to distinguish between address object resources and collections 473 when using standard WebDAV techniques to examine the contents of 474 a collection. 476 b. Collections contained in address book collections MUST NOT 477 contain address book collections at any depth. i.e., "nesting" of 478 address book collections within other address book collections at 479 any depth is not allowed. This specification does not define how 480 collections contained in an address book collection are used or 481 how they relate to any address object resources contained in the 482 address book collection. 484 Multiple address book collections MAY be children of the same 485 collection. 487 6. Address Book Feature 489 6.1. Address Book Support 491 A server supporting the features described in this document, MUST 492 include "addressbook" as a field in the DAV response header from an 493 OPTIONS request on any resource that supports any address book 494 properties, reports, or methods. A value of "addressbook" in the DAV 495 response header MUST indicate that the server supports all MUST level 496 requirements and REQUIRED features specified in this document. 498 6.1.1. Example: Using OPTIONS for the Discovery of Support for CardDAV 500 >> Request << 502 OPTIONS /addressbooks/users/ HTTP/1.1 503 Host: addressbook.example.com 505 >> Response << 507 HTTP/1.1 200 OK 508 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 509 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL 510 DAV: 1, 2, 3, access-control, addressbook 511 DAV: extended-mkcol 512 Date: Sat, 11 Nov 2006 09:32:12 GMT 513 Content-Length: 0 515 In this example, the OPTIONS response indicates that the server 516 supports CardDAV in this namespace, therefore the '/addressbooks/ 517 users/' collection may be used as a parent for address book 518 collections as the extended MKCOL method is available, and as a 519 possible target for REPORT requests for address book reports. 521 6.2. Address Book Properties 523 6.2.1. CARDDAV:addressbook-description Property 525 Name: addressbook-description 527 Namespace: urn:ietf:params:xml:ns:carddav 529 Purpose: Provides a human-readable description of the address book 530 collection. 532 Value: Any text. 534 Protected: SHOULD NOT be protected so that users can specify a 535 description. 537 COPY/MOVE behavior: This property value SHOULD be preserved in COPY 538 and MOVE operations. 540 allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop 541 request. 543 Description: This property contains a description of the address 544 book collection that is suitable for presentation to a user. 546 Definition: 548 549 551 Example: 553 Adresses de Oliver Daboo 557 6.2.2. CARDDAV:supported-address-data Property 559 Name: supported-address-data 561 Namespace: urn:ietf:params:xml:ns:carddav 563 Purpose: Specifies what media types are allowed for address object 564 resources in an address book collection. 566 Protected: MUST be protected as it indicates the level of support 567 provided by the server. 569 COPY/MOVE behavior: This property value MUST be preserved in COPY 570 and MOVE operations. 572 allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop 573 request. 575 Description: The CARDDAV:supported-address-data property is used to 576 specify the media type supported for the address object resources 577 contained in a given address book collection (e.g., vCard version 578 3.0). Any attempt by the client to store address object resources 579 with a media type not listed in this property MUST result in an 580 error, with the CARDDAV:supported-address-data precondition 581 (Section 6.3.2.1) being violated. In the absence of this property 582 the server MUST only accept data with the media type "text/vcard" 583 and vCard version 3.0, and clients can assume that. 585 Definition: 587 589 Example: 591 593 594 596 6.2.3. CARDDAV:max-resource-size Property 598 Name: max-resource-size 600 Namespace: urn:ietf:params:xml:ns:carddav 602 Purpose: Provides a numeric value indicating the maximum size of a 603 resource in octets that the server is willing to accept when an 604 address object resource is stored in an address book collection. 606 Value: Any text representing a numeric value. 608 Protected: MUST be protected as it indicates limits provided by the 609 server. 611 COPY/MOVE behavior: This property value MUST be preserved in COPY 612 and MOVE operations. 614 allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop 615 request. 617 Description: The CARDDAV:max-resource-size is used to specify a 618 numeric value that represents the maximum size in octets that the 619 server is willing to accept when an address object resource is 620 stored in an address book collection. Any attempt to store an 621 address book object resource exceeding this size MUST result in an 622 error, with the CARDDAV:max-resource-size precondition 623 (Section 6.3.2.1) being violated. In the absence of this property 624 the client can assume that the server will allow storing a 625 resource of any reasonable size. 627 Definition: 629 630 632 Example: 634 102400 637 6.3. Creating Resources 639 Address book collections and address object resources may be created 640 by either a CardDAV client or by the CardDAV server. This 641 specification defines restrictions and a data model that both clients 642 and servers MUST adhere to when manipulating such address data. 644 6.3.1. Extended MKCOL Method 646 An HTTP request using the extended MKCOL method 647 [draft-daboo-webdav-mkcol-00] can be used to create a new address 648 book collection resource. A server MAY restrict address book 649 collection creation to particular collections. 651 To create an address book, the client sends an extended MKCOL request 652 to the server and in the body of the request sets the DAV: 653 resourcetype property to the resource type for an address book 654 collection as defined in Section 5.2. 656 Support for creating address books on the server is only RECOMMENDED 657 and not REQUIRED because some address book stores only support one 658 address book per user (or principal), and those are typically pre- 659 created for each account. However, servers and clients are strongly 660 encouraged to support address book creation whenever possible to 661 allow users to create multiple address book collections to help 662 organize their data better. 664 Clients SHOULD use the DAV:displayname property for a human-readable 665 name of the address book. Clients can either specify the value of 666 the DAV:displayname property in the request body of the extended 667 MKCOL request, or alternatively issue a PROPPATCH request to change 668 the DAV:displayname property to the appropriate value immediately 669 after using the extended MKCOL request. Clients SHOULD NOT set the 670 DAV: displayname property to be the same as any other address book 671 collection at the same URI "level". When displaying address book 672 collections to users, clients SHOULD check the DAV:displayname 673 property and use that value as the name of the address book. In the 674 event that the DAV: displayname property is not set, the client MAY 675 use the last part of the address book collection URI as the name, 676 however that path segment may be "opaque" and not represent any 677 meaningful human-readable text. 679 6.3.1.1. Example - Successful MKCOL request 681 This example creates an address book collection called /home/lisa/ 682 addressbook/ on the server addressbook.example.com with specific 683 values for the properties DAV:resourcetype, DAV:displayname and 684 CARDDAV:addressbook-description. 686 >> Request << 688 MKCOL /home/lisa/addressbook/ HTTP/1.1 689 Host: addressbook.example.com 690 Content-Type: text/xml; charset="utf-8" 691 Content-Length: xxx 693 694 696 697 698 699 700 701 702 Lisa's Contacts 703 My primary address book. 705 706 707 709 >> Response << 711 HTTP/1.1 201 Created 712 Cache-Control: no-cache 713 Date: Sat, 11 Nov 2006 09:32:12 GMT 714 Content-Type: application/xml; charset="utf-8" 715 Content-Length: xxxx 717 718 720 721 722 723 724 725 726 HTTP/1.1 200 OK 727 728 730 6.3.2. Creating Address Object Resources 732 Clients populate address book collections with address object 733 resources. The URL for each address object resource is entirely 734 arbitrary, and does not need to bear a specific relationship (but 735 might) to the address object resource's vCard properties or other 736 metadata. New address object resources MUST be created with a PUT 737 request targeted at an unmapped URI. A PUT request targeted at a 738 mapped URI updates an existing address object resource. 740 When servers create new resources, it's not hard for the server to 741 choose a unique URL. It's slightly tougher for clients, because a 742 client might not want to examine all resources in the collection, and 743 might not want to lock the entire collection to ensure that a new one 744 isn't created with a name collision. However, there is an HTTP 745 feature to mitigate this. If the client intends to create a new 746 address resource the client SHOULD use the HTTP header "If-None- 747 Match: *" on the PUT request. The Request-URI on the PUT request 748 MUST include the target collection, where the resource is to be 749 created, plus the name of the resource in the last path segment. The 750 "If-None-Match" header ensures that the client will not inadvertently 751 overwrite an existing resource even, if the last path segment turned 752 out to already be used. 754 >> Request << 756 PUT /lisa/addressbook/newvcard.vcf HTTP/1.1 757 If-None-Match: * 758 Host: addressbook.example.com 759 Content-Type: text/vcard 760 Content-Length: xxx 762 BEGIN:VCARD 763 VERSION:3.0 764 FN:Cyrus Daboo 765 N:Daboo;Cyrus 766 ADR;TYPE=POSTAL:;2822 Email HQ;Suite 2821;RFCVille;PA;15213;USA 767 EMAIL;TYPE=INTERNET,PREF:cyrus@example.com 768 NICKNAME:me 769 NOTE:Example VCard. 770 ORG:Self Employed 771 TEL;TYPE=WORK,VOICE:412 605 0499 772 TEL;TYPE=FAX:412 605 0705 773 URL:http://www.example.com 774 UID:1234-5678-9000-1 775 END:VCARD 776 >> Response << 778 HTTP/1.1 201 Created 779 Date: Thu, 02 Sep 2004 16:53:32 GMT 780 Content-Length: 0 781 ETag: "123456789-000-111" 783 The request to change an existing address object resource is the 784 same, but with a specific ETag in the "If-Match" header, rather than 785 the "If-None-Match" header. 787 File names for vCards are commonly suffixed by ".vcf", and clients 788 may choose to use the same convention for URLs. 790 6.3.2.1. Additional Preconditions for PUT, COPY and MOVE 792 This specification creates additional Preconditions for PUT, COPY and 793 MOVE methods. These preconditions apply: 795 o When a PUT operation of an address object resource into an address 796 book collection occurs. 798 o When a COPY or MOVE operation of an address object resource into 799 an address book collection occurs. 801 The new preconditions are: 803 (CARDDAV:supported-address-data): The resource submitted in the 804 PUT request, or targeted by a COPY or MOVE request MUST be a 805 supported media type (i.e., vCard) for address object resources; 807 (CARDDAV:valid-address-data): The resource submitted in the PUT 808 request, or targeted by a COPY or MOVE request MUST be valid data 809 for the media type being specified (i.e., MUST contain valid vCard 810 data); 812 (CARDDAV:no-uid-conflict): The resource submitted in the PUT 813 request, or targeted by a COPY or MOVE request MUST NOT specify a 814 vCard UID property value already in use in the targeted address 815 book collection or overwrite an existing address object resource 816 with one that has a different UID property value. Servers SHOULD 817 report the URL of the resource that is already making use of the 818 same UID property value in the DAV:href element; 820 822 (CARDDAV:addressbook-collection-location-ok): In a COPY or MOVE 823 request, when the Request-URI is an address book collection, the 824 URI targeted by the Destination HTTP Request header MUST identify 825 a location where an address book collection can be created; 827 (CARDDAV:max-resource-size): The resource submitted in the PUT 828 request, or targeted by a COPY or MOVE request MUST have an octet 829 size less than or equal to the value of the CARDDAV:max-resource- 830 size property value (Section 6.2.3) on the address book collection 831 where the resource will be stored; 833 6.3.2.2. Non-Standard vCard Properties, and Parameters 835 vCard provides a "standard mechanism for doing non-standard things". 836 This extension support allows implementers to make use of non- 837 standard properties and parameters whose names are prefixed with the 838 text "X-". 840 Servers MUST support the use of non-standard properties and 841 parameters in address object resources stored via the PUT method. 843 Servers may need to enforce rules for their own "private" properties 844 or parameters, so servers MAY reject any attempt by the client to 845 change those or use values for those outside of any restrictions the 846 server may have. Servers SHOULD ensure that any "private" properties 847 or parameters it uses follow the convention of including a vendor id 848 in the "X-" name, as described in Section 3.8 of [RFC2426], e.g., 849 "X-ABC-PRIVATE". 851 6.3.2.3. Address Object Resource Entity Tag 853 The DAV:getetag property MUST be defined and set to a strong entity 854 tag on all address object resources. 856 A response to a GET request targeted at an address object resource 857 MUST contain an ETag response header field indicating the current 858 value of the strong entity tag of the address object resource. 860 Servers SHOULD return a strong entity tag (ETag header) in a PUT 861 response when the stored address object resource is equivalent by 862 octet equality to the address object resource submitted in the body 863 of the PUT request. This allows clients to reliably use the returned 864 strong entity tag for data synchronization purposes. For instance, 865 the client can do a PROPFIND request on the stored address object 866 resource and have the DAV:getetag property returned, and compare that 867 value with the strong entity tag it received on the PUT response, and 868 know that if they are equal, then the address object resource on the 869 server has not been changed. 871 In the case where the data stored by a server as a result of a PUT 872 request is not equivalent by octet equality to the submitted address 873 object resource, the behavior of the ETag response header is not 874 specified here, with the exception that a strong entity tag MUST NOT 875 be returned in the response. As a result, clients may need to 876 retrieve the modified address object resource (and ETag) as a basis 877 for further changes, rather than use the address object resource it 878 had sent with the PUT request. 880 7. Address Book Access Control 882 CardDAV servers MUST support and adhere to the requirements of WebDAV 883 ACL [RFC3744]. WebDAV ACL provides a framework for an extensible set 884 of privileges that can be applied to WebDAV collections and ordinary 885 resources. 887 7.1. Additional Principal Properties 889 This section defines additional properties for WebDAV principal 890 resources as defined in [RFC3744]. 892 7.1.1. CARDDAV:addressbook-home-set Property 894 Name: addressbook-home-set 896 Namespace: urn:ietf:params:xml:ns:carddav 898 Purpose: Identifies the URL of any WebDAV collections that contain 899 address book collections owned by the associated principal 900 resource. 902 Protected: MAY be protected if the server has fixed locations in 903 which address books are created. 905 COPY/MOVE behavior: This property value MUST be preserved in COPY 906 and MOVE operations. 908 allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop 909 request. 911 Description: The CARDDAV:addressbook-home-set property is meant to 912 allow users to easily find the address book collections owned by 913 the principal. Typically, users will group all the address book 914 collections that they own under a common collection. This 915 property specifies the URL of collections that either are address 916 book collections or ordinary collections that have child or 917 descendant address book collections owned by the principal. 919 Definition: 921 923 Example: 925 927 http://addressbook.example.com/bernard/addresses/ 928 930 7.1.2. CARDDAV:principal-address Property 932 Name: principal-address 934 Namespace: urn:ietf:params:xml:ns:carddav 936 Purpose: Identifies the URL of an address object resource that 937 corresponds to the user represented by the principal. 939 Protected: MAY be protected if the server provides a fixed location 940 for principal addresses. 942 COPY/MOVE behavior: This property value MUST be preserved in COPY 943 and MOVE operations. 945 allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop 946 request. 948 Description: The CARDDAV:principal-address property is meant to 949 allow users to easily find contact information for users 950 represented by principals on the system. This property specifies 951 the URL of the address object resource containing the 952 corresponding contact information. 954 Definition: 956 958 Example: 960 962 http://addressbook.example.com/system/cyrus.vcf 963 965 8. Address Book Reports 967 This section defines the reports that CardDAV servers MUST support on 968 address book collections and address object resources. 970 CardDAV servers MUST advertise support for these REPORTs on all 971 address book collections and address object resources with the DAV: 972 supported-report-set property defined in Section 3.1.5 of [RFC3253]. 973 CardDAV servers MAY also advertise support for these REPORTs on 974 ordinary collections. 976 Some of these REPORTs allow address data (from possibly multiple 977 resources) to be returned. 979 8.1. REPORT Method 981 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an 982 extensible mechanism for obtaining information about a resource. 983 Unlike the PROPFIND method, which returns the value of one or more 984 named properties, the REPORT method can involve more complex 985 processing. REPORT is valuable in cases where the server has access 986 to all of the information needed to perform the complex request (such 987 as a query), and where it would require multiple requests for the 988 client to retrieve the information needed to perform the same 989 request. 991 A server that supports this specification MUST support the DAV: 992 expand-property report (defined in Section 3.8 of [RFC3253]). 994 8.2. Ordinary collections 996 Servers MAY support the REPORTs defined in this document on ordinary 997 collections (collections that are not address book collections) in 998 addition to address book collections or address object resources. In 999 computing responses to the REPORTs on ordinary collections, servers 1000 MUST only consider address object resources contained in address book 1001 collections that are targeted by the REPORT based on the value of the 1002 Depth request header. 1004 8.3. Searching Text: Collations 1006 Some of the reports defined in this section do text matches of 1007 character strings provided by the client and compared to stored 1008 address data. Since vCard data is by default encoded in the UTF-8 1009 charset and may include characters outside of the US-ASCII charset 1010 range in some property and parameter values, there is a need to 1011 ensure that text matching follows well-defined rules. 1013 To deal with this, this specification makes use of the IANA Collation 1014 Registry defined in [RFC4790] to specify collations that may be used 1015 to carry out the text comparison operations with a well-defined rule. 1017 Collations supported by the server MUST support "equality" and 1018 "substring" match operations as per [RFC4790] Section 4.2, including 1019 the "prefix" and "suffix" options for "substring" matching. CardDAV 1020 uses these match options for "equals", "contains", "starts-with" and 1021 "ends-with" match operations. 1023 CardDAV servers are REQUIRED to support the "i;ascii-casemap" 1024 [RFC4790] and "i;unicode-casemap" [RFC5051] collations, and MAY 1025 support other collations. 1027 Servers MUST advertise the set of collations that they support via 1028 the CARDDAV:supported-collation-set property defined on any resource 1029 that supports reports that use collations. 1031 In the absence of a collation explicitly specified by the client, or 1032 if the client specifies the "default" collation identifier (as 1033 defined in [RFC4790] Section 3.1), the server MUST default to using 1034 "i;unicode-casemap" as the collation. 1036 Wildcards (as defined in [RFC4790] Section 3.2) MUST NOT be used in 1037 the collation identifier. 1039 If the client chooses a collation not supported by the server, the 1040 server MUST respond with a CARDDAV:supported-collation precondition 1041 error response. 1043 8.3.1. CARDDAV:supported-collation-set Property 1045 Name: supported-collation-set 1047 Namespace: urn:ietf:params:xml:ns:carddav 1049 Purpose: Identifies the set of collations supported by the server 1050 for text matching operations. 1052 Protected: MUST be protected as it indicates support provided by the 1053 server. 1055 COPY/MOVE behavior: This property value MUST be preserved in COPY 1056 and MOVE operations. 1058 allprop behavior: SHOULD be returned by a PROPFIND DAV:allprop 1059 request. 1061 Description: The CARDDAV:supported-collation-set property contains 1062 zero or more CARDDAV:supported-collation elements which specify 1063 the collection identifiers of the collations supported by the 1064 server. 1066 Definition: 1068 1070 1072 Example: 1074 1076 i;ascii-casemap 1077 i;octet 1078 i;unicode-casemap 1079 1081 8.4. Partial Retrieval 1083 Some address book REPORTs defined in this document allow partial 1084 retrieval of address object resources. A CardDAV client can specify 1085 what information to return in the body of an address book REPORT 1086 request. 1088 A CardDAV client can request particular WebDAV property values, all 1089 WebDAV property values, or a list of the names of the resource's 1090 WebDAV properties. A CardDAV client can also request address data to 1091 be returned and whether all vCard properties should be returned or 1092 only particular ones. See CARDDAV:address-data in Section 10.4. 1094 8.5. Non-standard properties and parameters 1096 Servers MUST support the use of non-standard property or parameter 1097 names in the CARDDAV:address-data XML element in address book REPORT 1098 requests to allow clients to request that non-standard properties and 1099 parameters be returned in the address data provided in the response. 1101 Servers MAY support the use of non-standard property or parameter 1102 names in the CARDDAV:prop-filter and CARDDAV:param-filter XML 1103 elements specified in the CARDDAV:filter XML element of address book 1104 REPORT requests. 1106 Servers MUST fail with the CARDDAV:supported-filter precondition if 1107 an address book REPORT request uses a CARDDAV:prop-filter or CARDDAV: 1108 param-filter XML element that makes reference to a non-standard 1109 property or parameter name which the server does not support queries 1110 on. 1112 8.6. CARDDAV:addressbook-query Report 1114 The CARDDAV:addressbook-query REPORT performs a search for all 1115 address object resources that match a specified filter. The response 1116 of this REPORT will contain all the WebDAV properties and address 1117 object resource data specified in the request. In the case of the 1118 CARDDAV:address-data XML element, one can explicitly specify the 1119 vCard properties that should be returned in the address object 1120 resource data that matches the filter. 1122 The format of this report is modeled on the PROPFIND method. The 1123 request and response bodies of the CARDAV:addressbook-query report 1124 use XML elements that are also used by PROPFIND. In particular the 1125 request can include XML elements to request WebDAV properties to be 1126 returned. When that occurs the response should follow the same 1127 behavior as PROPFIND with respect to the DAV:multistatus response 1128 elements used to return specific property results. For instance, a 1129 request to retrieve the value of a property which does not exist is 1130 an error and MUST be noted with a response XML element which contains 1131 a 404 (Not Found) status value. 1133 Support for the CARDDAV:addressbook-query REPORT is REQUIRED. 1135 Marshalling: 1137 The request body MUST be a CARDDAV:addressbook-query XML element 1138 as defined in Section 10.3. 1140 The request MAY include a Depth header. If no Depth header is 1141 included, Depth:0 is assumed. 1143 The response body for a successful request MUST be a DAV: 1144 multistatus XML element (i.e., the response uses the same format 1145 as the response for PROPFIND). In the case where there are no 1146 response elements, the returned DAV:multistatus XML element is 1147 empty. 1149 The response body for a successful CARDDAV:addressbook-query 1150 REPORT request MUST contain a DAV:response element for each 1151 address object that matched the search filter. address data is 1152 returned in the CARDDAV:address-data XML element inside the DAV: 1153 propstat XML element. 1155 Preconditions: 1157 (CARDDAV:supported-address-data): The attributes "content-type" 1158 and "version" of the CARDDAV:address-data XML element (see 1159 Section 10.4) specify a media type supported by the server for 1160 address object resources. 1162 (CARDDAV:supported-filter): The CARDDAV:prop-filter (see 1163 Section 10.5.1) and CARDDAV:param-filter (see Section 10.5.2) XML 1164 elements used in the CARDDAV:filter XML element (see Section 10.5) 1165 in the REPORT request only make reference to properties and 1166 parameters for which queries are supported by the server. i.e., if 1167 the CARDDAV:filter element attempts to reference an unsupported 1168 property or parameter, this precondition is violated. Servers 1169 SHOULD report the CARDDAV:prop-filter or CARDDAV:param-filter for 1170 which it does not provide support. 1172 1175 (CARDDAV:supported-collation): Any XML attribute specifying a 1176 collation MUST specify a collation supported by the server as 1177 described in Section 8.3. 1179 Postconditions: 1181 (DAV:number-of-matches-within-limits): The number of matching 1182 address object resources must fall within server-specific, 1183 predefined limits. For example, this condition might be triggered 1184 if a search specification would cause the return of an extremely 1185 large number of responses. 1187 8.6.1. Example: Partial retrieval of vCards matching a 1188 NICKNAME 1190 In this example, the client requests the server to search for address 1191 object resources that contain a NICKNAME property whose value equals 1192 some specific text, and to return specific vCard properties for those 1193 vCards found. In addition the DAV:getetag property is also requested 1194 and returned as part of the response. 1196 >> Request << 1198 REPORT /home/bernard/addressbook/ HTTP/1.1 1199 Host: addressbook.example.com 1200 Depth: 1 1201 Content-Type: text/xml; charset="utf-8" 1202 Content-Length: xxxx 1204 1205 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 me 1222 1223 1224 1225 >> Response << 1227 HTTP/1.1 207 Multi-Status 1228 Date: Sat, 11 Nov 2006 09:32:12 GMT 1229 Content-Type: text/xml; charset="utf-8" 1230 Content-Length: xxxx 1232 1233 1235 1236 /home/bernard/addressbook/v102.vcf 1237 1238 1239 "23ba4d-ff11fb" 1240 BEGIN:VCARD 1241 VERSION:3.0 1242 NICKNAME:me 1243 UID:34222-232@example.com 1244 FN:Cyrus Daboo 1245 EMAIL:daboo@example.com 1246 END:VCARD 1247 1248 1249 HTTP/1.1 200 OK 1250 1251 1252 1254 8.6.2. Example: Partial retrieval of vCards matching a full 1255 name 1257 In this example, the client requests the server to search for address 1258 object resources that contain a FN property whose value contains some 1259 specific text, and to return specific vCard properties for those 1260 vCards found. In addition the DAV:getetag property is also requested 1261 and returned as part of the response. 1263 >> Request << 1265 REPORT /home/bernard/addressbook/ HTTP/1.1 1266 Host: addressbook.example.com 1267 Depth: 1 1268 Content-Type: text/xml; charset="utf-8" 1269 Content-Length: xxxx 1271 1272 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 Daboo 1289 1290 1291 1292 >> Response << 1294 HTTP/1.1 207 Multi-Status 1295 Date: Sat, 11 Nov 2006 09:32:12 GMT 1296 Content-Type: text/xml; charset="utf-8" 1297 Content-Length: xxxx 1299 1300 1302 1303 /home/bernard/addressbook/v102.vcf 1304 1305 1306 "23ba4d-ff11fb" 1307 BEGIN:VCARD 1308 VERSION:3.0 1309 NICKNAME:me 1310 UID:34222-232@example.com 1311 FN:Cyrus Daboo 1312 EMAIL:daboo@example.com 1313 END:VCARD 1314 1315 1316 HTTP/1.1 200 OK 1317 1318 1319 1320 /home/bernard/addressbook/v104.vcf 1321 1322 1323 "23ba4d-ff11fc" 1324 BEGIN:VCARD 1325 VERSION:3.0 1326 NICKNAME:oliver 1327 UID:34222-23222@example.com 1328 FN:Oliver Daboo 1329 EMAIL:oliver@example.com 1330 END:VCARD 1331 1332 1333 HTTP/1.1 200 OK 1334 1335 1336 1338 8.7. CARDDAV:addressbook-multiget Report 1340 The CARDDAV:addressbook-multiget REPORT is used to retrieve specific 1341 address object resources from within a collection, if the Request-URI 1342 is a collection, or to retrieve a specific address object resource, 1343 if the Request-URI is a address object resource. This report is 1344 similar to the CARDDAV:addressbook-query REPORT (see Section 8.6), 1345 except that it takes a list of DAV:href elements instead of a 1346 CARDDAV:filter element to determine which address object resources to 1347 return. 1349 Support for the addressbook-multiget REPORT is REQUIRED. 1351 Marshalling: 1353 The request body MUST be a CARDDAV:addressbook-multiget XML 1354 element (see Section 10.6, which MUST contain at least one DAV: 1355 href XML element, and one optional CARDDAV:address-data element as 1356 defined in Section 10.4. If the Request-URI is a collection 1357 resource, then the DAV:href elements MUST refer to resources 1358 within that collection, and they MAY refer to resources at any 1359 depth within the collection. As a result the "Depth" header MUST 1360 be ignored by the server and SHOULD NOT be sent by the client. If 1361 the Request-URI refers to a non-collection resource, then there 1362 MUST be a single DAV:href element that is equivalent to the 1363 Request-URI. 1365 The response body for a successful request MUST be a DAV: 1366 multistatus XML element. 1368 The response body for a successful CARDDAV:addressbook-multiget 1369 REPORT request MUST contain a DAV:response element for each 1370 address object resource referenced by the provided set of DAV:href 1371 elements. Address data is returned in the CARDDAV:address-data 1372 element inside the DAV:prop element. 1374 In the case of an error accessing any of the provided DAV:href 1375 resources, the server MUST return the appropriate error status 1376 code in the DAV:status element of the corresponding DAV:response 1377 element. 1379 Preconditions: 1381 (CARDAV:supported-address-data): The attributes "content-type" and 1382 "version" of the CARDDAV:address-data XML elements (see 1383 Section 10.4) specify a media type supported by the server for 1384 address object resources. 1386 Postconditions: 1388 None. 1390 8.7.1. Example: CARDDAV:addressbook-multiget Report 1392 In this example, the client requests the server to return specific 1393 properties of the address components referenced by specific URIs. In 1394 addition the DAV:getetag property is also requested and returned as 1395 part of the response. Note that in this example, the resource at 1396 http://addressbook.example.com/home/bernard/addressbook/vcf1.vcf does 1397 not exist, resulting in an error status response. 1399 >> Request << 1401 REPORT /home/bernard/addressbook/ HTTP/1.1 1402 Host: addressbook.example.com 1403 Content-Type: text/xml; charset="utf-8" 1404 Content-Length: xxxx 1406 1407 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 /home/bernard/addressbook/vcf102.vcf 1420 /home/bernard/addressbook/vcf1.vcf 1421 1422 >> Response << 1424 HTTP/1.1 207 Multi-Status 1425 Date: Sat, 11 Nov 2006 09:32:12 GMT 1426 Content-Type: text/xml; charset="utf-8" 1427 Content-Length: xxxx 1429 1430 1432 1433 /home/bernard/addressbook/vcf102.vcf 1434 1435 1436 "23ba4d-ff11fb" 1437 BEGIN:VCARD 1438 VERSION:3.0 1439 NICKNAME:me 1440 UID:34222-232@example.com 1441 FN:Cyrus Daboo 1442 EMAIL:daboo@example.com 1443 END:VCARD 1444 1445 1446 HTTP/1.1 200 OK 1447 1448 1449 1450 /home/bernard/addressbook/vcf1.vcf 1451 HTTP/1.1 404 Resource not found 1452 1453 1455 9. Guidelines 1457 9.1. Restrict the Properties Returned 1459 Clients may not need all the properties in a vCard object when 1460 presenting information to the user, or looking up specific items for 1461 their email address, for example. Since some property data can be 1462 large (e.g., PHOTO or SOUND with inline content) clients can choose 1463 to ignore those by only requesting the specific items it knows it 1464 will use, through use of the CARDDAV:address-data XML element in the 1465 relevant reports. 1467 However, if a client needs to make a change to a vCard, it can only 1468 change the entire vCard data via a PUT request. There is no way to 1469 incrementally make a change to a set of properties within a vCard 1470 object resource. As a result the client will have to cache the 1471 entire set of properties on a resource that is being changed. 1473 9.2. Use of Locking 1475 WebDAV locks can be used to prevent two clients modifying the same 1476 resource from either overwriting each others' changes (though that 1477 problem can also be solved by using ETags) and also to prevent the 1478 user from making changes that will conflict with another set of 1479 changes. In a multi-user address book system, the address book 1480 client could lock an address object resource while the user is 1481 editing the vCard data, and unlock the address object resource when 1482 the user finishes or cancels. Locks can also be used to prevent 1483 changes while data is being reorganized. For example, an address 1484 book client might lock two address book collections prior to moving a 1485 bunch of address object resources from one to another. 1487 Clients may request a lock timeout period that is appropriate to the 1488 use case. When the user explicitly decides to reserve a resource and 1489 prevent other changes, a long timeout might be appropriate, but in 1490 cases when the client automatically decides to lock the resource the 1491 timeout should be short (and the client can always refresh the lock 1492 should it need to). A short lock timeout means that if the client is 1493 unable to remove the lock, the other address book users aren't 1494 prevented from making changes. 1496 9.3. Finding address books 1498 Much of the time an address book client (or agent) will discover a 1499 new address book's location by being provided directly with the URL. 1500 E.g. a user will type his or her own address book location into 1501 client configuration information, or cut and paste a URL from email 1502 into the address book application. The client need only confirm that 1503 the URL points to a resource which is an address book. The client 1504 may also be able to browse WebDAV collections to find address book 1505 collections. 1507 The choice of HTTP URLs means that address object resources are 1508 backward compatible with existing software, but does have the 1509 disadvantage that existing software does not usually know to look at 1510 the OPTIONS response to that URL to determine what can be done with 1511 it. This is somewhat of a barrier for WebDAV usage as well as with 1512 CardDAV usage. This specification does not offer a way through this 1513 other than making the information available in the OPTIONS response 1514 should this be requested. 1516 For address book sharing use cases, one might wish to find the 1517 address book belonging to another user. If the other user has an 1518 address book in the same repository, that address book can be found 1519 by using the principal namespace required by WebDAV ACL support. 1521 Because CardDAV requires servers to support WebDAV ACL [RFC3744] 1522 including principal namespaces, and with the addition of the CARDDAV: 1523 addressbook-home-set property, there are a couple options for CardDAV 1524 clients to find one's own address book or another user's address 1525 book. 1527 In this case, a DAV:principal-match REPORT is used to find a named 1528 property (the CARDDAV:addressbook-home-set) on the Principal-URL of 1529 the current user. Using this, a WebDAV client can learn "who am I" 1530 and "where are my address books". The REPORT request body looks like 1531 this: 1533 1534 1535 1536 1537 1539 1540 1542 To find other users' address books, the DAV:principal-property-search 1543 REPORT can be used to filter on some properties and return others. 1544 To search for an address book owned by a user named "Laurie", the 1545 REPORT request body would look like this: 1547 1548 1549 1550 1551 1552 1553 Laurie 1554 1555 1556 1558 1559 1560 1562 The server performs a case-sensitive or caseless search for a 1563 matching string subset of "Laurie" within the DAV:displayname 1564 property. Thus, the server might return "Laurie Dusseault", "Laurier 1565 Desruisseaux" or "Wilfrid Laurier" all as matching DAV:displayname 1566 values, and the address books for each of these. 1568 10. XML Element Definitions 1570 10.1. CARDDAV:addressbook XML Element 1572 Name: addressbook 1574 Namespace: urn:ietf:params:xml:ns:carddav 1576 Purpose: Specifies the resource type of an address book collection. 1578 Description: See Section 5.2. 1580 Definition: 1582 1584 10.2. CARDDAV:supported-collation XML Element 1586 Name: supported-collation 1588 Namespace: urn:ietf:params:xml:ns:carddav 1590 Purpose: Identifies a single collation via its collation identifier 1591 as defined by [RFC4790]. 1593 Description: The CARDDAV:supported-collation contains the text of a 1594 collation identifier as described in Section 8.3.1. 1596 Definition: 1598 1599 1601 10.3. CARDDAV:addressbook-query XML Element 1603 Name: addressbook-query 1605 Namespace: urn:ietf:params:xml:ns:carddav 1607 Purpose: Defines a report for querying address book data 1608 Description: See Section 8.6. 1610 Definition: 1612 1616 10.4. CARDDAV:address-data XML Element 1618 Name: address-data 1620 Namespace: urn:ietf:params:xml:ns:carddav 1622 Purpose: Specifies one of the following: 1624 1. A supported media type for address object resources when 1625 nested in the CARDDAV:supported-address-data property; 1627 2. The parts of an address object resource should be returned by 1628 a given address book REPORT; 1630 3. The content of an address object resource in a response to an 1631 address book REPORT. 1633 Description: When nested in the CARDDAV:supported-address-data 1634 property, the CARDDAV:address-data XML element specifies a media 1635 type supported by the CardDAV server for address object resources. 1637 When used in an address book REPORT request, the CARDDAV:address- 1638 data XML element specifies which parts of address object resources 1639 need to be returned in the response. If the CARDDAV:address-data 1640 XML element doesn't contain any CARDDAV:prop elements, address 1641 object resources will be returned in their entirety. 1643 Finally, when used in an address book REPORT response, the 1644 CARDDAV:address-data XML element specifies the content of a 1645 address object resource. Given that XML parsers normalize the 1646 two-character sequence CRLF (US-ASCII decimal 13 and US-ASCII 1647 decimal 10) to a single LF character (US-ASCII decimal 10), the CR 1648 character (US-ASCII decimal 13) MAY be omitted in address object 1649 resources specified in the CARDDAV:address-data XML element. 1650 Furthermore, address object resources specified in the CARDDAV: 1651 address-data XML element MAY be invalid per their media type 1652 specification if the CARDAV:address-data XML element part of the 1653 address book REPORT request did not specify required properties 1654 (e.g., UID, etc.) or specified a CARDDAV:prop XML element with the 1655 "novalue" attribute set to "yes". 1657 Note: The CARDDAV:address-data XML element is specified in requests 1658 and responses inside the DAV:prop XML element as if it were a 1659 WebDAV property. However, the CARDDAV:address-data XML element is 1660 not a WebDAV property and as such it is not returned in PROPFIND 1661 responses nor used in PROPPATCH requests. 1663 Note: The address data embedded within the CARDDAV:address-data XML 1664 element MUST follow the standard XML character data encoding 1665 rules, including use of <, >, & etc entity encoding or 1666 the use of a construct. In the later case the 1667 vCard data cannot contain the character sequence "]]>" which is 1668 the end delimiter for the CDATA section. 1670 Definition: 1672 1674 when nested in the CARDDAV:supported-address-data property 1675 to specify a supported media type for address object 1676 resources; 1678 1680 when nested in the DAV:prop XML element in an addressbook 1681 REPORT request to specify which parts of address object 1682 resources should be returned in the response; 1684 1685 1687 when nested in the DAV:prop XML element in an addressbook 1688 REPORT response to specify the content of a returned 1689 address object resource. 1691 1693 1694 1696 attributes can be used on all three variants of the 1697 CALDAV:address-data XML element. 1699 10.4.1. CARDDAV:allprop XML Element 1700 Name: allprop 1702 Namespace: urn:ietf:params:xml:ns:carddav 1704 Purpose: Specifies that all properties shall be returned. 1706 Description: This element can be used when the client wants all 1707 properties of components returned by a report. 1709 Definition: 1711 1713 NOTE: The CARDDAV:allprop element defined here has the same name as 1714 the DAV:allprop element defined in WebDAV. However, the CARDDAV: 1715 allprop element defined here uses the 1716 "urn:ietf:params:xml:ns:carddav" namespace, as opposed to the "DAV:" 1717 namespace used for the DAV:allprop element defined in WebDAV. 1719 10.4.2. CARDDAV:prop XML Element 1721 Name: prop 1723 Namespace: urn:ietf:params:xml:ns:carddav 1725 Purpose: Defines which properties to return in the response. 1727 Description: The "name" attribute specifies the name of the 1728 addressbook property to return (e.g., "NICKNAME"). The "novalue" 1729 attribute can be used by clients to request that the actual value 1730 of the property not be returned (if the "novalue" attribute is set 1731 to "yes"). In that case the server will return just the vCard 1732 property name and any vCard parameters and a trailing ":" without 1733 the subsequent value data. 1735 Definition: 1737 1739 1741 1742 1744 NOTE: The CARDDAV:prop element defined here has the same name as the 1745 DAV:prop element defined in WebDAV. However, the CARDDAV:prop 1746 element defined here uses the "urn:ietf:params:xml:ns:carddav" 1747 namespace, as opposed to the "DAV:" namespace used for the DAV:prop 1748 element defined in WebDAV. 1750 10.5. CARDDAV:filter XML Element 1752 Name: filter 1754 Namespace: urn:ietf:params:xml:ns:carddav 1756 Purpose: Determines which matching objects are returned. 1758 Description: The "filter" element specifies the search filter used 1759 to match address objects that should be returned by a report. 1761 Definition: 1763 1765 10.5.1. CARDDAV:prop-filter XML Element 1767 Name: prop-filter 1769 Namespace: urn:ietf:params:xml:ns:carddav 1771 Purpose: Limits the search to specific properties. 1773 Description: The CARDDAV:prop-filter XML element specifies a search 1774 criteria on a specific vCard property (e.g., NICKNAME). An 1775 address object is said to match a CARDDAV:prop-filter if: 1777 * A property of the type specified by the "name" attribute 1778 exists, and the CARDDAV:prop-filter is empty, or it matches the 1779 CARDDAV:text-match conditions if specified, and that any 1780 CARDDAV:param-filter child elements also match. 1782 or: 1784 * A property of the type specified by the "name" attribute does 1785 not exist, and the CARDAV:is-not-defined element is specified. 1787 Definition: 1789 1792 1793 1795 10.5.2. CARDDAV:param-filter XML Element 1797 Name: param-filter 1799 Namespace: urn:ietf:params:xml:ns:carddav 1801 Purpose: Limits the search to specific parameter values. 1803 Description: The CARDDAV:param-filter XML element specifies a search 1804 criteria on a specific vCard property parameter (e.g., TYPE) in 1805 the scope of a given CARDDAV:prop-filter. A vCard property is 1806 said to match a CARDDAV:param-filter if: 1808 * A parameter of the type specified by the "name" attribute 1809 exists, and the CARDDAV:param-filter is empty, or it matches 1810 the CARDDAV:text-match conditions if specified. 1812 or: 1814 * A parameter of the type specified by the "name" attribute does 1815 not exist, and the CARDDAV:is-not-defined element is specified. 1817 Definition: 1819 1821 1822 1824 10.5.3. CARDDAV:is-not-defined XML Element 1826 Name: is-not-defined 1828 Namespace: urn:ietf:params:xml:ns:carddav 1830 Purpose: Specifies that a match should occur if the enclosing 1831 property or parameter does not exist. 1833 Description: The CARDDAV:is-not-defined XML element specifies that a 1834 match occurs if the enclosing property or parameter value 1835 specified in an address book REPORT request does not exist in the 1836 address data being tested. 1838 Definition: 1840 1842 10.5.4. CARDDAV:text-match XML Element 1844 Name: text-match 1846 Namespace: urn:ietf:params:xml:ns:carddav 1848 Purpose: Specifies a substring match on a property or parameter 1849 value. 1851 Description: The CARDDAV:text-match XML element specifies text used 1852 for a substring match against the property or parameter value 1853 specified in an address book REPORT request. 1855 The "collation" attribute is used to select the collation that the 1856 server MUST use for character string matching. In the absence of 1857 this attribute the server MUST use the "i;unicode-casemap" 1858 collation. 1860 The "negate-condition" attribute is used to indicate that this 1861 test returns a match if the text matches, when the attribute value 1862 is set to "no", or return a match if the text does not match, if 1863 the attribute value is set to "yes". For example, this can be 1864 used to match components with a CATEGORIES property not set to 1865 PERSON. 1867 The "match-type" attribute is used to indicate the type of match 1868 operation to use. Possible choices are: 1870 "equals" - an exact match to the target string 1872 "contains" - a substring match, matching anywhere within the 1873 target string 1875 "starts-with" - a substring match, matching only at the start 1876 of the target string 1878 "ends-with" - a substring match, matching only at the end of 1879 the target string 1881 Definition: 1883 1884 1886 1891 10.6. CARDDAV:addressbook-multiget XML Element 1893 Name: addressbook-multiget 1895 Namespace: urn:ietf:params:xml:ns:carddav 1897 Purpose: CardDAV report used to retrieve specific address objects 1898 via their URIs. 1900 Description: See Section 8.7. 1902 Definition: 1904 1909 11. Internationalization Considerations 1911 CardDAV allows internationalized strings to be stored and retrieved 1912 for the description of address book collections (see Section 6.2.1). 1914 The CARDDAV:addressbook-query report (Section 8.6) includes a text 1915 searching option controlled by the CARDDAV:text-match element and 1916 details of character handling are covered in the description of that 1917 element (see Section 10.5.4). 1919 12. Security Considerations 1921 HTTP protocol transactions are sent in the clear over the network 1922 unless protection from snooping is negotiated. This can be 1923 accomplished by use of TLS as defined in [RFC2818]. In particular, 1924 if HTTP Basic authentication is available, the server MUST allow TLS 1925 to be used at the same time, and SHOULD prevent use of Basic 1926 authentication when TLS is not in use. 1928 With the ACL extension present, WebDAV allows control over who can 1929 access (read or write) any resource on the WebDAV server. In 1930 addition, WebDAV ACL provides for an "inheritance" mechanism, whereby 1931 resources may inherit access privileges from other resources. Often 1932 the "other" resource is a parent collection of the resource itself. 1933 Clients MUST take care to ensure users are aware of which address 1934 books may be "private" (i.e. only accessible to them) and which are 1935 "shared" (i.e. accessible to others). 1937 Since webservers are often the target of automated indexing 1938 applications that gather data from the server, analyze it and extract 1939 'interesting' parts, great care must be taken when allowing 1940 unauthenticated access to any address book or address object data. 1941 Clients MAY choose to warn users when they create address data in a 1942 public address book, copy or move address data into public address 1943 books, or change access privileges in such a way as to expose address 1944 data to unauthenticated users. 1946 This specification currently relies on standard HTTP authentication 1947 mechanisms for identifying users. These comprise Basic and Digest 1948 authentication as well as SSL using client-side certificates. 1950 13. IANA Consideration 1952 In addition to the namespaces defined by RFC4918 [RFC4918] for XML 1953 elements, this document uses a URN to describe a new XML namespace 1954 conforming to a registry mechanism described in RFC3688 [RFC3688]. 1955 All other IANA considerations mentioned in RFC4918 [RFC4918] also 1956 apply to this document. 1958 13.1. Namespace Registration 1960 Registration request for the carddav namespace: 1962 URI: urn:ietf:params:xml:ns:carddav 1964 Registrant Contact: See the "Author's Address" section of this 1965 document. 1967 XML: None. Namespace URIs do not represent an XML specification. 1969 14. Acknowledgments 1971 Thanks go to Lisa Dusseault and Bernard Desruisseaux for their work 1972 on CalDAV, on which CardDAV is heavily based. The following 1973 individuals contributed their ideas and support for writing this 1974 specification: Stefan Eissing, Arnaud Quillaud, Julian Reschke, Elias 1975 Sinderson, Greg Stein, Wilfredo Sanchez Vega. 1977 15. References 1978 15.1. Normative References 1980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1981 Requirement Levels", BCP 14, RFC 2119, March 1997. 1983 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1984 RFC 2246, January 1999. 1986 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 1987 RFC 2426, September 1998. 1989 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1990 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1991 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1993 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1995 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 1996 Whitehead, "Versioning Extensions to WebDAV 1997 (Web Distributed Authoring and Versioning)", RFC 3253, 1998 March 2002. 2000 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2001 January 2004. 2003 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 2004 Distributed Authoring and Versioning (WebDAV) 2005 Access Control Protocol", RFC 3744, May 2004. 2007 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 2008 Application Protocol Collation Registry", RFC 4790, 2009 March 2007. 2011 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 2012 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 2014 [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation 2015 Algorithm", RFC 5051, October 2007. 2017 [W3C.REC-xml-20060816] 2018 Bray, T., Paoli, J., Sperberg-McQueen, C., Yergeau, F., 2019 and E. Maler, "Extensible Markup Language (XML) 1.0 2020 (Fourth Edition)", World Wide Web Consortium 2021 Recommendation REC-xml-20060816, August 2006, 2022 . 2024 [draft-daboo-webdav-mkcol-00] 2025 Daboo, C., "Extended MKCOL for WebDAV", November 2007. 2027 15.2. Informative References 2029 [IMSP] Myers, J., "IMSP - Internet Message Support Protocol", 2030 June 1995. 2032 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 2033 Configuration Access Protocol", RFC 2244, November 1997. 2035 [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 2036 Access Protocol (v3)", RFC 2251, December 1997. 2038 Appendix A. Change History (to be removed prior to publication as an 2039 RFC) 2041 Changes from -03 2043 1. Renamed addressbook-data to address-data for consistency. 2045 2. Fixed address-data element definition. 2047 Changes from -02 2049 1. Replaced MKADDRESSBOOK with extended MKCOL. 2051 2. Now require i;uncide-casemap as a supproted collation and make it 2052 the default. 2054 3. No longer require i;octet as a supproted collation. 2056 4. Allow different types of match operations via the "match-type" 2057 attribute on the "text-match" element. 2059 5. Updated to 4918 reference and removed some text/sections 2060 duplicating 4918. 2062 6. WebDAV Level 3 now required. 2064 7. TLS requirement text tweaked to match latest text approved by 2065 IESG. 2067 8. Added principal-address proeprty to principal resources to allow 2068 a vcard to be associated with a principal. 2070 9. XML definition clean-up. 2072 Changes from -01 2073 1. Added commentary on SyncML. 2075 2. Changed 'adbk' to 'addressbook'. 2077 3. Support for MKADDRESSBOOK is now a SHOULD. 2079 4. Updated to RFC4790 reference. 2081 5. Removed synchronization report. 2083 6. Removed BNF conventions section as we have no BNF. 2085 7. Reworded and reformatted several items to match the final CalDAV 2086 spec. 2088 8. Added section on use of nonstandard proeprties and parameters 2089 (as per CalDAV). 2091 9. Added section of behavior of ETags (as per CalDAV). 2093 10. Generalized the text so that vCard need not be the only format 2094 supported by the server (i.e., allow xml version of vCard etc). 2096 11. Renamed supported-addressbook-data to supported-address-data. 2098 12. Renamed valid-addressbook-data tp valid-address-data. 2100 13. Now requires "i;unicasemao" collation. 2102 Changes from -00 2104 1. Fixed various incorrect references and typos. 2106 2. Major changes to sync with latest CalDAV spec behaviors. 2108 Author's Address 2110 Cyrus Daboo 2111 Apple Inc. 2112 1 Infinite Loop 2113 Cupertino, CA 95014 2114 USA 2116 Email: cyrus@daboo.name 2117 URI: http://www.apple.com/ 2119 Full Copyright Statement 2121 Copyright (C) The IETF Trust (2008). 2123 This document is subject to the rights, licenses and restrictions 2124 contained in BCP 78, and except as set forth therein, the authors 2125 retain all their rights. 2127 This document and the information contained herein are provided on an 2128 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2129 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2130 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2131 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2132 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2133 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2135 Intellectual Property 2137 The IETF takes no position regarding the validity or scope of any 2138 Intellectual Property Rights or other rights that might be claimed to 2139 pertain to the implementation or use of the technology described in 2140 this document or the extent to which any license under such rights 2141 might or might not be available; nor does it represent that it has 2142 made any independent effort to identify any such rights. Information 2143 on the procedures with respect to rights in RFC documents can be 2144 found in BCP 78 and BCP 79. 2146 Copies of IPR disclosures made to the IETF Secretariat and any 2147 assurances of licenses to be made available, or the result of an 2148 attempt made to obtain a general license or permission for the use of 2149 such proprietary rights by implementers or users of this 2150 specification can be obtained from the IETF on-line IPR repository at 2151 http://www.ietf.org/ipr. 2153 The IETF invites any interested party to bring to its attention any 2154 copyrights, patents or patent applications, or other proprietary 2155 rights that may cover technology that may be required to implement 2156 this standard. Please address the information to the IETF at 2157 ietf-ipr@ietf.org. 2159 Acknowledgment 2161 Funding for the RFC Editor function is provided by the IETF 2162 Administrative Support Activity (IASA).