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, . 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]