This is a purely informative rendering of an RFC that includes verified errata. This rendering may not be used as a reference.

The following 'Verified' errata have been incorporated in this document: EID 3340, EID 3341, EID 3342
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.

If an instance of a multi-valued property does not have an INDEX value, then it is included at the end of the ordered sequence, as if it had a very high INDEX value. 
EID 3342 (Verified) is as follows:

Section: 3.1

Original Text:

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.

Corrected Text:

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.

If an instance of a multi-valued property does not have an INDEX value, then it is included at the end of the ordered sequence, as if it had a very high INDEX value. 
Notes:
It is not clear how a list of properties should be sorted if some of them have INDEX parameters and others do not.  This errata submission proposes that properties without an INDEX parameter be pushed to the end of the sorted list, as if they had a very high INDEX value.

For example, the ordering of the following properties is very clear, since they all have INDEX parameters:

INTEREST;INDEX=3:art
INTEREST;INDEX=2:baseball
INTEREST;INDEX=4:music
INTEREST;INDEX=1:hockey

The above example would be sorted as follows:

INTEREST;INDEX=1:hockey
INTEREST;INDEX=2:baseball
INTEREST;INDEX=3:art
INTEREST;INDEX=4:music

However, the spec does not provide guidance on how to sort a list of properties if some properties have INDEX parameters and others do not.  This errata submission suggests that the properties missing the INDEX parameter be pushed to the end of the sorted list.  For example:

Unsorted:

INTEREST:art
INTEREST;INDEX=2:baseball
INTEREST:music
INTEREST;INDEX=1:hockey

Sorted:

INTEREST;INDEX=1:hockey
INTEREST;INDEX=2:baseball
INTEREST:art
INTEREST:music

...OR...

INTEREST;INDEX=1:hockey
INTEREST;INDEX=2:baseball
INTEREST:music
INTEREST:art

Verifier note:
Something like this was meant to be in the document, but was left out.
Format definition: INDEX-param = "INDEX=" INDEX-value INDEX-value = integer Examples: ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com ORG-DIRECTORY;PREF=1;INDEX=2:http://mycompany.example2.com
EID 3340 (Verified) is as follows:

Section: 3.1

Original Text:

Examples:
ORG-URI;INDEX=1:http://mycompany.example1.com
ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com

Corrected Text:

Examples:
ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com
ORG-DIRECTORY;PREF=1;INDEX=2:http://mycompany.example2.com
Notes:
In the examples, the ORG-DIRECTORY property is incorrectly referred to as ORG-URI.
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-DIRECTORY | RFC 6715, Section 2.4 | +-------+------------------------+------------------------+
EID 3341 (Verified) is as follows:

Section: 5

Original Text:

     +-------+------------------------+------------------------+
     | 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  |
     +-------+------------------------+------------------------+

Corrected Text:

     +-------+------------------------+------------------------+
     | Name- |                        |                        |
     | space | Property               | Reference              |
     +-------+------------------------+------------------------+
     |       | EXPERTISE              | RFC 6715, Section 2.1  |
     |       | HOBBY                  | RFC 6715, Section 2.2  |
     |       | INTEREST               | RFC 6715, Section 2.3  |
     |       | ORG-DIRECTORY          | RFC 6715, Section 2.4  |
     +-------+------------------------+------------------------+
Notes:
The ORG-DIRECTORY property is incorrectly referred to as ORG-URI.
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