GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6715

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.

Cauchie, et al. Standards Track [Page 1] RFC 6715 vCard-OMA-CAB August 2012

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.

Cauchie, et al. Standards Track [Page 2] RFC 6715 vCard-OMA-CAB August 2012

 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.

Cauchie, et al. Standards Track [Page 3] RFC 6715 vCard-OMA-CAB August 2012

 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.

Cauchie, et al. Standards Track [Page 4] RFC 6715 vCard-OMA-CAB August 2012

               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.

Cauchie, et al. Standards Track [Page 5] RFC 6715 vCard-OMA-CAB August 2012

  • "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

Cauchie, et al. Standards Track [Page 6] RFC 6715 vCard-OMA-CAB August 2012

               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

Cauchie, et al. Standards Track [Page 7] RFC 6715 vCard-OMA-CAB August 2012

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].

Cauchie, et al. Standards Track [Page 8] RFC 6715 vCard-OMA-CAB August 2012

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.

Cauchie, et al. Standards Track [Page 9] RFC 6715 vCard-OMA-CAB August 2012

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

Cauchie, et al. Standards Track [Page 10] RFC 6715 vCard-OMA-CAB August 2012

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

Cauchie, et al. Standards Track [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6715.txt · Last modified: 2012/08/30 00:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki