idnits 2.17.1 draft-ietf-vcarddav-oma-cab-extensions-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 324: '... MUST be strictly positive. Zer...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2012) is 4302 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 vcarddav D. Cauchie 3 Internet-Draft France Telecom - Orange 4 Intended status: Standards Track B. Leiba 5 Expires: December 20, 2012 K. Li 6 Huawei Technologies 7 June 18, 2012 9 vCard Format extension : represent vCard extensions defined by the Open 10 Mobile Alliance (OMA) Converged Address Book (CAB) group 11 draft-ietf-vcarddav-oma-cab-extensions-03 13 Abstract 15 This document defines extensions to the vCard data format for 16 representing and exchanging certain contact information. The 17 properties covered here have been defined by the Open Mobile Alliance 18 Converged Address Book group, in order to synchronize, using OMA Data 19 Synchronization, contact fields that were not already defined in the 20 base vCard 4.0 specification. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 20, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. A Brief Introduction to the Converged Address Book . . . . . 3 58 1.2. Terminology Used in This Document . . . . . . . . . . . . . 3 60 2. vCard Extensions : Properties . . . . . . . . . . . . . . . 4 61 2.1. Property : EXPERTISE . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Property : HOBBY . . . . . . . . . . . . . . . . . . . . . . 5 63 2.3. Property : INTEREST . . . . . . . . . . . . . . . . . . . . 6 64 2.4. Property : ORG-DIRECTORY . . . . . . . . . . . . . . . . . . 7 66 3. vCard extensions : Parameters . . . . . . . . . . . . . . . 8 67 3.1. Parameter : INDEX . . . . . . . . . . . . . . . . . . . . . 8 68 3.2. Parameter : LEVEL . . . . . . . . . . . . . . . . . . . . . 9 70 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Synchronization of an Open Mobile Alliance Converged Address Book 85 [OMA-CAB], using Open Mobile Alliance Data Synchronization [OMA-DS], 86 commonly uses vCard as an exchange format between the DS Server and 87 the DS Client. In order to properly perform synchronization of an 88 OMA-CAB, the CAB specification defines some CAB contact fields not 89 already defined in the vCard base specification. This document re- 90 uses the definitions found in the OMA-CAB specification and describes 91 them as vCard extensions. The following sections define the 92 necessary Properties and Parameters. 94 1.1. A Brief Introduction to the Converged Address Book 96 The Converged Address Book (CAB) Enabler provides consistent 97 mechanisms to manage contact information both in user-facing 98 applications and in support of network-facing activities. At the 99 core of this enabler is a network-based contact repository in which a 100 user can store contact information. That information can be 101 retrieved by any CAB-enabled device. The network-based repository is 102 also able to provide specific contact information to other users and 103 to keep their copies up to date whenever the information is changed. 105 The CAB Enabler provides synchronization of the contact information 106 available in the user device(s) with the network-based contact 107 repository. 109 The CAB Enabler also manages the distribution of a user's own contact 110 information. In essence, a user fills out a Personal Contact Card, 111 which includes all the information a user wishes to store about him 112 or herself. 114 Because systems that are supporting the CAB Enabler are likely 115 supporting multiple users, the CAB Enabler also defines a search 116 paradigm that permits other users to query those systems to locate 117 information about the available users. 119 The CAB Enabler supports many different types of information. It, 120 therefore, has a data model that is flexible and extensible. It 121 manages traditional types of contact information (such as name, 122 address, email, phone number, mobile number) as well as new types of 123 information (such as websites, blogs, presence subscription 124 references). 126 1.2. Terminology Used in This Document 128 Syntax specifications shown here use the augmented Backus-Naur Form 129 (ABNF) as described in [RFC5234], and are specified as in the base 130 vcard specification [RFC6350]. 132 2. vCard Extensions : Properties 134 The following sections define the CAB Properties. 136 Note: 137 Some string-value vCard properties are defined herein for which no 138 specific list of allowed strings is specified. For those properties, 139 it is intended that de-facto taxonomies might develop. One vCard 140 can, for example, specify a hobby of "philately", while another uses 141 "stamp collecting", and a third has "old postage stamps". Usage, not 142 specification, may lead to a preference over time for a single term. 143 In general, these are meant to be understood by humans, rather than 144 to be used for automated categorization that might require standard 145 terms and registries. 147 2.1. Property : EXPERTISE 149 Namespace: 151 Property name: EXPERTISE 153 Purpose: To specify a field of expertise for the object that the 154 vCard refers to. 156 Value type: A single text value. 158 Cardinality: * 160 Property parameters: LEVEL (possible values : "beginner", "average", 161 "expert"), INDEX 163 Description: This is intended to be a free-form naming of fields of 164 expertise, meant for human consumption, and no specific expertise 165 fields are defined. See the note at the beginning of Section 2. 167 Format definition: 169 EXPERTISE-param = LEVEL-param / INDEX-param / language-param / 170 pref-param / altid-param / type-param / any-param 172 EXPERTISE-value = text 174 Examples: 176 EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature 178 EXPERTISE;INDEX=1;LEVEL=expert:chemistry 180 2.2. Property : HOBBY 182 Namespace: 184 Property name: HOBBY 186 Purpose: To specify the hobbies of the object that the vCard refers 187 to. 189 Value type: A single text value. 191 Cardinality: * 193 Property parameters: LEVEL (possible values : "high", "medium", 194 "low"), INDEX 196 Description: This is intended to be a free-form naming of hobbies, 197 meant for human consumption, and no specific hobbies are defined. 198 See the note at the beginning of Section 2. 200 A hobby, as opposed to an interest (see Section 2.3) is an 201 activity that one actively engages in for entertainment, 202 intellectual stimulation, creative expression, or the like. 204 * "Art" might be a hobby if one actively sculpts or paints. 206 * "Tennis" might be a hobby if one enjoys playing, rather than 207 just watching matches. 209 Format definition: 211 HOBBY-param = LEVEL-param / INDEX-param / language-param / pref- 212 param / altid-param / type-param / any-param 214 HOBBY-value = text 216 Examples: 218 HOBBY;INDEX=1;LEVEL=high:reading 220 HOBBY;INDEX=2;LEVEL=high:sewing 222 2.3. Property : INTEREST 224 Namespace: 226 Property name: INTEREST 228 Purpose: To specify the interest(s) of the object that the vCard 229 refers to. 231 Value type: A single text value 233 Cardinality: * 235 Property parameters: LEVEL (possible values : "high", "medium", 236 "low"), INDEX 238 Description: This is intended to be a free-form naming of interests, 239 meant for human consumption, and no specific interests are 240 defined. See the note at the beginning of Section 2. 242 An interest, as opposed to a hobby (see Section 2.2) is an 243 activity or topic that one finds interesting, but doesn't 244 necessarily actively engage in. 246 * "Art" might be an interest if one likes looking at art, but 247 doesn't create art. 249 * "Tennis" might be an interest if one enjoys watching matches, 250 but doesn't play. 252 Format definition: 254 INTEREST-param = LEVEL-param / INDEX-param / language-param / 255 pref-param / altid-param / type-param / any-param 257 INTEREST-value = text 259 Examples: 261 INTEREST;INDEX=1;LEVEL=medium:r&b music 263 INTEREST;INDEX=2;LEVEL=high:rock'n roll music 265 2.4. Property : ORG-DIRECTORY 267 Namespace: 269 Property name: ORG-DIRECTORY 271 Purpose: To specify a directory of an organization the vCard's 272 entity belongs to. 274 Value type: A single URI value. 276 Cardinality: * 278 Property parameters: PREF, INDEX 280 Description: This is intended to be a URI that can be used to do an 281 organization-directory lookup. Presumably, the entity the vCard 282 represents would be found in the directory, though that isn't 283 required. This might be used to make it easier to find someone's 284 co-workers, management chain, and so on, in a company or 285 organizational directory. 287 How the lookup is done depends upon the URI scheme, and no 288 attempt is made here to specify details of the lookup mechanism. 289 An HTTP URI might, for example, lead to a web form that's 290 intended for manual lookup in a browser -- thus, this URI might 291 or might not be useable for automated lookup or searching. 293 Format definition: 295 ORG-DIRECTORY-param = pref-param / INDEX-param / language-param 296 / pid-param / pref-param / altid-param / type-param / 297 any-param 299 ORG-DIRECTORY-value= uri 301 Examples: 303 ORG-DIRECTORY;INDEX=1:http://directory.mycompany.example.com 305 ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/ 306 o=Example%20Tech,ou=Engineering 308 3. vCard extensions : Parameters 310 The following sections define Parameters used within Properties 311 definitions. 313 3.1. Parameter : INDEX 315 Namespace: 317 Parameter name: INDEX 319 Purpose: Used in a multi-valued property to indicate the position of 320 this value within the set of values. 322 Description: When a property is multi-valued, INDEX can be used to 323 indicate an ordering or sequence of the values. INDEX values 324 MUST be strictly positive. Zero is not allowed. 326 Format definition: 328 INDEX-param = "INDEX=" INDEX-value 330 INDEX-value = integer 332 Examples: 334 ORG-URI;INDEX=1:http://mycompany.example1.com 336 ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com 338 3.2. Parameter : LEVEL 340 Namespace: 342 Parameter name: LEVEL 344 Purpose: Used to indicate a level of expertise, hobby or interest 345 attained by the object the vCard represents. 347 Description: Allowable values: 349 * "beginner", "average", "expert" when used with EXPERTISE 351 * "high", "medium", "low" when used with HOBBY or INTEREST 353 Format definition: 355 LEVEL-param = "LEVEL=" LEVEL-value 357 LEVEL-value = "beginner" / "average" / "expert" / "high" / 358 "medium" / "low" 360 Examples: 362 EXPERTISE;LEVEL=beginner:chinese literature 364 HOBBY;LEVEL=high:reading 366 INTEREST;LEVEL=medium:r&b music 368 4. Security Considerations 370 This document presents no security considerations beyond those in 371 section 9 of the base vcard specification [RFC6350]. 373 5. IANA Considerations 375 IANA is requested to add the following entries to the vCard 376 Properties registry, defined in [RFC6350] section 10.3.1. 378 +-------+---------------------------+-------------------+ 379 | Name | | | 380 | space | Property | Reference | 381 +-------+---------------------------+-------------------+ 382 | | EXPERTISE | RFCXXXX, sec 2.1 | 383 | | HOBBY | RFCXXXX, sec 2.2 | 384 | | INTEREST | RFCXXXX, sec 2.3 | 385 | | ORG-URI | RFCXXXX, sec 2.4 | 386 +-------+---------------------------+-------------------+ 388 IANA is requested to add the following entries to the vCard 389 Parameters registry, defined in [RFC6350] section 10.3.2. 391 +-------+---------------------------+-------------------+ 392 | Name | | | 393 | space | Parameter | Reference | 394 +-------+---------------------------+-------------------+ 395 | | INDEX | RFCXXXX, sec 3.1 | 396 | | LEVEL | RFCXXXX, sec 3.2 | 397 +-------+---------------------------+-------------------+ 399 IANA is requested to add the following entries to the vCard Values 400 registry, defined in [RFC6350] section 10.3.4. 402 +-----------+-----------+---------------+-------------------+ 403 | Property | Parameter | Value | Reference | 404 +-----------+-----------+---------------+-------------------+ 405 | EXPERTISE | LEVEL | beginner | RFCXXXX, sec 3.2 | 406 | EXPERTISE | LEVEL | average | RFCXXXX, sec 3.2 | 407 | EXPERTISE | LEVEL | expert | RFCXXXX, sec 3.2 | 408 | HOBBY | LEVEL | high | RFCXXXX, sec 3.2 | 409 | HOBBY | LEVEL | medium | RFCXXXX, sec 3.2 | 410 | HOBBY | LEVEL | low | RFCXXXX, sec 3.2 | 411 | INTEREST | LEVEL | high | RFCXXXX, sec 3.2 | 412 | INTEREST | LEVEL | medium | RFCXXXX, sec 3.2 | 413 | INTEREST | LEVEL | low | RFCXXXX, sec 3.2 | 414 +-----------+---------------------------+-------------------+ 416 6. Acknowledgments 418 Thanks to Simon Perreault, Peter Saint-Andre, Cyrus Daboo, and Chris 419 Newman for particularly thorough reviews, which led to a much cleaner 420 submission to the working group. 422 7. References 424 7.1. Normative References 426 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 427 Specifications: ABNF", STD 68, RFC 5234, January 2008. 429 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 430 August 2011. 432 7.2. Informative References 434 [OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB) 435 Specification", October 2010, . 440 Candidate Version 1.0, OMA-TS-CAB-V1_0-20101019-C 442 [OMA-DS] Open Mobile Alliance, "Data Synchronization Protocol", 443 March 2009, . 448 Candidate Version 1.2.2, OMA-TS-DS_Protocol-V1_2_2- 449 20090319-A 451 Authors' Addresses 453 Dany Cauchie 454 France Telecom - Orange 455 2 Avenue Pierre Marzin 456 Lannion 22307 457 France 459 Phone: +33 2 96 05 31 16 460 Email: dany.cauchie@orange.com 461 Barry Leiba 462 Huawei Technologies 464 Phone: +1 646 827 0648 465 Email: barryleiba@computer.org 466 URI: http://internetmessagingtechnology.org/ 468 Kepeng Li 469 Huawei Technologies 471 Phone: +86 755 28974289 472 Email: likepeng@huawei.com