idnits 2.17.00 (12 Aug 2021) /tmp/idnits49520/draft-ietf-vcarddav-oma-cab-extensions-02.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 322: '... 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 (May 11, 2012) is 3661 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-DS' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: November 12, 2012 K. Li 6 Huawei Technologies 7 May 11, 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-02 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 November 12, 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. Normative References . . . . . . . . . . . . . . . . . . . . 11 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 CAB contact fields not 87 already defined in the vCard base specification. This document re- 88 uses the definitions found in the OMA-CAB specification and describes 89 them as vCard extensions. The following sections define the 90 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 manages 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 of expertise for the object that the 152 vCard refers to. 154 Value type: A single text 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 / language-param / 168 pref-param / altid-param / type-param / any-param 170 EXPERTISE-value = text 172 Examples: 174 EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature 176 EXPERTISE;INDEX=1;LEVEL=expert:chemistry 178 2.2. Property : HOBBY 180 Namespace: 182 Property name: HOBBY 184 Purpose: To specify the hobbies of the object that the vCard refers 185 to. 187 Value type: A single text value. 189 Cardinality: * 191 Property parameters: LEVEL (possible values : "high", "medium", 192 "low"), INDEX 194 Description: This is intended to be a free-form naming of hobbies, 195 meant for human consumption, and no specific hobbies are defined. 196 See the note at the beginning of Section 2. 198 A hobby, as opposed to an interest (see Section 2.3) is an 199 activity that one actively engages in for entertainment, 200 intellectual stimulation, creative expression, or the like. 202 * "Art" might be a hobby if one actively sculpts or paints. 204 * "Tennis" might be a hobby if one enjoys playing, rather than 205 just watching matches. 207 Format definition: 209 HOBBY-param = LEVEL-param / INDEX-param / language-param / pref- 210 param / altid-param / type-param / any-param 212 HOBBY-value = text 214 Examples: 216 HOBBY;INDEX=1;LEVEL=high:reading 218 HOBBY;INDEX=2;LEVEL=high:sewing 220 2.3. Property : INTEREST 222 Namespace: 224 Property name: INTEREST 226 Purpose: To specify the interest(s) of the object that the vCard 227 refers to. 229 Value type: A single text value 231 Cardinality: * 233 Property parameters: LEVEL (possible values : "high", "medium", 234 "low"), INDEX 236 Description: This is intended to be a free-form naming of interests, 237 meant for human consumption, and no specific interests are 238 defined. See the note at the beginning of Section 2. 240 An interest, as opposed to a hobby (see Section 2.2) is an 241 activity or topic that one finds interesting, but doesn't 242 necessarily actively engage in. 244 * "Art" might be an interest if one likes looking at art, but 245 doesn't create art. 247 * "Tennis" might be an interest if one enjoys watching matches, 248 but doesn't play. 250 Format definition: 252 INTEREST-param = LEVEL-param / INDEX-param / language-param / 253 pref-param / altid-param / type-param / any-param 255 INTEREST-value = text 257 Examples: 259 INTEREST;INDEX=1;LEVEL=medium:r&b music 261 INTEREST;INDEX=2;LEVEL=high:rock'n roll music 263 2.4. Property : ORG-DIRECTORY 265 Namespace: 267 Property name: ORG-DIRECTORY 269 Purpose: To specify a directory of an organization the vCard's 270 entity belongs to. 272 Value type: A single URI value. 274 Cardinality: * 276 Property parameters: PREF, INDEX 278 Description: This is intended to be a URI that can be used to do an 279 organization-directory lookup. Presumably, the entity the vCard 280 represents would be found in the directory, though that isn't 281 required. This might be used to make it easier to find someone's 282 co-workers, management chain, and so on, in a company or 283 organizational directory. 285 How the lookup is done depends upon the URI scheme, and no 286 attempt is made here to specify details of the lookup mechanism. 287 An HTTP URI might, for example, lead to a web form that's 288 intended for manual lookup in a browser -- thus, this URI might 289 or might not be useable for automated lookup or searching. 291 Format definition: 293 ORG-DIRECTORY-param = pref-param / INDEX-param / language-param 294 / pid-param / pref-param / altid-param / type-param / 295 any-param 297 ORG-DIRECTORY-value= uri 299 Examples: 301 ORG-DIRECTORY;INDEX=1:http://directory.mycompany.example.com 303 ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/ 304 o=Example%20Tech,ou=Engineering 306 3. vCard extensions : Parameters 308 The following sections define Parameters used within Properties 309 definitions. 311 3.1. Parameter : INDEX 313 Namespace: 315 Parameter name: INDEX 317 Purpose: Used in a multi-valued property to indicate the position of 318 this value within the set of values. 320 Description: When a property is multi-valued, INDEX can be used to 321 indicate an ordering or sequence of the values. INDEX values 322 MUST be strictly positive. Zero is not allowed. 324 Format definition: 326 INDEX-param = "INDEX=" INDEX-value 328 INDEX-value = integer 330 Examples: 332 ORG-URI;INDEX=1:http://mycompany.example1.com 334 ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com 336 3.2. Parameter : LEVEL 338 Namespace: 340 Parameter name: LEVEL 342 Purpose: Used to indicate a level of expertise, hobby or interest 343 attained by the object the vCard represents. 345 Description: Allowable values: 347 * "beginner", "average", "expert" when used with EXPERTISE 349 * "high", "medium", "low" when used with HOBBY or INTEREST 351 Format definition: 353 LEVEL-param = "LEVEL=" LEVEL-value 355 LEVEL-value = "beginner" / "average" / "expert" / "high" / 356 "medium" / "low" 358 Examples: 360 EXPERTISE;LEVEL=beginner:chinese literature 362 HOBBY;LEVEL=high:reading 364 INTEREST;LEVEL=medium:r&b music 366 4. Security Considerations 368 This document presents no security considerations beyond those in 369 section 9 of the base vcard specification [RFC6350]. 371 5. IANA Considerations 373 IANA is requested to add the following entries to the vCard 374 Properties registry, defined in [RFC6350] section 10.3.1. 376 +-------+---------------------------+-------------------+ 377 | Name | | | 378 | space | Property | Reference | 379 +-------+---------------------------+-------------------+ 380 | | EXPERTISE | RFCXXXX, sec 2.1 | 381 | | HOBBY | RFCXXXX, sec 2.2 | 382 | | INTEREST | RFCXXXX, sec 2.3 | 383 | | ORG-URI | RFCXXXX, sec 2.4 | 384 +-------+---------------------------+-------------------+ 386 IANA is requested to add the following entries to the vCard 387 Parameters registry, defined in [RFC6350] section 10.3.2. 389 +-------+---------------------------+-------------------+ 390 | Name | | | 391 | space | Parameter | Reference | 392 +-------+---------------------------+-------------------+ 393 | | INDEX | RFCXXXX, sec 3.1 | 394 | | LEVEL | RFCXXXX, sec 3.2 | 395 +-------+---------------------------+-------------------+ 397 IANA is requested to add the following entries to the vCard Values 398 registry, defined in [RFC6350] section 10.3.4. 400 +-----------+-----------+---------------+-------------------+ 401 | Property | Parameter | Value | Reference | 402 +-----------+-----------+---------------+-------------------+ 403 | EXPERTISE | LEVEL | beginner | RFCXXXX, sec 3.2 | 404 | EXPERTISE | LEVEL | average | RFCXXXX, sec 3.2 | 405 | EXPERTISE | LEVEL | expert | RFCXXXX, sec 3.2 | 406 | HOBBY | LEVEL | high | RFCXXXX, sec 3.2 | 407 | HOBBY | LEVEL | medium | RFCXXXX, sec 3.2 | 408 | HOBBY | LEVEL | low | RFCXXXX, sec 3.2 | 409 | INTEREST | LEVEL | high | RFCXXXX, sec 3.2 | 410 | INTEREST | LEVEL | medium | RFCXXXX, sec 3.2 | 411 | INTEREST | LEVEL | low | RFCXXXX, sec 3.2 | 412 +-----------+---------------------------+-------------------+ 414 6. Acknowledgments 416 Thanks to Simon Perreault, Peter Saint-Andre, Cyrus Daboo, and Chris 417 Newman for particularly thorough reviews, which led to a much cleaner 418 submission to the working group. 420 7. Normative References 422 [OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB) 423 Specification", October 2010, . 428 Candidate Version 1.0, OMA-TS-CAB-V1_0-20101019-C 430 [OMA-DS] Open Mobile Alliance, "Data Synchronization Protocol", 431 March 2009, . 436 Candidate Version 1.2.2, OMA-TS-DS_Protocol-V1_2_2- 437 20090319-A 439 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 440 Specifications: ABNF", STD 68, RFC 5234, January 2008. 442 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 443 August 2011. 445 Authors' Addresses 447 Dany Cauchie 448 France Telecom - Orange 449 2 Avenue Pierre Marzin 450 Lannion 22307 451 France 453 Phone: +33 2 96 05 31 16 454 Email: dany.cauchie@orange.com 455 Barry Leiba 456 Huawei Technologies 458 Phone: +1 646 827 0648 459 Email: barryleiba@computer.org 460 URI: http://internetmessagingtechnology.org/ 462 Kepeng Li 463 Huawei Technologies 465 Phone: +86 755 28974289 466 Email: likepeng@huawei.com