< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/