summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6715.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6715.txt')
-rw-r--r--doc/rfc/rfc6715.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6715.txt b/doc/rfc/rfc6715.txt
new file mode 100644
index 0000000..d2e2abf
--- /dev/null
+++ b/doc/rfc/rfc6715.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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]
+