7Internet Engineering Task Force (IETF) D. Cauchie
8Request for Comments: 6715 France Telecom - Orange
9Category: Standards Track B. Leiba
15 vCard Format Extensions: Representing vCard Extensions Defined by the
16 Open Mobile Alliance (OMA) Converged Address Book (CAB) Group
20 This document defines extensions to the vCard data format for
21 representing and exchanging certain contact information. The
22 properties covered here have been defined by the Open Mobile Alliance
23 (OMA) Converged Address Book group, in order to synchronize, using
24 OMA Data Synchronization, contact fields that were not already
25 defined in the base vCard 4.0 specification.
29 This is an Internet Standards Track document.
31 This document is a product of the Internet Engineering Task Force
32 (IETF). It represents the consensus of the IETF community. It has
33 received public review and has been approved for publication by the
34 Internet Engineering Steering Group (IESG). Further information on
35 Internet Standards is available in Section 2 of RFC 5741.
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 http://www.rfc-editor.org/info/rfc6715.
43 Copyright (c) 2012 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
58Cauchie, et al. Standards Track [Page 1]
60RFC 6715 vCard-OMA-CAB August 2012
65 1. Introduction ....................................................2
66 1.1. A Brief Introduction to the Converged Address Book .........2
67 1.2. Terminology Used in This Document ..........................3
68 2. vCard Extensions: Properties ....................................3
69 2.1. Property: EXPERTISE ........................................3
70 2.2. Property: HOBBY ............................................4
71 2.3. Property: INTEREST .........................................5
72 2.4. Property: ORG-DIRECTORY ....................................6
73 3. vCard Extensions: Parameters ....................................7
74 3.1. Parameter: INDEX ...........................................7
75 3.2. Parameter: LEVEL ...........................................8
76 4. Security Considerations .........................................8
77 5. IANA Considerations .............................................9
78 6. Acknowledgments .................................................9
79 7. References .....................................................10
80 7.1. Normative References ......................................10
81 7.2. Informative References ....................................10
85 Synchronization of an Open Mobile Alliance Converged Address Book
86 [OMA-CAB], using Open Mobile Alliance Data Synchronization [OMA-DS],
87 commonly uses vCard as an exchange format between the DS Server and
88 the DS Client. In order to properly perform synchronization of an
89 OMA-CAB, the CAB specification defines some CAB contact fields not
90 already defined in the vCard base specification. This document
91 reuses the definitions found in the OMA-CAB specification and
92 describes them as vCard extensions. The following sections define
93 the necessary Properties and Parameters.
951.1. A Brief Introduction to the Converged Address Book
97 The Converged Address Book (CAB) Enabler provides consistent
98 mechanisms to manage contact information both in user-facing
99 applications and in support of network-facing activities. At the
100 core of this enabler is a network-based contact repository in which a
101 user can store contact information. That information can be
102 retrieved by any CAB-enabled device. The network-based repository is
103 also able to provide specific contact information to other users and
104 to keep their copies up to date whenever the information is changed.
106 The CAB Enabler provides synchronization of the contact information
107 available in the user device(s) with the network-based contact
114Cauchie, et al. Standards Track [Page 2]
116RFC 6715 vCard-OMA-CAB August 2012
119 The CAB Enabler also manages the distribution of a user's own contact
120 information. In essence, a user fills out a Personal Contact Card,
121 which includes all the information a user wishes to store about
124 Because systems that are supporting the CAB Enabler are likely
125 supporting multiple users, the CAB Enabler also defines a search
126 paradigm that permits other users to query those systems to locate
127 information about the available users.
129 The CAB Enabler supports many different types of information. It
130 therefore has a data model that is flexible and extensible. It
131 manages traditional types of contact information (such as name,
132 address, email, phone number, mobile number) as well as new types of
133 information (such as websites, blogs, presence subscription
1361.2. Terminology Used in This Document
138 Syntax specifications shown here use the augmented Backus-Naur Form
139 (ABNF) as described in [RFC5234] and are specified as in the base
140 vCard specification [RFC6350].
1422. vCard Extensions: Properties
144 The following sections define the CAB Properties.
147 Some string-value vCard properties are defined herein for which no
148 specific list of allowed strings is specified. For those properties,
149 it is intended that de facto taxonomies might develop. One vCard
150 can, for example, specify a hobby of "philately", while another uses
151 "stamp collecting", and a third has "old postage stamps". Usage, not
152 specification, may lead to a preference over time for a single term.
153 In general, these are meant to be understood by humans, rather than
154 to be used for automated categorization that might require standard
155 terms and registries.
1572.1. Property: EXPERTISE
161 Property name: EXPERTISE
163 Purpose: To specify a field of expertise for the object to which the
166 Value type: A single text value.
170Cauchie, et al. Standards Track [Page 3]
172RFC 6715 vCard-OMA-CAB August 2012
177 Property parameters: LEVEL (possible values: "beginner", "average",
180 Description: This is intended to be a free-form naming of fields of
181 expertise, meant for human consumption, and no specific
182 expertise fields are defined. See the note at the
183 beginning of Section 2.
187 EXPERTISE-param = LEVEL-param / INDEX-param / language-param /
188 pref-param / altid-param / type-param /
191 EXPERTISE-value = text
195 EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature
197 EXPERTISE;INDEX=1;LEVEL=expert:chemistry
205 Purpose: To specify the hobbies of the object to which the vCard
208 Value type: A single text value.
212 Property parameters: LEVEL (possible values: "high", "medium",
215 Description: This is intended to be a free-form naming of hobbies,
216 meant for human consumption, and no specific hobbies
217 are defined. See the note at the beginning of
226Cauchie, et al. Standards Track [Page 4]
228RFC 6715 vCard-OMA-CAB August 2012
231 A hobby, as opposed to an interest (see Section 2.3),
232 is an activity that one actively engages in for
233 entertainment, intellectual stimulation, creative
234 expression, or the like.
236 * "Art" might be a hobby if one actively sculpts or paints.
238 * "Tennis" might be a hobby if one enjoys playing, rather than
239 just watching, matches.
243 HOBBY-param = LEVEL-param / INDEX-param / language-param /
244 pref-param / altid-param / type-param / any-param
250 HOBBY;INDEX=1;LEVEL=high:reading
252 HOBBY;INDEX=2;LEVEL=high:sewing
2542.3. Property: INTEREST
258 Property name: INTEREST
260 Purpose: To specify the interest(s) of the object to which the vCard
263 Value type: A single text value
267 Property parameters: LEVEL (possible values: "high", "medium",
270 Description: This is intended to be a free-form naming of interests,
271 meant for human consumption, and no specific interests
272 are defined. See the note at the beginning of
275 An interest, as opposed to a hobby (see Section 2.2),
276 is an activity or topic that one finds interesting but
277 doesn't necessarily actively engage in.
282Cauchie, et al. Standards Track [Page 5]
284RFC 6715 vCard-OMA-CAB August 2012
287 * "Art" might be an interest if one likes looking at art but
290 * "Tennis" might be an interest if one enjoys watching matches
295 INTEREST-param = LEVEL-param / INDEX-param / language-param /
296 pref-param / altid-param / type-param /
299 INTEREST-value = text
303 INTEREST;INDEX=1;LEVEL=medium:r&b music
305 INTEREST;INDEX=2;LEVEL=high:rock 'n' roll music
3072.4. Property: ORG-DIRECTORY
311 Property name: ORG-DIRECTORY
313 Purpose: To specify a directory of an organization to which the
314 vCard's entity belongs.
316 Value type: A single URI value.
320 Property parameters: PREF, INDEX
322 Description: This is intended to be a URI that can be used to do an
323 organization-directory lookup. Presumably, the entity
324 the vCard represents would be found in the directory,
325 though that isn't required. This might be used to make
326 it easier to find someone's coworkers, management
327 chain, and so on, in a company or organizational
330 How the lookup is done depends upon the URI scheme, and
331 no attempt is made here to specify details of the
332 lookup mechanism. An HTTP URI might, for example, lead
338Cauchie, et al. Standards Track [Page 6]
340RFC 6715 vCard-OMA-CAB August 2012
343 to a web form that's intended for manual lookup in a
344 browser; thus, this URI might or might not be usable
345 for automated lookup or searching.
349 ORG-DIRECTORY-param = pref-param / INDEX-param / language-param
350 / pid-param / pref-param / altid-param /
351 type-param / any-param
353 ORG-DIRECTORY-value= uri
357 ORG-DIRECTORY;INDEX=1:http://directory.mycompany.example.com
359 ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/
360 o=Example%20Tech,ou=Engineering
3623. vCard Extensions: Parameters
364 The following sections define Parameters used within Properties
371 Parameter name: INDEX
373 Purpose: Used in a multi-valued property to indicate the position of
374 this value within the set of values.
376 Description: When a property is multi-valued, INDEX can be used to
377 indicate an ordering or sequence of the values. INDEX
378 values must be strictly positive. Zero is not allowed.
382 INDEX-param = "INDEX=" INDEX-value
384 INDEX-value = integer
388 ORG-URI;INDEX=1:http://mycompany.example1.com
390 ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com
394Cauchie, et al. Standards Track [Page 7]
396RFC 6715 vCard-OMA-CAB August 2012
403 Parameter name: LEVEL
405 Purpose: Used to indicate a level of expertise, hobby, or interest
406 attained by the object the vCard represents.
408 Description: Allowable values:
410 * "beginner", "average", "expert" when used with EXPERTISE
412 * "high", "medium", "low" when used with HOBBY or INTEREST
416 LEVEL-param = "LEVEL=" LEVEL-value
418 LEVEL-value = "beginner" / "average" / "expert" / "high" /
423 EXPERTISE;LEVEL=beginner:chinese literature
425 HOBBY;LEVEL=high:reading
427 INTEREST;LEVEL=medium:r&b music
4294. Security Considerations
431 This document presents no security considerations beyond those in
432 Section 9 of the base vCard specification [RFC6350].
450Cauchie, et al. Standards Track [Page 8]
452RFC 6715 vCard-OMA-CAB August 2012
4555. IANA Considerations
457 IANA has added the following entries to the "vCard Properties"
458 registry, defined in [RFC6350] Section 10.3.1.
460 +-------+------------------------+------------------------+
462 | space | Property | Reference |
463 +-------+------------------------+------------------------+
464 | | EXPERTISE | RFC 6715, Section 2.1 |
465 | | HOBBY | RFC 6715, Section 2.2 |
466 | | INTEREST | RFC 6715, Section 2.3 |
467 | | ORG-URI | RFC 6715, Section 2.4 |
468 +-------+------------------------+------------------------+
470 IANA has added the following entries to the "vCard Parameters"
471 registry, defined in [RFC6350] Section 10.3.2.
473 +-------+------------------------+------------------------+
475 | space | Parameter | Reference |
476 +-------+------------------------+------------------------+
477 | | INDEX | RFC 6715, Section 3.1 |
478 | | LEVEL | RFC 6715, Section 3.2 |
479 +-------+------------------------+------------------------+
481 IANA has added the following entries to the "vCard Parameter Values"
482 registry, defined in [RFC6350] Section 10.3.4.
484 +-----------+-----------+---------------+------------------------+
485 | Property | Parameter | Value | Reference |
486 +-----------+-----------+---------------+------------------------+
487 | EXPERTISE | LEVEL | beginner | RFC 6715, Section 3.2 |
488 | EXPERTISE | LEVEL | average | RFC 6715, Section 3.2 |
489 | EXPERTISE | LEVEL | expert | RFC 6715, Section 3.2 |
490 | HOBBY | LEVEL | high | RFC 6715, Section 3.2 |
491 | HOBBY | LEVEL | medium | RFC 6715, Section 3.2 |
492 | HOBBY | LEVEL | low | RFC 6715, Section 3.2 |
493 | INTEREST | LEVEL | high | RFC 6715, Section 3.2 |
494 | INTEREST | LEVEL | medium | RFC 6715, Section 3.2 |
495 | INTEREST | LEVEL | low | RFC 6715, Section 3.2 |
496 +-----------+---------------------------+------------------------+
500 Thanks to Simon Perreault, Peter Saint-Andre, Cyrus Daboo, and Chris
501 Newman for particularly thorough reviews, which led to a much cleaner
502 submission to the working group.
506Cauchie, et al. Standards Track [Page 9]
508RFC 6715 vCard-OMA-CAB August 2012
5137.1. Normative References
515 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
516 Syntax Specifications: ABNF", STD 68, RFC 5234,
519 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
5227.2. Informative References
524 [OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB)
525 Specification", October 2010, <http://
526 www.openmobilealliance.org/Technical/release_program/docs/
527 CopyrightClick.aspx?pck=CAB&file=V1_0-20101019-C/
528 OMA-TS-CAB-V1_0-20101019-C.pdf>.
530 Candidate Version 1.0, OMA-TS-CAB-V1_0-20101019-C
532 [OMA-DS] Open Mobile Alliance, "DS Protocol", March 2009, <http://
533 www.openmobilealliance.org/Technical/release_program/docs/
534 copyrightclick.aspx?pck=DS&file=V1_2_2-20090319-A/
535 OMA-TS-DS_Protocol-V1_2_2-20090319-A.pdf>.
562Cauchie, et al. Standards Track [Page 10]
564RFC 6715 vCard-OMA-CAB August 2012
570 France Telecom - Orange
571 2 Avenue Pierre Marzin
575 Phone: +33 2 96 05 31 16
576 EMail: dany.cauchie@orange.com
582 Phone: +1 646 827 0648
583 EMail: barryleiba@computer.org
584 URI: http://internetmessagingtechnology.org/
590 Phone: +86 755 28974289
591 EMail: likepeng@huawei.com
618Cauchie, et al. Standards Track [Page 11]