vcarddav                                                      D. Cauchie
Internet-Draft                                   France Telecom - Orange
Intended status: Standards Track                                B. Leiba
Expires: April 22, September 3, 2012                                         K. Li
                                                     Huawei Technologies
                                                        October 20, 2011
                                                           March 2, 2012

vCard Format extension : represent vCard extensions defined by the Open
        Mobile Alliance (OMA) Converged Address Book (CAB) group
               draft-ietf-vcarddav-oma-cab-extensions-00
               draft-ietf-vcarddav-oma-cab-extensions-01

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
   Converged Address Book group, in order to synchronize, using OMA Data
   Synchronization, important contact fields that were not already
   defined in the base vCard 4.0 specification.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 22, September 3, 2012.

Copyright Notice

   Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  A Brief Introduction to the Converged Address Book . . . . .  3
   1.2.  Terminology Used in This Document  . . . . . . . . . . . . .  3

   2.    vCard Extensions : Properties  . . . . . . . . . . . . . . .  3  4
   2.1.  Property : CONTACT-LANGUAGE  . . . . . . . . . . . . . . . .  3
   2.2.  Property : SERVICE . . . . . . . . . . . . . . . . . . . . .  5
   2.3.  Property : EXPERTISE . . . . . . . . . . . . . . . . . . . .  6
   2.4.  4
   2.2.  Property : HOBBY . . . . . . . . . . . . . . . . . . . . . .  7
   2.5.  5
   2.3.  Property : INTEREST  . . . . . . . . . . . . . . . . . . . .  8
   2.6.  Property : PUBLICNOTE  . . . . . . . . . . . . . . . . . . .  9
   2.7.  6
   2.4.  Property : ORG-DIRECTORY . . . . . . . . . . . . . . . . . . 10  7

   3.    vCard extensions : Parameters  . . . . . . . . . . . . . . . 12  8
   3.1.  Parameter : INDEX  . . . . . . . . . . . . . . . . . . . . . 12  8
   3.2.  Parameter : LANGUAGE-PROFICIENCY-TYPE  . . . . . . . . . . . 12
   3.3.  Parameter : LANGUAGE-FLUENCY-TYPE  . . . . . . . . . . . . . 13
   3.4.  Parameter : LEVEL  . . . . . . . . . . . . . . . . . . . . . 14  9

   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 14 10

   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15 10

   6.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 15 10

   7.    Normative References . . . . . . . . . . . . . . . . . . . . 15 10

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 11

1.  Introduction

   [[anchor1: Barry: There are still quite a few review comments that
   are not incorporated into this version.  I have included those
   comments in the appropriate places with the XML "cref" element, so
   they will show up within "[[ ]]", as this one does.  I am still
   working on these, but please feel free to help me resolve these
   comments as we go through the document again.]]

   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 important CAB contact
   fields not already defined in the vCard base specification.  This
   document re-uses 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.  Terminology Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are  A Brief Introduction to be interpreted as described in [RFC2119].

   Syntax specifications shown here use the augmented Backus-Naur Form
   (ABNF) as described Converged Address Book

   The Converged Address Book (CAB) Enabler provides consistent
   mechanisms to manage contact information both in [RFC5234], user-facing
   applications and are specified as in support of network-facing activities.  At the base
   vcard specification [RFC6350].

2.  vCard Extensions : Properties

   The following sections define the CAB Properties.

   [[anchor3: Simon: As I start reading section 2.1, I'm still wondering
   what OMA-CAB does and where I can go for more information.  So maybe
   core of this enabler is a few more introduction sentences with network-based contact repository in which a reference would
   user can store contact information.  That information can be
   helpful.]]

   [[anchor4: Alexey: I would like
   retrieved by any CAB-enabled device.  The network-based repository is
   also able to see at least statements about
   whether various properties have corresponding registries of allowed
   values, how unrecognized values should be treated (if allowed),
   etc.]]

2.1.  Property : CONTACT-LANGUAGE
   Namespace:

   Property name:  CONTACT-LANGUAGE

   Purpose:  To specify the language(s) that may be used for contacting
       the individual associated with the vCard.

   Value type:  A single language-tag value.

   Cardinality:  *

   Property parameters:  PREF, INDEX, LANGUAGE-PROFICIENCY-TYPE,
       LANGUAGE-FLUENCY-TYPE

   Description:

       [[anchor6: Simon: What's the difference between CONTACT-LANGUAGE
       and LANG?  If it's only for supporting the new parameters, why
       not simply add the new parameters to the LANG property?]]

       [[anchor7: Peter StA: I like CONTACT-LANGUAGE and I'm wondering
       why we didn't define that already in the base vCard4 spec.]]

       [[anchor8: Chris: The CONTACT-LANGUAGE property seems useful, but
       I don't see how provide specific contact information to specify that I can read other users and speak a language
       but not write the language.  [Alexey: Or
   to speak, but not read a
       language.]]]

       [[anchor9: Dany: We decided keep their copies up to use LANG instead date whenever the information is changed.

   The CAB Enabler provides synchronization of CONTACT-
       LANGUAGE.]]

   Format definition:

       CONTACT-LANGUAGE-param =  pref-param / LANGUAGE-PROFICIENCY-TYPE-
               param / LANGUAGE-FLUENCY-TYPE-param / INDEX-param

       CONTACT-LANGUAGE-value =  language-tag

   Example:

       CONTACT-LANGUAGE;INDEX=1;
         LANGUAGE-PROFICIENCY-TYPE=speak;
         LANGUAGE-FLUENCY-TYPE=fluent:en

2.2.  Property : SERVICE

   Namespace:

   Property name:  SERVICE

   Purpose:  To specify the aliases used on different sites by contact information
   available in the
       object that user device(s) with the vCard refers to.

   Value type:  A single structured value consisting of 3 values
       separated by network-based contact
   repository.

   The CAB Enabler also managed the SEMI-COLON character (U+0059) :

       1.  label : indicating a free-text description distribution of the service

       2.  alias : indicating the alias identifier string used for a
           service

       3.  url : indicating the URL pointing to the service resource

   Cardinality:  *

   Property parameters:  INDEX

   Description:

       [[anchor11: Peter StA: SERVICE seems somewhat underspecified; in
       particular the "label" is just user's own contact
   information.  In essence, a free-form name for user fills out a Personal Contact Card,
   which includes all the service,
       but it seems information a user wishes to store about him
   or herself.

   Because systems that different people might call are supporting the same service by
       different names, leading to confusion (e.g., "facebook" vs.
       "FaceBook", "Google" vs. "Gmail" vs. "Google Talk").]]

       [[anchor12: Chris: The SERVICE property seems vague, I prefer CAB Enabler are likely
   supporting multiple users, the
       SOCIALPROFILE name in draft-george-vcarddav-vcard-extension,
       although having CAB Enabler also defines a way to distinguish the unique identifier used
       by search
   paradigm that social service seems useful.]]

       [[anchor13: Cyrus: WRT SERVICE I would like permits other users to draw people's
       attention query those systems to
       http://tools.ietf.org/html/draft-daboo-vcard-service-type (which
       is now expired).  This takes a locate
   information about the available users.

   The CAB Enabler supports many different approach types of defining information.  It,
   therefore, has a
       SERVICE-TYPE parameter for use on existing properties such as
       EMAIL data model that is flexible and IM. 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 allow those communications properties to be
       "tagged" with Document

   Syntax specifications shown here use the service provider identifier.]]

       [[anchor14: Cyrus: I wonder whether instead of SERVICE we should
       be using augmented Backus-Naur Form
   (ABNF) as described in [RFC5234], and are specified as in the existing base
   vcard specification [RFC6350].

2.  vCard URL property combined with SERVICE-
       TYPE. Extensions : Properties

   The existing property already states "social networking
       site identifiers" as one possible use case.  I realize this might
       make 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 little bit harder third has "old postage stamps".  Usage, not
   specification, may lead to do a simple one-to-one mapping
       with OMA attributes, but I do think we should try 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 re-use
       existing vCard properties where ever it makes sense.]]

   Format definition:

       SERVICE-param =  INDEX-param

       SERVICE-value =  text

   Example:

       SERVICE;INDEX=1:facebook;Facili Tie;
         http://fr-fr.facebook.com/people/Facili-Tie/100001298828793

2.3. registries.

2.1.  Property : EXPERTISE

   Namespace:

   Property name:  EXPERTISE

   Purpose:  To specify the expertise(s) of a field in which the object that the vCard
       refers to. to has expertise.

   Value type:  A single string 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

       EXPERTISE-value =  text

   Examples:

       EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature

       EXPERTISE;INDEX=1;LEVEL=expert:chemistry

2.4.

2.2.  Property : HOBBY

   Namespace:

   Property name:  HOBBY

   Purpose:  To specify the hobbies of the object that the vCard refers
       to.

   Value type:  A single string 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.5) 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

       HOBBY-value =  text

   Examples:

       HOBBY;INDEX=1;LEVEL=high:reading

       HOBBY;INDEX=2;LEVEL=high:sewing

2.5.

2.3.  Property : INTEREST

   Namespace:

   Property name:  INTEREST

   Purpose:  To specify the interest(s) of the object that the vCard
       refers to.

   Value type:  A single string 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.4) 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

       INTEREST-value =  text

   Examples:

       INTEREST;INDEX=1;LEVEL=medium:r&b music

       INTEREST;INDEX=2;LEVEL=high:rock'n roll music

2.6.  Property : PUBLICNOTE

   Namespace:

   Property name:  PUBLICNOTE

   Purpose:  To specify additional information associated with the
       object the vCard refers to.

   Value type:  A single string value

   Cardinality:  *

   Property parameters:

   Description:

       [[anchor17: Peter StA: How is PUBLICNOTE different from NOTE in
       the base spec?  The example ("Out of my office today") seems more
       like presence than vCard.]]

       [[anchor18: Chris: I don't understand PUBLICNOTE or how it might
       be used or presented in a UI.  The example looks like it's going
       to be used as a presence status or something like that.  Seems
       too vague to be useful.]]

       [[anchor19: Dany: Yes, it looks like information stored by a
       presence server but it is not because CAB doesn't deal with
       presence information.  NOTE could be used to stored somthing like
       "This is my personal card" and PUBLICNOTE could be used to store
       something like "I would like to reach tennis players in New-
       York".  So, my suggestion is to change the example with something
       which represents a more permanent information.  Examples could
       be, "I live in Beijing", "Waiting for a job", "I spoke to Barack
       OBAMA", "Motorbike fanatic".  Hence, to me, NOTE is a permanent
       information (like "this is ALICE's personal card"), PUBLICNOTE is
       a semi-permanent information (like "Waiting for a job"), and
       presence is a temporary information (like "out of my office
       today").]]

       [[anchor20: Barry: I think the decision was to use PUBLICNOTE, one enjoys watching matches,
           but make the description clearer.  I will take a stab at that.]] doesn't play.

   Format definition:

       PUBLICNOTE-param

       INTEREST-param =  language-param

       PUBLICNOTE-value  LEVEL-param / INDEX-param

       INTEREST-value =  text

   Example:

       PUBLICNOTE;LANGUAGE=en:Out of my office today

2.7.

   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 the organization-directory a directory of an organization the object the
       vCard represents. vCard's
       entity belongs to.

   Value type:  A single URI value.

   Cardinality:  *

   Property parameters:  PREF, INDEX

   Description:

       [[anchor22: Chris: ORG-DIRECTORY  This is interesting, but I'd like an
       example with an LDAP URL.]]

       [[anchor23: Alexey: Additionally: does use of intended to be a particular URI
       scheme implies 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
       co-workers, management chain, and so on, in a particular data format?  HTTP URIs (for example)
       don't provide enough information about format of company or
       organizational directory.

       How the resource by
       themselves.]]

       [[anchor24: Dany: Need better description of what ORG-DIRECTORY
       means lookup is done depends upon the URI scheme, and eventually mapping with SOURCE.]] 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 useable for automated lookup or searching.

   Format definition:

       ORG-DIRECTORY-param =  pref-param / INDEX-param

       ORG-DIRECTORY-value=  uri

   Examples:

       ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com

       ORG-DIRECTORY;PREF=1;INDEX=2:http://mycompany.example2.com

       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:

       [[anchor27: Simon: I don't understand the difference between  When a property is multi-valued, INDEX and PID.]] can be used to
       indicate an ordering or sequence of the values.

   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

       ORG-URI;INDEX=1:http://mycompany.example1.com

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

3.2.  Parameter : LANGUAGE-PROFICIENCY-TYPE

   Namespace:

   Parameter name:  LANGUAGE-PROFICIENCY-TYPE
   Purpose:  Used to indicate which degree of proficiency the object the
       vCard represents attained in the corresponding language.

   Description:  Possible values are "read only", "speak", "read/write".

   Format definition:

       LANGUAGE-PROFICIENCY-TYPE-param =  "LANGUAGE-PROFICIENCY-TYPE="
               LANGUAGE-PROFICIENCY-TYPE-value

       LANGUAGE-PROFICIENCY-TYPE-value =  "read only" / "speak" / "read/
               write"

   Example:

       CONTACT-LANGUAGE;LANGUAGE-PROFICIENCY-TYPE=speak:en

3.3.  Parameter : LANGUAGE-FLUENCY-TYPE

   Namespace:

   Parameter name:  LANGUAGE-FLUENCY-TYPE

   Purpose:  Used to indicate which degree of fluency the object the
       vCard represents attained in the corresponding language.

   Description:  Possible values are "beginner", "average", "fluent".

   Format definition:

       LANGUAGE-FLUENCY-TYPE-param =  "LANGUAGE-FLUENCY-TYPE=" LANGUAGE-
               FLUENCY-TYPE-value

       LANGUAGE-FLUENCY-TYPE-value =  "beginner" / "average" / "fluent"

   Example:

       CONTACT-LANGUAGE;LANGUAGE-FLUENCY-TYPE=fluent:en

3.4.  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:  Possible 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].

   [[anchor31: Chris: Some of these may have security and/or privacy
   considerations -- the PUBLICNOTE is sensitive.  The SERVICE or
   SOCIALPROFILE enables automated "friend invite" spam.]]

5.  IANA Considerations

   IANA is requested to add the following entries to the vCard
   Properties registry, defined in [RFC6350] section 10.3.1.

     +-------+---------------------------+-------------------+
     | Name  |                           |                   |
     | space | Property                  | Reference         |
     +-------+---------------------------+-------------------+
     |       | CONTACT-LANGUAGE EXPERTISE                 | RFCXXXX, sec 2.1  |
     |       | SERVICE HOBBY                     | RFCXXXX, sec 2.2  |
     |       | EXPERTISE INTEREST                  | RFCXXXX, sec 2.3  |
     |       | HOBBY ORG-URI                   | RFCXXXX, sec 2.4  |
     |       | INTEREST                  | RFCXXXX, sec 2.5  |
     |       | PUBLICNOTE                | RFCXXXX, sec 2.6  |
     |       | ORG-DIRECTORY             | RFCXXXX, sec 2.7  |
     +-------+---------------------------+-------------------+

   IANA is requested to add the following entries to the vCard
   Parameters registry, defined in [RFC6350] section 10.3.2.

     +-------+---------------------------+-------------------+
     | Name  |                           |                   |
     | space | Parameter                 | Reference         |
     +-------+---------------------------+-------------------+
     |       | INDEX                     | RFCXXXX, sec 3.1  |
     |       | LANGUAGE-PROFICIENCY-TYPE | RFCXXXX, sec 3.2  |
     |       | LANGUAGE-FLUENCY-TYPE     | RFCXXXX, sec 3.3  |
     |       | LEVEL                     | RFCXXXX, sec 3.4 3.2  |
     +-------+---------------------------+-------------------+

6.  Acknowledgments

   Thanks to Simon Perrault, Perreault, Peter St. Andre, Saint-Andre, and Chris Newman for
   particularly thorough reviews, which led to a much cleaner submission
   to the working group.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5234]  Crocker, D. 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.

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