draft-ietf-vcarddav-oma-cab-extensions-00.txt   draft-ietf-vcarddav-oma-cab-extensions-01.txt 
vcarddav D. Cauchie vcarddav D. Cauchie
Internet-Draft France Telecom - Orange Internet-Draft France Telecom - Orange
Intended status: Standards Track B. Leiba Intended status: Standards Track B. Leiba
Expires: April 22, 2012 K. Li Expires: September 3, 2012 K. Li
Huawei Technologies Huawei Technologies
October 20, 2011 March 2, 2012
vCard Format extension : represent vCard extensions defined by the Open vCard Format extension : represent vCard extensions defined by the Open
Mobile Alliance (OMA) Converged Address Book (CAB) group Mobile Alliance (OMA) Converged Address Book (CAB) group
draft-ietf-vcarddav-oma-cab-extensions-00 draft-ietf-vcarddav-oma-cab-extensions-01
Abstract Abstract
This document defines extensions to the vCard data format for This document defines extensions to the vCard data format for
representing and exchanging certain contact information. The representing and exchanging certain contact information. The
properties covered here have been defined by the Open Mobile Alliance properties covered here have been defined by the Open Mobile Alliance
Converged Address Book group, in order to synchronize, using OMA Data Converged Address Book group, in order to synchronize, using OMA Data
Synchronization, important contact fields that were not already Synchronization, important contact fields that were not already
defined in the base vCard 4.0 specification. defined in the base vCard 4.0 specification.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2012. This Internet-Draft will expire on September 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used in This Document . . . . . . . . . . . . . 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 2. vCard Extensions : Properties . . . . . . . . . . . . . . . 4
2.1. Property : CONTACT-LANGUAGE . . . . . . . . . . . . . . . . 3 2.1. Property : EXPERTISE . . . . . . . . . . . . . . . . . . . . 4
2.2. Property : SERVICE . . . . . . . . . . . . . . . . . . . . . 5 2.2. Property : HOBBY . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Property : EXPERTISE . . . . . . . . . . . . . . . . . . . . 6 2.3. Property : INTEREST . . . . . . . . . . . . . . . . . . . . 6
2.4. Property : HOBBY . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Property : ORG-DIRECTORY . . . . . . . . . . . . . . . . . . 7
2.5. Property : INTEREST . . . . . . . . . . . . . . . . . . . . 8
2.6. Property : PUBLICNOTE . . . . . . . . . . . . . . . . . . . 9
2.7. Property : ORG-DIRECTORY . . . . . . . . . . . . . . . . . . 10
3. vCard extensions : Parameters . . . . . . . . . . . . . . . 12 3. vCard extensions : Parameters . . . . . . . . . . . . . . . 8
3.1. Parameter : INDEX . . . . . . . . . . . . . . . . . . . . . 12 3.1. Parameter : INDEX . . . . . . . . . . . . . . . . . . . . . 8
3.2. Parameter : LANGUAGE-PROFICIENCY-TYPE . . . . . . . . . . . 12 3.2. Parameter : LEVEL . . . . . . . . . . . . . . . . . . . . . 9
3.3. Parameter : LANGUAGE-FLUENCY-TYPE . . . . . . . . . . . . . 13
3.4. Parameter : LEVEL . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . 15 7. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 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 Synchronization of an Open Mobile Alliance Converged Address Book
[OMA-CAB], using Open Mobile Alliance Data Synchronization (OMA-DS), [OMA-CAB], using Open Mobile Alliance Data Synchronization (OMA-DS),
commonly uses vCard as an exchange format between the DS Server and commonly uses vCard as an exchange format between the DS Server and
the DS Client. In order to properly perform synchronization of an the DS Client. In order to properly perform synchronization of an
OMA-CAB, the CAB specification defines some important CAB contact OMA-CAB, the CAB specification defines some important CAB contact
fields not already defined in the vCard base specification. This fields not already defined in the vCard base specification. This
document re-uses the definitions found in the OMA-CAB specification document re-uses the definitions found in the OMA-CAB specification
and describes them as vCard extensions. The following sections and describes them as vCard extensions. The following sections
define the necessary Properties and Parameters. define the necessary Properties and Parameters.
1.1. Terminology Used in This Document 1.1. A Brief Introduction to the Converged Address Book
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
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
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: 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.
[[anchor11: Peter StA: SERVICE seems somewhat underspecified; in The CAB Enabler provides synchronization of the contact information
particular the "label" is just a free-form name for the service, available in the user device(s) with the network-based contact
but it seems that different people might call the same service by repository.
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 The CAB Enabler also managed the distribution of a user's own contact
SOCIALPROFILE name in draft-george-vcarddav-vcard-extension, information. In essence, a user fills out a Personal Contact Card,
although having a way to distinguish the unique identifier used which includes all the information a user wishes to store about him
by that social service seems useful.]] or herself.
[[anchor13: Cyrus: WRT SERVICE I would like to draw people's Because systems that are supporting the CAB Enabler are likely
attention to supporting multiple users, the CAB Enabler also defines a search
http://tools.ietf.org/html/draft-daboo-vcard-service-type (which paradigm that permits other users to query those systems to locate
is now expired). This takes a different approach of defining a information about the available users.
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 The CAB Enabler supports many different types of information. It,
be using the existing vCard URL property combined with SERVICE- therefore, has a data model that is flexible and extensible. It
TYPE. The existing property already states "social networking manages traditional types of contact information (such as name,
site identifiers" as one possible use case. I realize this might address, email, phone number, mobile number) as well as new types of
make it a little bit harder to do a simple one-to-one mapping information (such as websites, blogs, presence subscription
with OMA attributes, but I do think we should try and re-use references).
existing vCard properties where ever it makes sense.]]
Format definition: 1.2. Terminology Used in This Document
SERVICE-param = INDEX-param 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].
SERVICE-value = text 2. vCard Extensions : Properties
Example: The following sections define the CAB Properties.
SERVICE;INDEX=1:facebook;Facili Tie; Note:
http://fr-fr.facebook.com/people/Facili-Tie/100001298828793 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.3. Property : EXPERTISE 2.1. Property : EXPERTISE
Namespace: Namespace:
Property name: EXPERTISE Property name: EXPERTISE
Purpose: To specify the expertise(s) of the object that the vCard Purpose: To specify a field in which the object that the vCard
refers to. refers to has expertise.
Value type: A single string value. Value type: A single string value.
Cardinality: * Cardinality: *
Property parameters: LEVEL (possible values : "beginner", "average", Property parameters: LEVEL (possible values : "beginner", "average",
"expert"), INDEX "expert"), INDEX
Description: 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: Format definition:
EXPERTISE-param = LEVEL-param / INDEX-param EXPERTISE-param = LEVEL-param / INDEX-param
EXPERTISE-value = text EXPERTISE-value = text
Examples: Examples:
EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature EXPERTISE;LEVEL=beginner;INDEX=2:chinese literature
EXPERTISE;INDEX=1;LEVEL=expert:chemistry EXPERTISE;INDEX=1;LEVEL=expert:chemistry
2.4. Property : HOBBY 2.2. Property : HOBBY
Namespace: Namespace:
Property name: HOBBY Property name: HOBBY
Purpose: To specify the hobbies of the object that the vCard refers Purpose: To specify the hobbies of the object that the vCard refers
to. to.
Value type: A single string value. Value type: A single string value.
Cardinality: * Cardinality: *
Property parameters: LEVEL (possible values : "high", "medium", Property parameters: LEVEL (possible values : "high", "medium",
"low"), INDEX "low"), INDEX
Description: A hobby, as opposed to an interest (see Section 2.5) is Description: This is intended to be a free-form naming of hobbies,
an activity that one actively engages in for entertainment, 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.3) is an
activity that one actively engages in for entertainment,
intellectual stimulation, creative expression, or the like. intellectual stimulation, creative expression, or the like.
* "Art" might be a hobby if one actively sculpts or paints. * "Art" might be a hobby if one actively sculpts or paints.
* "Tennis" might be a hobby if one enjoys playing, rather than * "Tennis" might be a hobby if one enjoys playing, rather than
just watching matches. just watching matches.
Format definition: Format definition:
HOBBY-param = LEVEL-param / INDEX-param HOBBY-param = LEVEL-param / INDEX-param
HOBBY-value = text HOBBY-value = text
Examples: Examples:
HOBBY;INDEX=1;LEVEL=high:reading HOBBY;INDEX=1;LEVEL=high:reading
HOBBY;INDEX=2;LEVEL=high:sewing HOBBY;INDEX=2;LEVEL=high:sewing
2.5. Property : INTEREST 2.3. Property : INTEREST
Namespace: Namespace:
Property name: INTEREST Property name: INTEREST
Purpose: To specify the interest(s) of the object that the vCard Purpose: To specify the interest(s) of the object that the vCard
refers to. refers to.
Value type: A single string value Value type: A single string value
Cardinality: * Cardinality: *
Property parameters: LEVEL (possible values : "high", "medium", Property parameters: LEVEL (possible values : "high", "medium",
"low"), INDEX "low"), INDEX
Description: An interest, as opposed to a hobby (see Section 2.4) is Description: This is intended to be a free-form naming of interests,
an activity or topic that one finds interesting, but doesn't 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. necessarily actively engage in.
* "Art" might be an interest if one likes looking at art, but * "Art" might be an interest if one likes looking at art, but
doesn't create art. doesn't create art.
* "Tennis" might be an interest if one enjoys watching matches, * "Tennis" might be an interest if one enjoys watching matches,
but doesn't play. but doesn't play.
Format definition: Format definition:
INTEREST-param = LEVEL-param / INDEX-param INTEREST-param = LEVEL-param / INDEX-param
INTEREST-value = text INTEREST-value = text
Examples: Examples:
INTEREST;INDEX=1;LEVEL=medium:r&b music INTEREST;INDEX=1;LEVEL=medium:r&b music
INTEREST;INDEX=2;LEVEL=high:rock'n roll music INTEREST;INDEX=2;LEVEL=high:rock'n roll music
2.6. Property : PUBLICNOTE 2.4. Property : ORG-DIRECTORY
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,
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: Namespace:
Property name: ORG-DIRECTORY Property name: ORG-DIRECTORY
Purpose: To specify the organization-directory of the object the Purpose: To specify a directory of an organization the vCard's
vCard represents. entity belongs to.
Value type: A single URI value. Value type: A single URI value.
Cardinality: * Cardinality: *
Property parameters: PREF, INDEX Property parameters: PREF, INDEX
Description: Description: This is intended to be a URI that can be used to do an
organization-directory lookup. Presumably, the entity the vCard
[[anchor22: Chris: ORG-DIRECTORY is interesting, but I'd like an represents would be found in the directory, though that isn't
example with an LDAP URL.]] required. This might be used to make it easier to find someone's
co-workers, management chain, and so on, in a company or
organizational directory.
[[anchor23: Alexey: Additionally: does use of a particular URI How the lookup is done depends upon the URI scheme, and no
scheme implies a particular data format? HTTP URIs (for example) attempt is made here to specify details of the lookup mechanism.
don't provide enough information about format of the resource by
themselves.]]
[[anchor24: Dany: Need better description of what ORG-DIRECTORY An HTTP URI might, for example, lead to a web form that's
means and eventually mapping with SOURCE.]] intended for manual lookup in a browser -- thus, this URI might
or might not be useable for automated lookup or searching.
Format definition: Format definition:
ORG-DIRECTORY-param = pref-param / INDEX-param ORG-DIRECTORY-param = pref-param / INDEX-param
ORG-DIRECTORY-value= uri ORG-DIRECTORY-value= uri
Examples: Examples:
ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com ORG-DIRECTORY;INDEX=1:http://directory.mycompany.example.com
ORG-DIRECTORY;PREF=1;INDEX=2:http://mycompany.example2.com ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/
o=Example%20Tech,ou=Engineering
3. vCard extensions : Parameters 3. vCard extensions : Parameters
The following sections define Parameters used within Properties The following sections define Parameters used within Properties
definitions. definitions.
3.1. Parameter : INDEX 3.1. Parameter : INDEX
Namespace: Namespace:
Parameter name: INDEX Parameter name: INDEX
Purpose: Used in a multi-valued property to indicate the position of Purpose: Used in a multi-valued property to indicate the position of
this value within the set of values. this value within the set of values.
Description: Description: When a property is multi-valued, INDEX can be used to
indicate an ordering or sequence of the values.
[[anchor27: Simon: I don't understand the difference between
INDEX and PID.]]
Format definition: Format definition:
INDEX-param = "INDEX=" INDEX-value INDEX-param = "INDEX=" INDEX-value
INDEX-value = integer INDEX-value = integer
Examples: Examples:
ORG-DIRECTORY;INDEX=1:http://mycompany.example1.com ORG-URI;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
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 ORG-URI;PREF=1;INDEX=2:http://mycompany.example2.com
3.4. Parameter : LEVEL 3.2. Parameter : LEVEL
Namespace: Namespace:
Parameter name: LEVEL Parameter name: LEVEL
Purpose: Used to indicate a level of expertise, hobby or interest Purpose: Used to indicate a level of expertise, hobby or interest
attained by the object the vCard represents. attained by the object the vCard represents.
Description: Possible values: Description: Possible values:
skipping to change at page 14, line 41 skipping to change at page 10, line 7
Examples: Examples:
EXPERTISE;LEVEL=beginner:chinese literature EXPERTISE;LEVEL=beginner:chinese literature
HOBBY;LEVEL=high:reading HOBBY;LEVEL=high:reading
INTEREST;LEVEL=medium:r&b music INTEREST;LEVEL=medium:r&b music
4. Security Considerations 4. Security Considerations
This presents no security considerations beyond those in section 9 of This document presents no security considerations beyond those in
the base vcard specification [RFC6350]. 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 5. IANA Considerations
IANA is requested to add the following entries to the vCard IANA is requested to add the following entries to the vCard
Properties registry, defined in [RFC6350] section 10.3.1. Properties registry, defined in [RFC6350] section 10.3.1.
+-------+---------------------------+-------------------+ +-------+---------------------------+-------------------+
| Name | | | | Name | | |
| space | Property | Reference | | space | Property | Reference |
+-------+---------------------------+-------------------+ +-------+---------------------------+-------------------+
| | CONTACT-LANGUAGE | RFCXXXX, sec 2.1 | | | EXPERTISE | RFCXXXX, sec 2.1 |
| | SERVICE | RFCXXXX, sec 2.2 | | | HOBBY | RFCXXXX, sec 2.2 |
| | EXPERTISE | RFCXXXX, sec 2.3 | | | INTEREST | RFCXXXX, sec 2.3 |
| | HOBBY | RFCXXXX, sec 2.4 | | | 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 IANA is requested to add the following entries to the vCard
Parameters registry, defined in [RFC6350] section 10.3.2. Parameters registry, defined in [RFC6350] section 10.3.2.
+-------+---------------------------+-------------------+ +-------+---------------------------+-------------------+
| Name | | | | Name | | |
| space | Parameter | Reference | | space | Parameter | Reference |
+-------+---------------------------+-------------------+ +-------+---------------------------+-------------------+
| | INDEX | RFCXXXX, sec 3.1 | | | INDEX | RFCXXXX, sec 3.1 |
| | LANGUAGE-PROFICIENCY-TYPE | RFCXXXX, sec 3.2 | | | LEVEL | RFCXXXX, sec 3.2 |
| | LANGUAGE-FLUENCY-TYPE | RFCXXXX, sec 3.3 |
| | LEVEL | RFCXXXX, sec 3.4 |
+-------+---------------------------+-------------------+ +-------+---------------------------+-------------------+
6. Acknowledgments 6. Acknowledgments
Thanks to Simon Perrault, Peter St. Andre, and Chris Newman for Thanks to Simon Perreault, Peter Saint-Andre, and Chris Newman for
particularly thorough reviews, which led to a much cleaner submission particularly thorough reviews, which led to a much cleaner submission
to the working group. to the working group.
7. Normative References 7. Normative References
[OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB) [OMA-CAB] Open Mobile Alliance, "Converged Address Book (CAB)
Specification", October 2010, <http:// Specification", October 2010, <http://
www.openmobilealliance.org/Technical/release_program/docs/ www.openmobilealliance.org/Technical/release_program/docs/
CopyrightClick.aspx?pck=CAB&file=V1_0-20101019-C/ CopyrightClick.aspx?pck=CAB&file=V1_0-20101019-C/
OMA-TS-CAB-V1_0-20101019-C.pdf>. OMA-TS-CAB-V1_0-20101019-C.pdf>.
Candidate Version 1.0, OMA-TS-CAB-V1_0-20101019-C 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 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. August 2011.
Authors' Addresses Authors' Addresses
Dany Cauchie Dany Cauchie
France Telecom - Orange France Telecom - Orange
2 Avenue Pierre Marzin 2 Avenue Pierre Marzin
Lannion 22307 Lannion 22307
France France
Phone: +33 2 96 05 31 16 Phone: +33 2 96 05 31 16
Email: dany.cauchie@orange-ftgroup.com Email: dany.cauchie@orange.com
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
Kepeng Li Kepeng Li
Huawei Technologies Huawei Technologies
 End of changes. 50 change blocks. 
303 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/