This JEP specifies how to represent data about IM users and other XMPP entities in terms of the Data Forms protocol.
WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Informational
Number: 0154
Version: 0.1
Last Updated: 2005-06-16
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0004, JEP-0060, JEP-0068
Supersedes: JEP-0054
Superseded By: None
Short Name: profiledata
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
It is widely acknowledged within the Jabber/XMPP community that the vcard-temp [1] specification (JEP-0054) has outlived its usefulness. There are several reasons for this conclusion:
Given the weaknesses of vCard, there is interest across the broader Internet community in replacing vCard with something more modern and extensible. Unfortunately, no other standards development organization has developed an alternative to vCard. Part of the challenge is that quite detailed ontologies have been developed that might replace parts of the vCard specification (e.g., the Extensible Name and Address Language [4] developed by OASIS [5]) while less-formal ontologies are being used to represent other parts of the problem space (e.g., Friend of a Friend (FOAF) [6]). The relevant protocols are in flux and it is unclear when (or even if) stability will emerge.
Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond JEP-0054, this JEP specifies a consistent framework for the wire representation of profile data fields in terms of the Data Forms [7] protocol, further qualified using the standardization concepts specified in Field Standardization for Data Forms [8]. The rationale behind this design decision is provided below.
Note: This JEP does not offer solutions to the problems of publishing, storing, and retrieving profile data. Those issues will be addressed in a separate proposal.
This JEP addresses the following requirements:
As noted, this JEP does not offer solutions to the problems of publishing, storing, and retrieving profile data. Those issues will be addressed in a separate proposal.
There are many possible approaches to representing profile data for communication over XMPP networks, including the following:
Structured data formats, such as User Geolocation [10] and User Physical Location [11].
Such data formats have the advantage of being human-readable. However:
A format represented by means of Resource Description Framework [12].
An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:
A format represented by means of Infobits [14].
The infobits approach to representing profile data was deprecated in early 2004 because it provides few advantages over an approach based on Data Forms.
A format represented by means of Data Forms (JEP-0004).
The Data Forms protocol defined in JEP-0004 has several advantages for use over XMPP:
For these reasons, this proposal specifies a way to represent profile data in terms of the Data Forms (jabber:x:data) protocol.
This proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profiledata', in accordance with the field standardization methods defined in JEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the Jabber Registrar [15] (although they may or may not be defined in a Jabber Enhancement Proposal). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of JEP-0068. [16]
The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:
Example 1. A Basic Example
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/profiledata</value>
</field>
<field var='display_name'>
<value>Peter Saint-Andre</value>
</field>
<field var='nickname'>
<value>stpeter</value>
<value>psa</value>
</field>
<field var='x-favorite_painters'>
<value>Joaquin Sorolla</value>
<value>Jan Vermeer</value>
</field>
</x>
By specifying that all fields are scoped by a FORM_TYPE of 'http://jabber.org/protocol/profiledata', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://jabber.org/protocol/profiledata' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.
However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (RFC 2426) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.
In order to address most (if not all) of the pieces of information described in existing profile specifications, this JEP defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the Jabber Registrar Considerations section of this JEP.
The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the Jabber Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, and other existing specifications.
Mappings are provided to vCard, xNAL, and FOAF.
A display name is a version of a person's name intended for display in a user interface. Sometimes also called a "full name" or "formatted name".
The Data Forms field that represents a display name is "display_name".
This field maps to:
Example 2. Display Name
<field var='display_name'>
<value>Peter Saint-Andre</value>
</field>
A family name is that part of a person's name which signifies the person's primary family association. Sometimes also called a "last name" or "surname".
The Data Forms field that represents a family name is "family_name".
This field maps to:
Example 3. Family Name
<field var='family_name'>
<value>Saint-Andre</value>
</field>
A given name is that part of a person's name which signifies the person's primary individual identity. Sometimes also called a "first name" or (in some countries) a "Christian name".
The Data Forms field that represents a given name is "given_name".
This field maps to:
Example 4. Given Name
<field var='given_name'>
<value>John</value>
</field>
A middle name is that part of a person's name which signifies the person's secondary individual identity. Sometimes also called a "middle initial".
The Data Forms field that represents a middle name is "middle_name".
This field maps to:
Example 5. Middle Name
<field var='middle_name'>
<value>Peter</value>
</field>
A name prefix is that part of a person's name which prepends the person's full name (e.g., Mr or Dr). Sometimes also called an "honorific" or "title".
The Data Forms field that represents a name prefix is "name_prefix".
This field maps to:
Example 6. Name Prefix
<field var='name_prefix'>
<value>Mr</value>
</field>
A name suffix is that part of a person's name which is appended to the person's full name (e.g., Jr or Esq).
The Data Forms field that represents a name suffix is "name_suffix".
This field maps to:
Example 7. Name Suffix
<field var='name_suffix'>
<value>Esq</value>
</field>
A nickname is a familiar name that may be used in informal contexts. Sometimes also called an "alias".
The Data Forms field that represents a nickname is "nickname".
This field maps to:
Example 8. Nickname
<field var='nickname'>
<value>stpeter</value>
<value>psa</value>
</field>
In some cultures, one's name includes a part that is derived from the given name of one's father; this part of one's name is called a "patronymic".
The Data Forms field that represents a patronymic is "patronymic".
Example 9. A Patronymic
<field var='patronymic'>
<value>Ivanovich</value>
</field>
Mappings are provided to vCard, xNAL, and JEP-0112 (User Physical Location [17]).
A country is the sovereign nation in which a person is located. Sometimes also called a "nation".
The Data Forms fields that represent a country are "country", "home_country", and "work_country" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 10. Country
<field var='country'>
<value>USA</value>
</field>
A region is a second-level administrative unit within the nation in which a person is located. Sometimes also called a "province", "state", or "administrative area".
The Data Forms field that represents a region is "region".
The Data Forms fields that represent a region are "home_region" and "work_region" for home addresses and work addresses respectively.
This field maps to:
Example 11. Region
<field var='region'>
<value>New York</value>
</field>
A locality is a defined place within the region in which a person is located. Sometimes also called a "city", "town", or "village".
The Data Forms fields that represent a locality are "locality", "home_locality", and "work_locality" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 12. Locality
<field var='locality'>
<value>New York City</value>
</field>
An area is a sub-division within the locality in which a person is located. Sometimes also called a "neighborhood", "suburb", "district", or "section".
The Data Forms fields that represent a area are "area", "home_area", and "work_area" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 13. Area
<field var='area'>
<value>Manhattan</value>
</field>
A street is the street address (number plus street name, or two street names at an intersection) at which a person is located, or a postal box number for physical mail delivery. Sometimes also called a "street address".
The Data Forms fields that represent a street are "street", "home_street", and "work_street" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 14. Street
<field var='street'>
<value>Fifth Avenue and 34th Street</value>
</field>
A building is the name for a specific structure on a street or within an area.
The Data Forms fields that represent a building are "building", "home_building", and "work_building" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 15. Building
<field var='building'>
<value>Empire State Building</value>
</field>
A floor is a named or numbered floor or level within a building. Sometimes also called a "level", "block", or "suite".
The Data Forms fields that represent a floor are "floor", "home_floor", and "work_floor" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 16. Floor
<field var='floor'>
<value>102</value>
</field>
A room is a named or numbered subdivision of a floor. Sometimes also called a "unit" or "apartment".
The Data Forms fields that represent a room are "room", "home_room", and "work_room" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 17. Room
<field var='room'>
<value>Observatory</value>
</field>
A postal box is a set of numeric or alphanumeric characters used to identify a mailbox at a postal delivery center.
The Data Forms fields that represent a postal box are "postalbox", "home_postalbox", and "work_postalbox" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 18. Postal Box
<field var='postalbox'>
<value>1641</value>
</field>
A postal code is a set of numeric or alphanumeric characters used to identify an area for postal delivery. Sometimes also called a "ZIP code" (in the U.S.).
The Data Forms fields that represent a postal code are "postalcode", "home_postalcode", and "work_postalcode" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 19. Postal Code
<field var='postalcode'>
<value>10002</value>
</field>
Mappings are provided to vCard and JEP-0080 (User Geolocation [18]).
Altitude is a person's height or depth in relationship to sea level, where positive altitude is meters above sea level and negative altitude is meters below sea level.
The Data Forms field that represents altitude is "alt".
This field maps to:
Example 20. Altitude
<field var='alt'>
<value>1609</value>
</field>
Latitude is a person's latitude in relation to the equator, where positive latitude is north of the equator and negative latitude is south of the equator.
The Data Forms field that represents latitude is "lat".
This field maps to:
Example 21. Latitude
<field var='lat'>
<value>39.75477</value>
</field>
Longitude is a person's longitude in relation to the equator, where positive longitude is east of the meridian and negative longitude is west of the equator.
The Data Forms field that represents longitude is "lon".
This field maps to:
Example 22. Latitude
<field var='lon'>
<value>-104.99768</value>
</field>
A fax number is a number for a machine that handles fascimile transmissions.
The Data Forms fields that represent a fax number are "fax", "home_fax", and "work_fax" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 23. Fax Number
<field var='fax'>
<value>303-308-3215</value>
</field>
A landline telephone number is a number for a traditional "PSTN" or "POTS" telephone.
The Data Forms fields that represent a landline telephone number are "landline", "home_landline", and "work_landline" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 24. Landline Telephone Number
<field var='landline_phone'>
<value>303-308-3282</value>
</field>
A mobile telephone number is a number for a mobile phone or cell phone on a wireless network.
The Data Forms fields that represent a mobile telephone number are "mobile", "home_mobile", and "work_mobile" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 25. Mobile Telephone Number
<field var='mobile_phone'>
<value>303-555-1212</value>
</field>
A pager number is a number for a dedicated alphanumeric paging device.
The Data Forms fields that represent a pager number are "pager", "home_pager", and "work_pager" for generic addresses, home addresses, and work addresses respectively.
This field maps to:
Example 26. Pager Number
<field var='pager'>
<value>303-555-1212</value>
</field>
A SIP address is a sip: or sips: URI at which a person can be contacted for Voice over Internet Protocol (VoIP) communications.
The Data Forms field that represents a SIP address is "sip_address".
This field does not map to data in vCard or any other profile representation format.
Example 27. SIP Address
<field var='sip_address'>
<value>sip:stpeter@sipspeare.lit</value>
</field>
A Skype address is an address on the popular Skype system for Voice over Internet Protocol (VoIP) communications.
The Data Forms field that represents a SIP address is "skype_address".
This field does not map to data in vCard or any other profile representation format.
Example 28. Skype Address
<field var='sip_address'>
<value>SomeSkypeUser</value>
</field>
An AIM screen name is an address at which a person or other entity can be contacted on the AOL Instant Messenger service.
The Data Forms field that represents an AIM screen name is "aim_id".
This field maps to:
Example 29. AIM Screen Name
<field var='aim_id'>
<value>psaintandre</value>
</field>
An email address is the value of a mailto: URI at which a person or other entity can be contacted using standard electronic mail protocols.
The Data Forms field that represents longitude is "email".
This field maps to:
Example 30. Email address
<field var='email'>
<value>stpeter@jabber.org</value>
<value>stpeter@gmail.com</value>
</field>
An ICQ number is an address at which a person or other entity can be contacted on the ICQ instant messaging service.
The Data Forms field that represents an ICQ number is "icq_id".
This field maps to:
Example 31. ICQ number
<field var='icq_id'>
<value>70902454</value>
</field>
A Jabber ID is the value of an xmpp: URI at which a person or other entity can be contacted over a Jabber/XMPP network.
The Data Forms field that represents a Jabber ID is "jid".
This field maps to:
Example 32. Jabber ID
<field var='jid'>
<value>stpeter@jabber.org</value>
<value>peter@saint-andre.com</value>
</field>
An MSN address is address at which a person or other entity can be contacted on the MSN instant messaging service.
The Data Forms field that represents an MSN address is "msn_id".
This field maps to:
Example 33. MSN Address
<field var='msn_id'>
<value>petersaintandre@hotmail.com</value>
</field>
A Yahoo ID is address at which a person or other entity can be contacted on the Yahoo! Instant Messenger service.
The Data Forms field that represents a Yahoo ID is "yahoo_id".
This field maps to:
Example 34. Yahoo ID
<field var='yahoo_id'>
<value>psaintandre</value>
</field>
An avatar is an often fanciful representation of a user's desired self-image or persona (e.g., in the context of a game). An avatar is usually not intended to be an accurate picture of the user's actual physical appearance (that is handled by the photo_url and photo_data fields).
An avatar can come in two forms: the avatar data itself, or a URL for a avatar.
The Data Forms field that represents the URL for an avatar is "avatar_url".
This field does not map to data in vCard or any other profile representation format.
Example 35. Avatar URL
<field var='avatar_url'>
<value>http://www.saint-andre.com/images/stpeter_small.jpg</value>
</field>
A biographical URL is the value of an http: URI at which can be found biographical information about a person.
The Data Forms field that represents a biographical URL is "bio".
Example 36. Biographical URL
<field var='bio'>
<value>http://www.jabber.org/people/stpeter.shtml</value>
<value>http://www.saint-andre.com/me/</value>
</field>
A FOAF URL is the value of an http: URI at which can be found a "friend of a friend" (FOAF) file about a person or entity.
The Data Forms field that represents a FOAF URL is "foaf_url".
Example 37. FOAF URL
<field var='foaf_url'>
<value>http://www.saint-andre.com/me/foaf.rdf</value>
</field>
A homepage URL is the value of an http: URI that is the default resource on the World Wide Web for a person or other entity.
The Data Forms field that represents a homepage URL is "homepage".
This field maps to:
Example 38. Homepage URL
<field var='homepage'>
<value>http://www.saint-andre.com/</value>
</field>
A photograph provides a pictorial representation of a person. Sometimes also called a "mugshot".
A photograph can come in two forms: the photo data itself (see below) or a URL for a photograph (e.g., the vCard PHOTO element can represent either, while the FOAF depiction and FOAF img can represent only a URL). The Data Forms field specified here identifies a URL for a photograph, not the data itself.
The Data Forms field that represents the URL for a photograph is "photo_url".
This field maps to:
Example 39. Photo URL
<field var='photo_url'>
<value>http://www.saint-andre.com/images/stpeter.jpg</value>
<value>http://www.saint-andre.com/images/stpeter_hell.jpg</value>
<value>http://www.saint-andre.com/images/stpeter_oscon.jpg</value>
</field>
A publications URL is the value of an http: URI at which can be found the list of a person's published writings.
The Data Forms field that represents a publications URL is "publications".
This field maps to:
Example 40. Publications URL
<field var='publications'>
<value>http://www.saint-andre.com/thoughts/publications.html</value>
</field>
A resume URL is the value of an http: URI at which can be found a person's resume or curriculum vitae.
The Data Forms field that represents a resume URL is "resume".
Example 41. Resume URL
<field var='resume'>
<value>http://www.saint-andre.com/work/</value>
</field>
A status URL is the value of an http: URI that specifies the current status of a person or other entity (e.g., a person's online presence or a server's uptime).
The Data Forms field that represents a homepage URL is "status_url".
Example 42. Status URL
<field var='status_url'>
<value>http://status.jabber.org/</value>
</field>
An organizational URL is the value of an http: URI that specifies the homepage for an organization or employer.
The Data Forms field that represents an organizational URL is "org_url".
This field maps to:
Example 43. Organizational URL
<field var='org_url'>
<value>http://www.jabber.org/</value>
</field>
A weblog URL is the value of an http: URI at which a person or other entity maintains a weblog.
The Data Forms field that represents a weblog URL is "weblog".
This field maps to:
Example 44. Weblog URL
<field var='weblog'>
<value>http://www.saint-andre.com/blog/</value>
</field>
A job title is the official name of a person's position within an organization.
The Data Forms field that represents a job title is "job_title".
This field maps to:
Example 45. Job Title
<field var='job_title'>
<value>Executive Director</value>
</field>
An organizational name is the official name of an organization (company, school, etc.) within which a person works.
The Data Forms field that represents the name of an organization is "org_name".
This field maps to:
Example 46. Organizational Name
<field var='org_name'>
<value>Jabber Software Foundation</value>
</field>
An organizational role describes a person's profession or how a person contributes within an organization.
The Data Forms field that represents an organizational role is "org_role".
This field maps to:
Example 47. Organizational Role
<field var='org_role'>
<value>Patron Saint</value>
<value>Chief Evangelist</value>
<value>Glorified Tech Writer</value>
</field>
An organizational unit is the name of part (subsidiary, department, etc.) of an organization.
The Data Forms field that represents an organizational unit is "org_unit".
This field maps to:
Example 48. Organizational Unit
<field var='org_unit'>
<value>Jabber Council</value>
</field>
These data fields are not necessarily permanent, but do not tend to change very often if at all.
A birth day-of-month is the day of the month in which a person was born. (Note: This data field is not what in English is usually referred to as a person's "birthday", i.e. the year+month+day on which the person was born; the "birthday" is split into three data fields in order to protect personal privacy, since a given individual might want to disclose his or her birth year, birth month, birth day-of-month, or some combination thereof but not all three.)
The Data Forms field that represents a birth day-of-month is "birth_dayofmonth".
When combined with other birthday-related fields, this field maps to:
Example 49. Birth Day-of-Month
<field var='birth_dayofmonth'>
<value>06</value>
</field>
A birth month is the month of the year in which a person was born.
The Data Forms field that represents a birth month is "birth_month".
When combined with other birthday-related fields, this field maps to:
Example 50. Birth Month
<field var='birth_month'>
<value>08</value>
</field>
A birth year is the year in which a person was born.
The Data Forms field that represents a birth year is "birth_year".
When combined with other birthday-related fields, this field maps to:
Example 51. Birth Year
<field var='birth_year'>
<value>1966</value>
</field>
Some people may want to know the color of a person's eyes. The allowable or recommeended values for this field are not specified.
The Data Forms field that represents a person's eye color is "eye_color".
Example 52. Eye Color
<field var='eye_color'>
<value>blue</value>
</field>
Gender is the self-defined gender of a person (this is not limited to "male" and "female", although those are the expected values in most instances). Sometimes also called "sex" or "gender identification".
The Data Forms field that represents a person's gender is "gender".
This field maps to:
Example 53. Gender
<field var='gender'>
<value>male</value>
</field>
Some people may want to know the color of a person's hair (if any). The allowable or recommended values for this field are not specified.
The Data Forms field that represents a person's hair color is "hair_color".
Example 54. Hair Color
<field var='hair_color'>
<value>none</value>
</field>
Some people may want to know a person's height. This SHOULD be expressed in centimeters (which can be transformed into other units if necessary by a client).
The Data Forms field that represents a person's height is "height".
Example 55. Height
<field var='height'>
<value>178</value>
</field>
Yes, it is a sensitive topic, but some people may want to know a person's weight. This SHOULD be expressed in kilograms (which can be transformed into other units if necessary by a client).
The Data Forms field that represents a person's weight is "weight".
Example 56. Weight
<field var='weight'>
<value>75</value>
</field>
An avatar is an often fanciful representation of a user's desired self-image or persona (e.g., in the context of a game). An avatar is usually not intended to be an accurate picture of the user's actual physical appearance (that is handled by the photo_url and photo_data fields).
An avatar can come in two forms: the avatar data itself, or a URL for a avatar.
The Data Forms field that represents avatar data is "avatar_data".
This field does not map to data in vCard or any other profile representation format.
Example 57. Avatar Data
<field var='avatar_data'>
<value>base64-encoded-image-data</value>
</field>
A hobby is a non-work activity that a person enjoys pursuing. Also called an "avocation".
The Data Forms field that represents a hobby is "hobby".
Example 58. Some Hobbies
<field var='hobby'>
<value>guitar</value>
<value>songwriting</value>
<value>blogging</value>
<value>reading</value>
<value>hiking</value>
</field>
An interest a thing that a person cares about or is curious about. It is, generally, less active than a hobby.
The Data Forms field that represents an interest is "interest".
Example 59. Some Interests
<field var='interest'>
<value>history</value>
<value>baseball</value>
<value>economics</value>
</field>
Some people know more than one language, but less than well (e.g., the person may not be able to speak fluently). The definition of "less well" is left to the user.
The value of this field MUST be an abbreviation for a language as specified in RFC 3066 [19].
The Data Forms field that represents a language known less that well is "languages_lesswell".
Example 60. Languages Known Less than Well
<field var='languages_lesswell'>
<value>cz</value>
<value>de</value>
<value>nl</value>
</field>
Everyone knows at least one language well (e.g., they are able to speak or write the language with a fair degree of fluency). Determination of whether someone knows a language "well" or "fluently" is left to the user.
The value of this field MUST be an abbreviation for a language as specified in RFC 3066.
The Data Forms field that represents a language known well is "languages_well".
Example 61. Languages Known Well
<field var='languages_well'>
<value>en</value>
</field>
A Myers-Briggs type indicator is four-letter acronym that is a popular way to characterize different personality types.
The Data Forms field that represents a Myers-Briggs type indicator is "mbti".
This field maps to:
Example 62. Myers-Briggs Type Indicator
<field var='mbti'>
<value>INTP</value>
</field>
A photo provides a pictorial representation of a person. Sometimes also called a "mugshot".
A photo can come in two forms: the photo data itself, or a URL for a photo (e.g., the vCard PHOTO element can represent either, while the FOAF depiction and FOAF img can represent only a URL).
The Data Forms field that represents photo data is "photo_data".
This field maps to:
Example 63. Photo Data
<field var='photo_data'>
<value>base64-encoded-image-data</value>
</field>
A profession is what a person does for his or her primary employment. Also known as a "vocation". The allowable or recommended values for this field are not specified.
The Data Forms field that represents a profession is "profession".
Example 64. A Profession
<field var='profession'>
<value>software engineer</value>
</field>
Many people feel affiliated with a religious belief system.
The Data Forms field that represents a religious affiliation is "religion".
Example 65. Religious Affiliation
<field var='religion'>
<value>none</value>
</field>
A wishlist is a list of items that a person would like to receive as gifts.
The Data Forms field that represents a wishlist is "wishlist".
Example 66. Wishlist
<field var='wishlist'>
<value>A Mini Cooper</value>
</field>
A zodiac sign is that part of the astrological belt under which a person was born; each sign is named after one of the constellations. (Note: we don't have to believe in astrology to support this field.)
The Data Forms field that represents a zodiac sign is "zodiac".
Example 67. Zodiac Sign
<field var='zodiac'>
<value>Leo</value>
</field>
Most people have favorite movies, authors, TV shows, musical artists, foods, games, etc.
The Data Forms field that represents favorite authors is "fav_authors".
This field does not map to data in vCard or any other profile representation format.
Example 68. Favorite Authors
<field var='fav_authors'>
<value>Jacob Bronowski</value>
<value>Friedrich Nietzsche</value>
<value>Carroll Quigley</value>
<value>Yevgeny Zamyatin</value>
</field>
The Data Forms field that represents favorite athletes is "fav_athletes".
This field does not map to data in vCard or any other profile representation format.
Example 69. Favorite Athletes
<field var='fav_athletes'>
<value>Lance Armstrong</value>
<value>Andre Agassiz</value>
</field>
The Data Forms field that represents favorite charities is "fav_charities".
This field does not map to data in vCard or any other profile representation format.
Example 70. Favorite Charities
<field var='fav_charities'>
<value>Amnesty International</value>
<value>Institute for Justice</value>
</field>
The Data Forms field that represents favorite foods is "fav_foods".
This field does not map to data in vCard or any other profile representation format.
Example 71. Favorite Foods
<field var='fav_foods'>
<value>Thai</value>
<value>Mexican</value>
<value>Italian</value>
</field>
The Data Forms field that represents favorite games is "fav_games".
This field does not map to data in vCard or any other profile representation format.
Example 72. Favorite Games
<field var='fav_games'>
<value>chess</value>
</field>
The Data Forms field that represents favorite movies is "fav_movies".
This field does not map to data in vCard or any other profile representation format.
Example 73. Favorite Movies
<field var='fav_movies'>
<value>In Search of Bobby Fischer</value>
<value>Strictly Ballroom</value>
<value>The Truth About Cats and Dogs</value>
<value>Ray</value>
</field>
The Data Forms field that represents favorite music is "fav_music".
This field does not map to data in vCard or any other profile representation format.
Example 74. Favorite Music
<field var='fav_music'>
<value>J.S. Bach</value>
<value>Duke Ellington</value>
<value>Mellow Candle</value>
<value>Yes</value>
</field>
A quote is a phrase or saying that a person identifies with in some way. According to the 2004 Pew Internet survey on instant messaging, quotes represent the most popular item to include in online profiles on major consumer-oriented instant messaging services.
The Data Forms field that represents favorite quotes is "fav_quotes".
This field does not map to data in vCard or any other profile representation format.
Example 75. Favorite Quotes
<field var='fav_quotes'>
<value>I am large, I contain multitudes.</value>
<value>"Think like a man of action, act like a man of thought." --Henri Bergson</value>
<value>One crowded hour of glorious life is worth an age without a name.</value>
</field>
The Data Forms field that represents favorite sports teams is "fav_teams".
This field does not map to data in vCard or any other profile representation format.
Example 76. Favorite Sports Teams
<field var='fav_teams'>
<value>New York Yankees</value>
<value>Colorado Rockies</value>
</field>
The Data Forms field that represents favorite TV shows is "fav_tv".
This field does not map to data in vCard or any other profile representation format.
Example 77. Favorite TV Shows
<field var='fav_tv'>
<value>Antiques Road Show</value>
</field>
Some people move around a lot.
The Data Forms field that represents places lived is "places_lived".
This field does not map to data in vCard or any other profile representation format.
Example 78. Places Lived
<field var='places_lived'>
<value>Denver, Colorado, USA</value>
<value>New Hope, Pennsylvania, USA</value>
<value>Maplewood, New Jersey, USA</value>
<value>Atlanta, Georgia, USA</value>
<value>Fairfax, Virginia, USA</value>
<value>Ceske Budejovice, Czech Republic</value>
<value>New York City</value>
<value>Readfield, Maine, USA</value>
<value>Sea Cliff, NY, USA</value>
</field>
The Data Forms field that represents schools attended is "schools".
This field does not map to data in vCard or any other profile representation format.
Example 79. Schools Attended
<field var='schools'>
<value>Columbia University</value>
<value>American Renaissance School</value>
<value>Maranacook Community School</value>
</field>
Profile data can be personally significant and even security critical. Due care should be taken in determining who shall have access to such information. However, this proposal merely defines the data formats for profile data; mechanisms for controlling access to such data will be defined in a separate proposal.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [20].
To follow.
1. JEP-0054: vcard-temp <http://www.jabber.org/jeps/jep-0054.html>.
2. RFC 2426: vCard MIME Directory Profile <http://www.ietf.org/rfc/rfc2426.txt>.
3. For links to the experimental XML representation of vCard, see JEP-0054.
4. See <http://xml.coverpages.org/xnal.html>.
5. OASIS is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. For further information, see <http://www.oasis-open.org/>.
6. Friend of a Friend (FOAF) <http://xmlns.com/foaf/0.1/>.
7. JEP-0004: Data Forms <http://www.jabber.org/jeps/jep-0004.html>.
8. JEP-0068: Field Data Standardization for Data Forms <http://www.jabber.org/jeps/jep-0068.html>.
9. The extensibility requirement is critically important, because it would be best if the protocol specified herein could be used to represent data used within specialized communities. Examples of such communities include dating services, multiplayer gaming networks, IM services provided by portals and ISPs, and expert-location systems within large corporations. While such communities might use part or all of some common set of data fields (such as fields that map to familiar vCard elements), each community might also want to represent quite disparate kinds of information (dating criteria, favorite games, contact preferences, areas of expertise, and the like). Furthermore, data might be used to profile network actors that are not persons (e.g., bots, services, and other software agents). Therefore, the ideal proposal will provide an extensible framework for representing profile data and will not limit itself to representing the relatively small set of data fields covered by the vCard format.
10. JEP-0080: User Geolocation <http://www.jabber.org/jeps/jep-0080.html>.
11. JEP-0112: User Physical Location <http://www.jabber.org/jeps/jep-0112.html>.
12. Resource Description Framework (RDF) <http://www.w3.org/RDF/>.
13. JEP-0134: Protocol Design Guidelines <http://www.jabber.org/jeps/jep-0134.html>.
14. JEP-0120: Infobits <http://www.jabber.org/jeps/jep-0120.html>.
15. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
16. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.
17. JEP-0112: User Physical Location <http://www.jabber.org/jeps/jep-0112.html>.
18. JEP-0080: User Geolocation <http://www.jabber.org/jeps/jep-0080.html>.
19. RFC 3066: Tags for the Identification of Languages <http://www.ietf.org/rfc/rfc3066.txt>.
20. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
END