vCard OMA CAB: vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group
Four new vCard properties and two parameters, borrowed from the OMA Converged Address Book, for hobbies, interests, expertise and directories.
Cauchie, D., Leiba, B., and K. Li, "vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group", RFC 6715, DOI 10.17487/RFC6715, August 2012, <https://www.rfc-editor.org/info/rfc6715>.
@misc{rfc6715,
series = {Request for Comments},
number = 6715,
howpublished = {RFC 6715},
publisher = {RFC Editor},
doi = {10.17487/RFC6715},
url = {https://www.rfc-editor.org/info/rfc6715},
author = {D. Cauchie and B. Leiba and K. Li},
title = {{vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group}},
pagetotal = 11,
year = 2012,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Cauchie
Request for Comments: 6715 France Telecom - Orange
Category: Standards Track B. Leiba
ISSN: 2070-1721 K. Li
Huawei Technologies
August 2012
vCard Format Extensions: Representing vCard Extensions Defined by the
Open Mobile Alliance (OMA) Converged Address Book (CAB) Group
Abstract
This document defines extensions to the vCard data format for
representing and exchanging certain contact information. The
properties covered here have been defined by the Open Mobile Alliance
(OMA) Converged Address Book group, in order to synchronize, using
OMA Data Synchronization, contact fields that were not already
defined in the base vCard 4.0 specification.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6715.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
1.1. A Brief Introduction to the Converged Address Book .........2
1.2. Terminology Used in This Document ..........................3
2. vCard Extensions: Properties ....................................3
2.1. Property: EXPERTISE ........................................3
2.2. Property: HOBBY ............................................4
2.3. Property: INTEREST .........................................5
2.4. Property: ORG-DIRECTORY ....................................6
3. vCard Extensions: Parameters ....................................7
3.1. Parameter: INDEX ...........................................7
3.2. Parameter: LEVEL ...........................................8
4. Security Considerations .........................................8
5. IANA Considerations .............................................9
6. Acknowledgments .................................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. Introduction
Synchronization of an Open Mobile Alliance Converged Address Book
[OMA-CAB], using Open Mobile Alliance Data Synchronization [OMA-DS],
commonly uses vCard as an exchange format between the DS Server and
the DS Client. In order to properly perform synchronization of an
OMA-CAB, the CAB specification defines some CAB contact fields not
already defined in the vCard base specification. This document
reuses the definitions found in the OMA-CAB specification and
describes them as vCard extensions. The following sections define
the necessary Properties and Parameters.
1.1. A Brief Introduction to the Converged Address Book
The Converged Address Book (CAB) Enabler provides consistent
mechanisms to manage contact information both in user-facing
applications and in support of network-facing activities. At the
core of this enabler is a network-based contact repository in which a
user can store contact information. That information can be
retrieved by any CAB-enabled device. The network-based repository is
also able to provide specific contact information to other users and
to keep their copies up to date whenever the information is changed.
The CAB Enabler provides synchronization of the contact information
available in the user device(s) with the network-based contact
repository.
The CAB Enabler also manages the distribution of a user's own contact
information. In essence, a user fills out a Personal Contact Card,
which includes all the information a user wishes to store about
himself or herself.
Because systems that are supporting the CAB Enabler are likely
supporting multiple users, the CAB Enabler also defines a search
paradigm that permits other users to query those systems to locate
information about the available users.
The CAB Enabler supports many different types of information. It
therefore has a data model that is flexible and extensible. It
manages traditional types of contact information (such as name,
address, email, phone number, mobile number) as well as new types of
information (such as websites, blogs, presence subscription
references).
1.2. Terminology Used in This Document
Syntax specifications shown here use the augmented Backus-Naur Form
(ABNF) as described in [RFC5234] and are specified as in the base
vCard specification [RFC6350].
2. vCard Extensions: Properties
The following sections define the CAB Properties.
Note:
Some string-value vCard properties are defined herein for which no
specific list of allowed strings is specified. For those properties,
it is intended that de facto taxonomies might develop. One vCard
can, for example, specify a hobby of "philately", while another uses
"stamp collecting", and a third has "old postage stamps". Usage, not
specification, may lead to a preference over time for a single term.
In general, these are meant to be understood by humans, rather than
to be used for automated categorization that might require standard
terms and registries.
2.1. Property: EXPERTISE
Namespace:
Property name: EXPERTISE
Purpose: To specify a field of expertise for the object to which the
vCard refers.
Value type: A single text value.
Cardinality: *
Property parameters: LEVEL (possible values: "beginner", "average",
"expert"), INDEX
Description: This is intended to be a free-form naming of fields of
expertise, meant for human consumption, and no specific
expertise fields are defined. See the note at the
beginning of Section 2.
Format definition:
EXPERTISE-param = LEVEL-param / INDEX-param / language-param /
pref-param / altid-param / type-param /
any-param
EXPERTISE-value = text
Examples:
EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature
EXPERTISE;INDEX=1;LEVEL=expert:chemistry
2.2. Property: HOBBY
Namespace:
Property name: HOBBY
Purpose: To specify the hobbies of the object to which the vCard
refers.
Value type: A single text value.
Cardinality: *
Property parameters: LEVEL (possible values: "high", "medium",
"low"), INDEX
Description: This is intended to be a free-form naming of hobbies,
meant for human consumption, and no specific hobbies
are defined. See the note at the beginning of
Section 2.
A hobby, as opposed to an interest (see Section 2.3),
is an activity that one actively engages in for
entertainment, intellectual stimulation, creative
expression, or the like.
* "Art" might be a hobby if one actively sculpts or paints.
* "Tennis" might be a hobby if one enjoys playing, rather than
just watching, matches.
Format definition:
HOBBY-param = LEVEL-param / INDEX-param / language-param /
pref-param / altid-param / type-param / any-param
HOBBY-value = text
Examples:
HOBBY;INDEX=1;LEVEL=high:reading
HOBBY;INDEX=2;LEVEL=high:sewing
2.3. Property: INTEREST
Namespace:
Property name: INTEREST
Purpose: To specify the interest(s) of the object to which the vCard
refers.
Value type: A single text value
Cardinality: *
Property parameters: LEVEL (possible values: "high", "medium",
"low"), INDEX
Description: This is intended to be a free-form naming of interests,
meant for human consumption, and no specific interests
are defined. See the note at the beginning of
Section 2.
An interest, as opposed to a hobby (see Section 2.2),
is an activity or topic that one finds interesting but
doesn't necessarily actively engage in.
* "Art" might be an interest if one likes looking at art but
doesn't create art.
* "Tennis" might be an interest if one enjoys watching matches
but doesn't play.
Format definition:
INTEREST-param = LEVEL-param / INDEX-param / language-param /
pref-param / altid-param / type-param /
any-param
INTEREST-value = text
Examples:
INTEREST;INDEX=1;LEVEL=medium:r&b music
INTEREST;INDEX=2;LEVEL=high:rock 'n' roll music
2.4. Property: ORG-DIRECTORY
Namespace:
Property name: ORG-DIRECTORY
Purpose: To specify a directory of an organization to which the
vCard's entity belongs.
Value type: A single URI value.
Cardinality: *
Property parameters: PREF, INDEX
Description: This is intended to be a URI that can be used to do an
organization-directory lookup. Presumably, the entity
the vCard represents would be found in the directory,
though that isn't required. This might be used to make
it easier to find someone's coworkers, management
chain, and so on, in a company or organizational
directory.
How the lookup is done depends upon the URI scheme, and
no attempt is made here to specify details of the
lookup mechanism. An HTTP URI might, for example, lead
to a web form that's intended for manual lookup in a
browser; thus, this URI might or might not be usable
for automated lookup or searching.
Format definition:
ORG-DIRECTORY-param = pref-param / INDEX-param / language-param
/ pid-param / pref-param / altid-param /
type-param / any-param
ORG-DIRECTORY-value= uri
Examples:
ORG-DIRECTORY;INDEX=1:http://directory.mycompany.example.com
ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/
o=Example%20Tech,ou=Engineering
3. vCard Extensions: Parameters
The following sections define Parameters used within Properties
definitions.
3.1. Parameter: INDEX
Namespace:
Parameter name: INDEX
Purpose: Used in a multi-valued property to indicate the position of
this value within the set of values.
Description: When a property is multi-valued, INDEX can be used to
indicate an ordering or sequence of the values. INDEX
values must be strictly positive. Zero is not allowed.
Format definition:
INDEX-param = "INDEX=" INDEX-value
INDEX-value = integer
Examples:
ORG-URI;INDEX=1:http://mycompany.example1.com
ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com
3.2. Parameter: LEVEL
Namespace:
Parameter name: LEVEL
Purpose: Used to indicate a level of expertise, hobby, or interest
attained by the object the vCard represents.
Description: Allowable values:
* "beginner", "average", "expert" when used with EXPERTISE
* "high", "medium", "low" when used with HOBBY or INTEREST
Format definition:
LEVEL-param = "LEVEL=" LEVEL-value
LEVEL-value = "beginner" / "average" / "expert" / "high" /
"medium" / "low"
Examples:
EXPERTISE;LEVEL=beginner:chinese literature
HOBBY;LEVEL=high:reading
INTEREST;LEVEL=medium:r&b music
4. Security Considerations
This document presents no security considerations beyond those in
Section 9 of the base vCard specification [RFC6350].
5. IANA Considerations
IANA has added the following entries to the "vCard Properties"
registry, defined in [RFC6350] Section 10.3.1.
+-------+------------------------+------------------------+
| Name- | | |
| space | Property | Reference |
+-------+------------------------+------------------------+
| | EXPERTISE | RFC 6715, Section 2.1 |
| | HOBBY | RFC 6715, Section 2.2 |
| | INTEREST | RFC 6715, Section 2.3 |
| | ORG-URI | RFC 6715, Section 2.4 |
+-------+------------------------+------------------------+
IANA has added the following entries to the "vCard Parameters"
registry, defined in [RFC6350] Section 10.3.2.
+-------+------------------------+------------------------+
| Name- | | |
| space | Parameter | Reference |
+-------+------------------------+------------------------+
| | INDEX | RFC 6715, Section 3.1 |
| | LEVEL | RFC 6715, Section 3.2 |
+-------+------------------------+------------------------+
IANA has added the following entries to the "vCard Parameter Values"
registry, defined in [RFC6350] Section 10.3.4.
+-----------+-----------+---------------+------------------------+
| Property | Parameter | Value | Reference |
+-----------+-----------+---------------+------------------------+
| EXPERTISE | LEVEL | beginner | RFC 6715, Section 3.2 |
| EXPERTISE | LEVEL | average | RFC 6715, Section 3.2 |
| EXPERTISE | LEVEL | expert | RFC 6715, Section 3.2 |
| HOBBY | LEVEL | high | RFC 6715, Section 3.2 |
| HOBBY | LEVEL | medium | RFC 6715, Section 3.2 |
| HOBBY | LEVEL | low | RFC 6715, Section 3.2 |
| INTEREST | LEVEL | high | RFC 6715, Section 3.2 |
| INTEREST | LEVEL | medium | RFC 6715, Section 3.2 |
| INTEREST | LEVEL | low | RFC 6715, Section 3.2 |
+-----------+---------------------------+------------------------+
6. Acknowledgments
Thanks to Simon Perreault, Peter Saint-Andre, Cyrus Daboo, and Chris
Newman for particularly thorough reviews, which led to a much cleaner
submission to the working group.
7. References
7.1. Normative References
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011.
7.2. Informative References
[OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB)
Specification", October 2010, <http://
www.openmobilealliance.org/Technical/release_program/docs/
CopyrightClick.aspx?pck=CAB&file=V1_0-20101019-C/
OMA-TS-CAB-V1_0-20101019-C.pdf>.
Candidate Version 1.0, OMA-TS-CAB-V1_0-20101019-C
[OMA-DS] Open Mobile Alliance, "DS Protocol", March 2009, <http://
www.openmobilealliance.org/Technical/release_program/docs/
copyrightclick.aspx?pck=DS&file=V1_2_2-20090319-A/
OMA-TS-DS_Protocol-V1_2_2-20090319-A.pdf>.
Authors' Addresses
Dany Cauchie
France Telecom - Orange
2 Avenue Pierre Marzin
Lannion 22307
France
Phone: +33 2 96 05 31 16
EMail: dany.cauchie@orange.com
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Kepeng Li
Huawei Technologies
Phone: +86 755 28974289
EMail: likepeng@huawei.com
AI ELI5
On this page
§1Why These Extensions Exist
Synchronizing an Open Mobile Alliance (OMA) Converged Address Book (CAB) with OMA Data Synchronization commonly uses vCard as the exchange format between the DS Server and the DS Client. The CAB specification defines some contact fields that the base vCard specification, RFC 6350, does not have.
This document reuses the definitions from the OMA-CAB specification and describes them as vCard extensions. It defines the needed properties and parameters, and nothing more.
Phones and servers swap contact cards to stay in step. Some phone cards had boxes the standard card lacked, so this memo adds those boxes to the standard.
§1.1The Converged Address Book
The CAB Enabler manages contact information both in user-facing applications and in network-facing activities. At its core is a network-based contact repository where a user stores contacts. Any CAB-enabled device can retrieve them, and the repository can give specific contact information to other users and keep their copies up to date.
It also synchronizes the contacts on the user's devices with the repository, manages the distribution of a user's own information through a Personal Contact Card, and defines a search paradigm so other users can look up people on the system. Its data model is flexible and extensible, covering traditional data such as name, address, email and phone number as well as newer types such as websites, blogs and presence subscription references.
Think of one big shared address book in the cloud that all your devices copy from. This memo only covers a few extra fields that book uses.
§2The Four New Properties
Four properties are added. Each can appear any number of times and is defined with ABNF, as in RFC 6350.
- EXPERTISE names a field of expertise. Its
LEVELcan bebeginner,averageorexpert. - HOBBY names an activity one actively engages in for entertainment, intellectual stimulation, creative expression, or the like. Its
LEVELcan behigh,mediumorlow. - INTEREST names an activity or topic one finds interesting but does not necessarily engage in. It uses the same three
LEVELvalues as HOBBY. - ORG-DIRECTORY holds a single URI that can be used for an organization-directory lookup, such as finding coworkers or a management chain.
The first three take a single text value. The RFC's examples of the hobby and interest split: "Art" is a hobby if one sculpts or paints, and an interest if one only likes looking at art. "Tennis" is a hobby for someone who plays and an interest for someone who watches.
There are boxes for what you are good at, what you do for fun, what you just like, and a link to your company's phone book.
§2.5Free-Form Text and Directory Lookups
EXPERTISE, HOBBY and INTEREST are intended as free-form naming, meant for human consumption. No specific lists of allowed strings are defined. The RFC expects that de facto taxonomies might develop: one vCard may say "philately", another "stamp collecting" and a third "old postage stamps". Usage, not specification, may favor one term over time. These values are not meant for automated categorization that would need standard terms and registries.
ORG-DIRECTORY works differently because its value is a URI. How the lookup is done depends on the URI scheme, and the RFC does not specify the lookup mechanism. An HTTP URI might lead to a web form meant for manual use in a browser, so it might not be usable for automated searching. The entity the vCard describes would presumably be found in the directory, but that is not required.
You can write anything you like in the hobby box, like "stamp collecting" or "old postage stamps". People will probably settle on favorite words over time.
§3The INDEX and LEVEL Parameters
INDEX is used in a multi-valued property to show the position of a value within the set. It takes an integer, and values must be strictly positive: zero is not allowed. The properties above all accept it.
LEVEL shows the level of expertise, hobby or interest attained. The allowed values depend on the property: beginner, average or expert with EXPERTISE, and high, medium or low with HOBBY or INTEREST.
The property definitions also allow the usual vCard parameters, such as language, pref, altid and type.
INDEX says which one is first, second or third on your list. LEVEL says how good you are, or how much you like it.
- EXPERTISEbeginner / average / expert — LEVEL values allowed with EXPERTISE.
- HOBBYhigh / medium / low — LEVEL values allowed with HOBBY.
- INTERESThigh / medium / low — LEVEL values allowed with INTEREST.
§3.1What the Lines Look Like
The RFC gives examples in vCard line syntax. A person who is an expert in chemistry and a beginner in Chinese literature, with two hobbies and two directory links, could have lines like these:
EXPERTISE;INDEX=1;LEVEL=expert:chemistryHOBBY;INDEX=1;LEVEL=high:readingINTEREST;INDEX=1;LEVEL=medium:r&b musicORG-DIRECTORY;INDEX=1:http://directory.mycompany.example.com
A directory can also be an LDAP URI, as in ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/o=Example%20Tech,ou=Engineering.
Each fact goes on its own line, like "hobby, number one, a lot: reading".
§4Security Considerations
RFC 6715 presents no security considerations beyond those in Section 9 of the base vCard specification, RFC 6350.
These new boxes add no new safety worries beyond the ones the normal contact card already has.
§5IANA Registrations
IANA added entries to three registries defined in RFC 6350: the vCard Properties registry, the vCard Parameters registry and the vCard Parameter Values registry. The property entries cover EXPERTISE, HOBBY and INTEREST, the parameter entries cover INDEX and LEVEL, and the parameter-value entries list each allowed LEVEL value for the property it applies to.
One oddity: the property table in the IANA section names the fourth property ORG-URI and points to Section 2.4, while Section 2.4 itself defines ORG-DIRECTORY. The INDEX examples in Section 3.1 also use ORG-URI. The RFC text does not explain the difference.
The official list of allowed card fields was updated to include the new ones. The list uses a slightly different name for the directory field than the rest of the memo does.