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
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6715.
|
|
|---|---|---|---|
| Authors | Dany Cauchie , Barry Leiba , Kepeng Li | ||
| Last updated | 2011-10-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6715 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-vcarddav-oma-cab-extensions-00
vcarddav D. Cauchie
Internet-Draft France Telecom - Orange
Intended status: Standards Track B. Leiba
Expires: April 22, 2012 K. Li
Huawei Technologies
October 20, 2011
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
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, 2012.
Copyright Notice
Copyright (c) 2011 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
Cauchie, et al. Expires April 22, 2012 [Page 1]
Internet-Draft vCard-OMA-CAB October 2011
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. Terminology Used in This Document . . . . . . . . . . . . . 3
2. vCard Extensions : Properties . . . . . . . . . . . . . . . 3
2.1. Property : CONTACT-LANGUAGE . . . . . . . . . . . . . . . . 3
2.2. Property : SERVICE . . . . . . . . . . . . . . . . . . . . . 5
2.3. Property : EXPERTISE . . . . . . . . . . . . . . . . . . . . 6
2.4. Property : HOBBY . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Property : INTEREST . . . . . . . . . . . . . . . . . . . . 8
2.6. Property : PUBLICNOTE . . . . . . . . . . . . . . . . . . . 9
2.7. Property : ORG-DIRECTORY . . . . . . . . . . . . . . . . . . 10
3. vCard extensions : Parameters . . . . . . . . . . . . . . . 12
3.1. Parameter : INDEX . . . . . . . . . . . . . . . . . . . . . 12
3.2. Parameter : LANGUAGE-PROFICIENCY-TYPE . . . . . . . . . . . 12
3.3. Parameter : LANGUAGE-FLUENCY-TYPE . . . . . . . . . . . . . 13
3.4. Parameter : LEVEL . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
7. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Cauchie, et al. Expires April 22, 2012 [Page 2]
Internet-Draft vCard-OMA-CAB October 2011
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 to be interpreted as described in [RFC2119].
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.
[[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
a few more introduction sentences with a reference would be
helpful.]]
[[anchor4: Alexey: I would like 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
Cauchie, et al. Expires April 22, 2012 [Page 3]
Internet-Draft vCard-OMA-CAB October 2011
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 to specify that I can read and speak a language
but not write the language. [Alexey: Or to speak, but not read a
language.]]]
[[anchor9: Dany: We decided to use LANG instead 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
Cauchie, et al. Expires April 22, 2012 [Page 4]
Internet-Draft vCard-OMA-CAB October 2011
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 the
object that the vCard refers to.
Value type: A single structured value consisting of 3 values
separated by the SEMI-COLON character (U+0059) :
1. label : indicating a free-text description 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 a free-form name for the service,
but it seems that different people might call 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 the
SOCIALPROFILE name in draft-george-vcarddav-vcard-extension,
although having a way to distinguish the unique identifier used
by that social service seems useful.]]
Cauchie, et al. Expires April 22, 2012 [Page 5]
Internet-Draft vCard-OMA-CAB October 2011
[[anchor13: Cyrus: WRT SERVICE I would like to draw people's
attention to
http://tools.ietf.org/html/draft-daboo-vcard-service-type (which
is now expired). This takes a different approach of defining a
SERVICE-TYPE parameter for use on existing properties such as
EMAIL and IM. This allow those communications properties to be
"tagged" with the service provider identifier.]]
[[anchor14: Cyrus: I wonder whether instead of SERVICE we should
be using the existing vCard URL property combined with SERVICE-
TYPE. The existing property already states "social networking
site identifiers" as one possible use case. I realize this might
make it a little bit harder to do a simple one-to-one mapping
with OMA attributes, but I do think we should try 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. Property : EXPERTISE
Namespace:
Property name: EXPERTISE
Purpose: To specify the expertise(s) of the object that the vCard
refers to.
Value type: A single string value.
Cauchie, et al. Expires April 22, 2012 [Page 6]
Internet-Draft vCard-OMA-CAB October 2011
Cardinality: *
Property parameters: LEVEL (possible values : "beginner", "average",
"expert"), INDEX
Description:
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. 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
Cauchie, et al. Expires April 22, 2012 [Page 7]
Internet-Draft vCard-OMA-CAB October 2011
Description: A hobby, as opposed to an interest (see Section 2.5) 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. 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
Cauchie, et al. Expires April 22, 2012 [Page 8]
Internet-Draft vCard-OMA-CAB October 2011
Description: An interest, as opposed to a hobby (see Section 2.4) 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:
Cauchie, et al. Expires April 22, 2012 [Page 9]
Internet-Draft vCard-OMA-CAB October 2011
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,
but make the description clearer. I will take a stab at that.]]
Format definition:
PUBLICNOTE-param = language-param
PUBLICNOTE-value = text
Example:
PUBLICNOTE;LANGUAGE=en:Out of my office today
2.7. Property : ORG-DIRECTORY
Namespace:
Cauchie, et al. Expires April 22, 2012 [Page 10]
Internet-Draft vCard-OMA-CAB October 2011
Property name: ORG-DIRECTORY
Purpose: To specify the organization-directory of the object the
vCard represents.
Value type: A single URI value.
Cardinality: *
Property parameters: PREF, INDEX
Description:
[[anchor22: Chris: ORG-DIRECTORY is interesting, but I'd like an
example with an LDAP URL.]]
[[anchor23: Alexey: Additionally: does use of a particular URI
scheme implies a particular data format? HTTP URIs (for example)
don't provide enough information about format of the resource by
themselves.]]
[[anchor24: Dany: Need better description of what ORG-DIRECTORY
means and eventually mapping with SOURCE.]]
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
Cauchie, et al. Expires April 22, 2012 [Page 11]
Internet-Draft vCard-OMA-CAB October 2011
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
INDEX and PID.]]
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
3.2. Parameter : LANGUAGE-PROFICIENCY-TYPE
Namespace:
Parameter name: LANGUAGE-PROFICIENCY-TYPE
Cauchie, et al. Expires April 22, 2012 [Page 12]
Internet-Draft vCard-OMA-CAB October 2011
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"
Cauchie, et al. Expires April 22, 2012 [Page 13]
Internet-Draft vCard-OMA-CAB October 2011
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 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
Cauchie, et al. Expires April 22, 2012 [Page 14]
Internet-Draft vCard-OMA-CAB October 2011
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 | RFCXXXX, sec 2.1 |
| | SERVICE | RFCXXXX, sec 2.2 |
| | EXPERTISE | RFCXXXX, sec 2.3 |
| | HOBBY | 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 |
+-------+---------------------------+-------------------+
6. Acknowledgments
Thanks to Simon Perrault, Peter St. 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/
Cauchie, et al. Expires April 22, 2012 [Page 15]
Internet-Draft vCard-OMA-CAB October 2011
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
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. Expires April 22, 2012 [Page 16]