idnits 2.17.00 (12 Aug 2021) /tmp/idnits49841/draft-ietf-vcarddav-oma-cab-extensions-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2012) is 3731 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-CAB' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: September 3, 2012 K. Li 6 Huawei Technologies 7 March 2, 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-01 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, important contact fields that were not already 20 defined in the 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 September 3, 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 . . . . . . . . . . . . . . . . . . . . . . 10 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Synchronization of an Open Mobile Alliance Converged Address Book 83 [OMA-CAB], using Open Mobile Alliance Data Synchronization (OMA-DS), 84 commonly uses vCard as an exchange format between the DS Server and 85 the DS Client. In order to properly perform synchronization of an 86 OMA-CAB, the CAB specification defines some important CAB contact 87 fields not already defined in the vCard base specification. This 88 document re-uses the definitions found in the OMA-CAB specification 89 and describes them as vCard extensions. The following sections 90 define the necessary Properties and Parameters. 92 1.1. A Brief Introduction to the Converged Address Book 94 The Converged Address Book (CAB) Enabler provides consistent 95 mechanisms to manage contact information both in user-facing 96 applications and in support of network-facing activities. At the 97 core of this enabler is a network-based contact repository in which a 98 user can store contact information. That information can be 99 retrieved by any CAB-enabled device. The network-based repository is 100 also able to provide specific contact information to other users and 101 to keep their copies up to date whenever the information is changed. 103 The CAB Enabler provides synchronization of the contact information 104 available in the user device(s) with the network-based contact 105 repository. 107 The CAB Enabler also managed the distribution of a user's own contact 108 information. In essence, a user fills out a Personal Contact Card, 109 which includes all the information a user wishes to store about him 110 or herself. 112 Because systems that are supporting the CAB Enabler are likely 113 supporting multiple users, the CAB Enabler also defines a search 114 paradigm that permits other users to query those systems to locate 115 information about the available users. 117 The CAB Enabler supports many different types of information. It, 118 therefore, has a data model that is flexible and extensible. It 119 manages traditional types of contact information (such as name, 120 address, email, phone number, mobile number) as well as new types of 121 information (such as websites, blogs, presence subscription 122 references). 124 1.2. Terminology Used in This Document 126 Syntax specifications shown here use the augmented Backus-Naur Form 127 (ABNF) as described in [RFC5234], and are specified as in the base 128 vcard specification [RFC6350]. 130 2. vCard Extensions : Properties 132 The following sections define the CAB Properties. 134 Note: 135 Some string-value vCard properties are defined herein for which no 136 specific list of allowed strings is specified. For those properties, 137 it is intended that de-facto taxonomies might develop. One vCard 138 can, for example, specify a hobby of "philately", while another uses 139 "stamp collecting", and a third has "old postage stamps". Usage, not 140 specification, may lead to a preference over time for a single term. 141 In general, these are meant to be understood by humans, rather than 142 to be used for automated categorization that might require standard 143 terms and registries. 145 2.1. Property : EXPERTISE 147 Namespace: 149 Property name: EXPERTISE 151 Purpose: To specify a field in which the object that the vCard 152 refers to has expertise. 154 Value type: A single string value. 156 Cardinality: * 158 Property parameters: LEVEL (possible values : "beginner", "average", 159 "expert"), INDEX 161 Description: This is intended to be a free-form naming of fields of 162 expertise, meant for human consumption, and no specific expertise 163 fields are defined. See the note at the beginning of Section 2. 165 Format definition: 167 EXPERTISE-param = LEVEL-param / INDEX-param 169 EXPERTISE-value = text 171 Examples: 173 EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature 175 EXPERTISE;INDEX=1;LEVEL=expert:chemistry 177 2.2. Property : HOBBY 179 Namespace: 181 Property name: HOBBY 183 Purpose: To specify the hobbies of the object that the vCard refers 184 to. 186 Value type: A single string value. 188 Cardinality: * 190 Property parameters: LEVEL (possible values : "high", "medium", 191 "low"), INDEX 193 Description: This is intended to be a free-form naming of hobbies, 194 meant for human consumption, and no specific hobbies are defined. 195 See the note at the beginning of Section 2. 197 A hobby, as opposed to an interest (see Section 2.3) is an 198 activity that one actively engages in for entertainment, 199 intellectual stimulation, creative expression, or the like. 201 * "Art" might be a hobby if one actively sculpts or paints. 203 * "Tennis" might be a hobby if one enjoys playing, rather than 204 just watching matches. 206 Format definition: 208 HOBBY-param = LEVEL-param / INDEX-param 210 HOBBY-value = text 212 Examples: 214 HOBBY;INDEX=1;LEVEL=high:reading 216 HOBBY;INDEX=2;LEVEL=high:sewing 218 2.3. Property : INTEREST 220 Namespace: 222 Property name: INTEREST 224 Purpose: To specify the interest(s) of the object that the vCard 225 refers to. 227 Value type: A single string value 229 Cardinality: * 231 Property parameters: LEVEL (possible values : "high", "medium", 232 "low"), INDEX 234 Description: This is intended to be a free-form naming of interests, 235 meant for human consumption, and no specific interests are 236 defined. See the note at the beginning of Section 2. 238 An interest, as opposed to a hobby (see Section 2.2) is an 239 activity or topic that one finds interesting, but doesn't 240 necessarily actively engage in. 242 * "Art" might be an interest if one likes looking at art, but 243 doesn't create art. 245 * "Tennis" might be an interest if one enjoys watching matches, 246 but doesn't play. 248 Format definition: 250 INTEREST-param = LEVEL-param / INDEX-param 252 INTEREST-value = text 254 Examples: 256 INTEREST;INDEX=1;LEVEL=medium:r&b music 258 INTEREST;INDEX=2;LEVEL=high:rock'n roll music 260 2.4. Property : ORG-DIRECTORY 262 Namespace: 264 Property name: ORG-DIRECTORY 266 Purpose: To specify a directory of an organization the vCard's 267 entity belongs to. 269 Value type: A single URI value. 271 Cardinality: * 273 Property parameters: PREF, INDEX 275 Description: This is intended to be a URI that can be used to do an 276 organization-directory lookup. Presumably, the entity the vCard 277 represents would be found in the directory, though that isn't 278 required. This might be used to make it easier to find someone's 279 co-workers, management chain, and so on, in a company or 280 organizational directory. 282 How the lookup is done depends upon the URI scheme, and no 283 attempt is made here to specify details of the lookup mechanism. 285 An HTTP URI might, for example, lead to a web form that's 286 intended for manual lookup in a browser -- thus, this URI might 287 or might not be useable for automated lookup or searching. 289 Format definition: 291 ORG-DIRECTORY-param = pref-param / INDEX-param 293 ORG-DIRECTORY-value= uri 295 Examples: 297 ORG-DIRECTORY;INDEX=1:http://directory.mycompany.example.com 299 ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/ 300 o=Example%20Tech,ou=Engineering 302 3. vCard extensions : Parameters 304 The following sections define Parameters used within Properties 305 definitions. 307 3.1. Parameter : INDEX 309 Namespace: 311 Parameter name: INDEX 313 Purpose: Used in a multi-valued property to indicate the position of 314 this value within the set of values. 316 Description: When a property is multi-valued, INDEX can be used to 317 indicate an ordering or sequence of the values. 319 Format definition: 321 INDEX-param = "INDEX=" INDEX-value 322 INDEX-value = integer 324 Examples: 326 ORG-URI;INDEX=1:http://mycompany.example1.com 328 ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com 330 3.2. Parameter : LEVEL 332 Namespace: 334 Parameter name: LEVEL 336 Purpose: Used to indicate a level of expertise, hobby or interest 337 attained by the object the vCard represents. 339 Description: Possible values: 341 * "beginner", "average", "expert" when used with EXPERTISE 343 * "high", "medium", "low" when used with HOBBY or INTEREST 345 Format definition: 347 LEVEL-param = "LEVEL=" LEVEL-value 349 LEVEL-value = "beginner" / "average" / "expert" / "high" / 350 "medium" / "low" 352 Examples: 354 EXPERTISE;LEVEL=beginner:chinese literature 356 HOBBY;LEVEL=high:reading 358 INTEREST;LEVEL=medium:r&b music 360 4. Security Considerations 362 This document presents no security considerations beyond those in 363 section 9 of the base vcard specification [RFC6350]. 365 5. IANA Considerations 367 IANA is requested to add the following entries to the vCard 368 Properties registry, defined in [RFC6350] section 10.3.1. 370 +-------+---------------------------+-------------------+ 371 | Name | | | 372 | space | Property | Reference | 373 +-------+---------------------------+-------------------+ 374 | | EXPERTISE | RFCXXXX, sec 2.1 | 375 | | HOBBY | RFCXXXX, sec 2.2 | 376 | | INTEREST | RFCXXXX, sec 2.3 | 377 | | ORG-URI | RFCXXXX, sec 2.4 | 378 +-------+---------------------------+-------------------+ 380 IANA is requested to add the following entries to the vCard 381 Parameters registry, defined in [RFC6350] section 10.3.2. 383 +-------+---------------------------+-------------------+ 384 | Name | | | 385 | space | Parameter | Reference | 386 +-------+---------------------------+-------------------+ 387 | | INDEX | RFCXXXX, sec 3.1 | 388 | | LEVEL | RFCXXXX, sec 3.2 | 389 +-------+---------------------------+-------------------+ 391 6. Acknowledgments 393 Thanks to Simon Perreault, Peter Saint-Andre, and Chris Newman for 394 particularly thorough reviews, which led to a much cleaner submission 395 to the working group. 397 7. Normative References 399 [OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB) 400 Specification", October 2010, . 405 Candidate Version 1.0, OMA-TS-CAB-V1_0-20101019-C 407 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 408 Specifications: ABNF", STD 68, RFC 5234, January 2008. 410 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 411 August 2011. 413 Authors' Addresses 415 Dany Cauchie 416 France Telecom - Orange 417 2 Avenue Pierre Marzin 418 Lannion 22307 419 France 421 Phone: +33 2 96 05 31 16 422 Email: dany.cauchie@orange.com 424 Barry Leiba 425 Huawei Technologies 427 Phone: +1 646 827 0648 428 Email: barryleiba@computer.org 429 URI: http://internetmessagingtechnology.org/ 431 Kepeng Li 432 Huawei Technologies 434 Phone: +86 755 28974289 435 Email: likepeng@huawei.com