doc: Add RFC documents

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