idnits 2.17.00 (12 Aug 2021) /tmp/idnits50244/draft-ietf-vcarddav-oma-cab-extensions-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 20, 2011) is 3865 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 (~~), 2 warnings (==), 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: April 22, 2012 K. Li 6 Huawei Technologies 7 October 20, 2011 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-00 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 April 22, 2012. 39 Copyright Notice 41 Copyright (c) 2011 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. Terminology Used in This Document . . . . . . . . . . . . . 3 59 2. vCard Extensions : Properties . . . . . . . . . . . . . . . 3 60 2.1. Property : CONTACT-LANGUAGE . . . . . . . . . . . . . . . . 3 61 2.2. Property : SERVICE . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Property : EXPERTISE . . . . . . . . . . . . . . . . . . . . 6 63 2.4. Property : HOBBY . . . . . . . . . . . . . . . . . . . . . . 7 64 2.5. Property : INTEREST . . . . . . . . . . . . . . . . . . . . 8 65 2.6. Property : PUBLICNOTE . . . . . . . . . . . . . . . . . . . 9 66 2.7. Property : ORG-DIRECTORY . . . . . . . . . . . . . . . . . . 10 68 3. vCard extensions : Parameters . . . . . . . . . . . . . . . 12 69 3.1. Parameter : INDEX . . . . . . . . . . . . . . . . . . . . . 12 70 3.2. Parameter : LANGUAGE-PROFICIENCY-TYPE . . . . . . . . . . . 12 71 3.3. Parameter : LANGUAGE-FLUENCY-TYPE . . . . . . . . . . . . . 13 72 3.4. Parameter : LEVEL . . . . . . . . . . . . . . . . . . . . . 14 74 4. Security Considerations . . . . . . . . . . . . . . . . . . 14 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 80 7. Normative References . . . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 [[anchor1: Barry: There are still quite a few review comments that 87 are not incorporated into this version. I have included those 88 comments in the appropriate places with the XML "cref" element, so 89 they will show up within "[[ ]]", as this one does. I am still 90 working on these, but please feel free to help me resolve these 91 comments as we go through the document again.]] 93 Synchronization of an Open Mobile Alliance Converged Address Book 94 [OMA-CAB], using Open Mobile Alliance Data Synchronization (OMA-DS), 95 commonly uses vCard as an exchange format between the DS Server and 96 the DS Client. In order to properly perform synchronization of an 97 OMA-CAB, the CAB specification defines some important CAB contact 98 fields not already defined in the vCard base specification. This 99 document re-uses the definitions found in the OMA-CAB specification 100 and describes them as vCard extensions. The following sections 101 define the necessary Properties and Parameters. 103 1.1. Terminology Used in This Document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 Syntax specifications shown here use the augmented Backus-Naur Form 110 (ABNF) as described in [RFC5234], and are specified as in the base 111 vcard specification [RFC6350]. 113 2. vCard Extensions : Properties 115 The following sections define the CAB Properties. 117 [[anchor3: Simon: As I start reading section 2.1, I'm still wondering 118 what OMA-CAB does and where I can go for more information. So maybe 119 a few more introduction sentences with a reference would be 120 helpful.]] 122 [[anchor4: Alexey: I would like to see at least statements about 123 whether various properties have corresponding registries of allowed 124 values, how unrecognized values should be treated (if allowed), 125 etc.]] 127 2.1. Property : CONTACT-LANGUAGE 128 Namespace: 130 Property name: CONTACT-LANGUAGE 132 Purpose: To specify the language(s) that may be used for contacting 133 the individual associated with the vCard. 135 Value type: A single language-tag value. 137 Cardinality: * 139 Property parameters: PREF, INDEX, LANGUAGE-PROFICIENCY-TYPE, 140 LANGUAGE-FLUENCY-TYPE 142 Description: 144 [[anchor6: Simon: What's the difference between CONTACT-LANGUAGE 145 and LANG? If it's only for supporting the new parameters, why 146 not simply add the new parameters to the LANG property?]] 148 [[anchor7: Peter StA: I like CONTACT-LANGUAGE and I'm wondering 149 why we didn't define that already in the base vCard4 spec.]] 151 [[anchor8: Chris: The CONTACT-LANGUAGE property seems useful, but 152 I don't see how to specify that I can read and speak a language 153 but not write the language. [Alexey: Or to speak, but not read a 154 language.]]] 156 [[anchor9: Dany: We decided to use LANG instead of CONTACT- 157 LANGUAGE.]] 159 Format definition: 161 CONTACT-LANGUAGE-param = pref-param / LANGUAGE-PROFICIENCY-TYPE- 162 param / LANGUAGE-FLUENCY-TYPE-param / INDEX-param 164 CONTACT-LANGUAGE-value = language-tag 166 Example: 168 CONTACT-LANGUAGE;INDEX=1; 169 LANGUAGE-PROFICIENCY-TYPE=speak; 170 LANGUAGE-FLUENCY-TYPE=fluent:en 172 2.2. Property : SERVICE 174 Namespace: 176 Property name: SERVICE 178 Purpose: To specify the aliases used on different sites by the 179 object that the vCard refers to. 181 Value type: A single structured value consisting of 3 values 182 separated by the SEMI-COLON character (U+0059) : 184 1. label : indicating a free-text description of the service 186 2. alias : indicating the alias identifier string used for a 187 service 189 3. url : indicating the URL pointing to the service resource 191 Cardinality: * 193 Property parameters: INDEX 195 Description: 197 [[anchor11: Peter StA: SERVICE seems somewhat underspecified; in 198 particular the "label" is just a free-form name for the service, 199 but it seems that different people might call the same service by 200 different names, leading to confusion (e.g., "facebook" vs. 201 "FaceBook", "Google" vs. "Gmail" vs. "Google Talk").]] 203 [[anchor12: Chris: The SERVICE property seems vague, I prefer the 204 SOCIALPROFILE name in draft-george-vcarddav-vcard-extension, 205 although having a way to distinguish the unique identifier used 206 by that social service seems useful.]] 208 [[anchor13: Cyrus: WRT SERVICE I would like to draw people's 209 attention to 210 http://tools.ietf.org/html/draft-daboo-vcard-service-type (which 211 is now expired). This takes a different approach of defining a 212 SERVICE-TYPE parameter for use on existing properties such as 213 EMAIL and IM. This allow those communications properties to be 214 "tagged" with the service provider identifier.]] 216 [[anchor14: Cyrus: I wonder whether instead of SERVICE we should 217 be using the existing vCard URL property combined with SERVICE- 218 TYPE. The existing property already states "social networking 219 site identifiers" as one possible use case. I realize this might 220 make it a little bit harder to do a simple one-to-one mapping 221 with OMA attributes, but I do think we should try and re-use 222 existing vCard properties where ever it makes sense.]] 224 Format definition: 226 SERVICE-param = INDEX-param 228 SERVICE-value = text 230 Example: 232 SERVICE;INDEX=1:facebook;Facili Tie; 233 http://fr-fr.facebook.com/people/Facili-Tie/100001298828793 235 2.3. Property : EXPERTISE 237 Namespace: 239 Property name: EXPERTISE 241 Purpose: To specify the expertise(s) of the object that the vCard 242 refers to. 244 Value type: A single string value. 246 Cardinality: * 248 Property parameters: LEVEL (possible values : "beginner", "average", 249 "expert"), INDEX 251 Description: 253 Format definition: 255 EXPERTISE-param = LEVEL-param / INDEX-param 257 EXPERTISE-value = text 259 Examples: 261 EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature 263 EXPERTISE;INDEX=1;LEVEL=expert:chemistry 265 2.4. Property : HOBBY 267 Namespace: 269 Property name: HOBBY 271 Purpose: To specify the hobbies of the object that the vCard refers 272 to. 274 Value type: A single string value. 276 Cardinality: * 278 Property parameters: LEVEL (possible values : "high", "medium", 279 "low"), INDEX 281 Description: A hobby, as opposed to an interest (see Section 2.5) is 282 an activity that one actively engages in for entertainment, 283 intellectual stimulation, creative expression, or the like. 285 * "Art" might be a hobby if one actively sculpts or paints. 287 * "Tennis" might be a hobby if one enjoys playing, rather than 288 just watching matches. 290 Format definition: 292 HOBBY-param = LEVEL-param / INDEX-param 294 HOBBY-value = text 296 Examples: 298 HOBBY;INDEX=1;LEVEL=high:reading 300 HOBBY;INDEX=2;LEVEL=high:sewing 302 2.5. Property : INTEREST 304 Namespace: 306 Property name: INTEREST 308 Purpose: To specify the interest(s) of the object that the vCard 309 refers to. 311 Value type: A single string value 313 Cardinality: * 315 Property parameters: LEVEL (possible values : "high", "medium", 316 "low"), INDEX 318 Description: An interest, as opposed to a hobby (see Section 2.4) is 319 an activity or topic that one finds interesting, but doesn't 320 necessarily actively engage in. 322 * "Art" might be an interest if one likes looking at art, but 323 doesn't create art. 325 * "Tennis" might be an interest if one enjoys watching matches, 326 but doesn't play. 328 Format definition: 330 INTEREST-param = LEVEL-param / INDEX-param 332 INTEREST-value = text 334 Examples: 336 INTEREST;INDEX=1;LEVEL=medium:r&b music 338 INTEREST;INDEX=2;LEVEL=high:rock'n roll music 340 2.6. Property : PUBLICNOTE 342 Namespace: 344 Property name: PUBLICNOTE 346 Purpose: To specify additional information associated with the 347 object the vCard refers to. 349 Value type: A single string value 351 Cardinality: * 353 Property parameters: 355 Description: 357 [[anchor17: Peter StA: How is PUBLICNOTE different from NOTE in 358 the base spec? The example ("Out of my office today") seems more 359 like presence than vCard.]] 361 [[anchor18: Chris: I don't understand PUBLICNOTE or how it might 362 be used or presented in a UI. The example looks like it's going 363 to be used as a presence status or something like that. Seems 364 too vague to be useful.]] 366 [[anchor19: Dany: Yes, it looks like information stored by a 367 presence server but it is not because CAB doesn't deal with 368 presence information. NOTE could be used to stored somthing like 369 "This is my personal card" and PUBLICNOTE could be used to store 370 something like "I would like to reach tennis players in New- 371 York". So, my suggestion is to change the example with something 372 which represents a more permanent information. Examples could 373 be, "I live in Beijing", "Waiting for a job", "I spoke to Barack 374 OBAMA", "Motorbike fanatic". Hence, to me, NOTE is a permanent 375 information (like "this is ALICE's personal card"), PUBLICNOTE is 376 a semi-permanent information (like "Waiting for a job"), and 377 presence is a temporary information (like "out of my office 378 today").]] 380 [[anchor20: Barry: I think the decision was to use PUBLICNOTE, 381 but make the description clearer. I will take a stab at that.]] 383 Format definition: 385 PUBLICNOTE-param = language-param 387 PUBLICNOTE-value = text 389 Example: 391 PUBLICNOTE;LANGUAGE=en:Out of my office today 393 2.7. Property : ORG-DIRECTORY 395 Namespace: 397 Property name: ORG-DIRECTORY 399 Purpose: To specify the organization-directory of the object the 400 vCard represents. 402 Value type: A single URI value. 404 Cardinality: * 406 Property parameters: PREF, INDEX 408 Description: 410 [[anchor22: Chris: ORG-DIRECTORY is interesting, but I'd like an 411 example with an LDAP URL.]] 413 [[anchor23: Alexey: Additionally: does use of a particular URI 414 scheme implies a particular data format? HTTP URIs (for example) 415 don't provide enough information about format of the resource by 416 themselves.]] 418 [[anchor24: Dany: Need better description of what ORG-DIRECTORY 419 means and eventually mapping with SOURCE.]] 421 Format definition: 423 ORG-DIRECTORY-param = pref-param / INDEX-param 425 ORG-DIRECTORY-value= uri 427 Examples: 429 ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com 431 ORG-DIRECTORY;PREF=1;INDEX=2:http://mycompany.example2.com 433 3. vCard extensions : Parameters 435 The following sections define Parameters used within Properties 436 definitions. 438 3.1. Parameter : INDEX 440 Namespace: 442 Parameter name: INDEX 444 Purpose: Used in a multi-valued property to indicate the position of 445 this value within the set of values. 447 Description: 449 [[anchor27: Simon: I don't understand the difference between 450 INDEX and PID.]] 452 Format definition: 454 INDEX-param = "INDEX=" INDEX-value 456 INDEX-value = integer 458 Examples: 460 ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com 462 ORG-DIRECTORY;PREF=1;INDEX=2:http://mycompany.example2.com 464 3.2. Parameter : LANGUAGE-PROFICIENCY-TYPE 466 Namespace: 468 Parameter name: LANGUAGE-PROFICIENCY-TYPE 469 Purpose: Used to indicate which degree of proficiency the object the 470 vCard represents attained in the corresponding language. 472 Description: Possible values are "read only", "speak", "read/write". 474 Format definition: 476 LANGUAGE-PROFICIENCY-TYPE-param = "LANGUAGE-PROFICIENCY-TYPE=" 477 LANGUAGE-PROFICIENCY-TYPE-value 479 LANGUAGE-PROFICIENCY-TYPE-value = "read only" / "speak" / "read/ 480 write" 482 Example: 484 CONTACT-LANGUAGE;LANGUAGE-PROFICIENCY-TYPE=speak:en 486 3.3. Parameter : LANGUAGE-FLUENCY-TYPE 488 Namespace: 490 Parameter name: LANGUAGE-FLUENCY-TYPE 492 Purpose: Used to indicate which degree of fluency the object the 493 vCard represents attained in the corresponding language. 495 Description: Possible values are "beginner", "average", "fluent". 497 Format definition: 499 LANGUAGE-FLUENCY-TYPE-param = "LANGUAGE-FLUENCY-TYPE=" LANGUAGE- 500 FLUENCY-TYPE-value 502 LANGUAGE-FLUENCY-TYPE-value = "beginner" / "average" / "fluent" 504 Example: 506 CONTACT-LANGUAGE;LANGUAGE-FLUENCY-TYPE=fluent:en 508 3.4. Parameter : LEVEL 510 Namespace: 512 Parameter name: LEVEL 514 Purpose: Used to indicate a level of expertise, hobby or interest 515 attained by the object the vCard represents. 517 Description: Possible values: 519 * "beginner", "average", "expert" when used with EXPERTISE 521 * "high", "medium", "low" when used with HOBBY or INTEREST 523 Format definition: 525 LEVEL-param = "LEVEL=" LEVEL-value 527 LEVEL-value = "beginner" / "average" / "expert" / "high" / 528 "medium" / "low" 530 Examples: 532 EXPERTISE;LEVEL=beginner:chinese literature 534 HOBBY;LEVEL=high:reading 536 INTEREST;LEVEL=medium:r&b music 538 4. Security Considerations 540 This presents no security considerations beyond those in section 9 of 541 the base vcard specification [RFC6350]. 543 [[anchor31: Chris: Some of these may have security and/or privacy 544 considerations -- the PUBLICNOTE is sensitive. The SERVICE or 545 SOCIALPROFILE enables automated "friend invite" spam.]] 547 5. IANA Considerations 549 IANA is requested to add the following entries to the vCard 550 Properties registry, defined in [RFC6350] section 10.3.1. 552 +-------+---------------------------+-------------------+ 553 | Name | | | 554 | space | Property | Reference | 555 +-------+---------------------------+-------------------+ 556 | | CONTACT-LANGUAGE | RFCXXXX, sec 2.1 | 557 | | SERVICE | RFCXXXX, sec 2.2 | 558 | | EXPERTISE | RFCXXXX, sec 2.3 | 559 | | HOBBY | RFCXXXX, sec 2.4 | 560 | | INTEREST | RFCXXXX, sec 2.5 | 561 | | PUBLICNOTE | RFCXXXX, sec 2.6 | 562 | | ORG-DIRECTORY | RFCXXXX, sec 2.7 | 563 +-------+---------------------------+-------------------+ 565 IANA is requested to add the following entries to the vCard 566 Parameters registry, defined in [RFC6350] section 10.3.2. 568 +-------+---------------------------+-------------------+ 569 | Name | | | 570 | space | Parameter | Reference | 571 +-------+---------------------------+-------------------+ 572 | | INDEX | RFCXXXX, sec 3.1 | 573 | | LANGUAGE-PROFICIENCY-TYPE | RFCXXXX, sec 3.2 | 574 | | LANGUAGE-FLUENCY-TYPE | RFCXXXX, sec 3.3 | 575 | | LEVEL | RFCXXXX, sec 3.4 | 576 +-------+---------------------------+-------------------+ 578 6. Acknowledgments 580 Thanks to Simon Perrault, Peter St. Andre, and Chris Newman for 581 particularly thorough reviews, which led to a much cleaner submission 582 to the working group. 584 7. Normative References 586 [OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB) 587 Specification", October 2010, . 592 Candidate Version 1.0, OMA-TS-CAB-V1_0-20101019-C 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 598 Specifications: ABNF", STD 68, RFC 5234, January 2008. 600 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 601 August 2011. 603 Authors' Addresses 605 Dany Cauchie 606 France Telecom - Orange 607 2 Avenue Pierre Marzin 608 Lannion 22307 609 France 611 Phone: +33 2 96 05 31 16 612 Email: dany.cauchie@orange-ftgroup.com 614 Barry Leiba 615 Huawei Technologies 617 Phone: +1 646 827 0648 618 Email: barryleiba@computer.org 619 URI: http://internetmessagingtechnology.org/ 621 Kepeng Li 622 Huawei Technologies 624 Phone: +86 755 28974289 625 Email: likepeng@huawei.com