<abstract>This document specifies how to represent and manage profile data about IM users and other XMPP entities using the XMPP Data Forms extension.</abstract>
<remark><p>Defined data management methods using IQ and the PEP subset of pubsub; added various data fields from LDAP; changed namespace from profiledata to profile.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2005-11-11</date>
<initials>psa</initials>
<remark><p>Added postaladdress, fav_chatrooms, alt_contact, teams; added various security-related fields.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2005-07-25</date>
<initials>psa</initials>
<remark><p>Added mappings to common LDAP schemas.</p></remark>
<remark><p>Defined how to handle vCard types such as home vs. work addresses.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2005-04-07</date>
<initials>psa</initials>
<remark><p>Reworked field standardization; added support for telephony addresses, electronic addresses, and organizational data.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2005-03-11</date>
<initials>psa</initials>
<remark><p>Added open issues.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2005-01-06</date>
<initials>psa</initials>
<remark><p>Explained requirements and design decisions in more detail, especially with regard to extensibility; split photo into two elements (data and URL).</p></remark>
<p>It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (<cite>XEP-0054</cite>) has outlived its usefulness. There are several reasons for this conclusion:</p>
<li>vCard (even in its XML representation <note>For links to the experimental XML representation of vCard, see <cite>XEP-0054</cite>.</note>) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.</li>
<p>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 <cite>Extensible Name and Address Language</cite><note>See <<linkurl='http://xml.coverpages.org/xnal.html'>http://xml.coverpages.org/xnal.html</link>>.</note> developed by &OASIS;) while less-formal ontologies are being used to represent other parts of the problem space (e.g., &foaf;). The relevant protocols are in flux and it is unclear when (or even if) stability will emerge.</p>
<p>Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond XEP-0054, this document specifies methods for the representation of profile data in terms of the &xep0004; protocol (further qualified using the standardization concepts specified in &xep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &xep0060; semantics (specifically the simplified subset of those semantics specified in &xep0163;). The rationale behind these design decisions is provided below.</p>
<li>Specify how to represent profile data in an XMPP-friendly manner for communication over the wire.</li>
<li>Ensure that the protocol is extensible (e.g., not limited to existing vCard fields).
<note>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.</note>
</li>
<li>Where possible, map profile data fields to existing vCard fields and other common formats.</li>
</ol>
</section1>
<section1topic='Concepts and Approach'anchor='approach'>
<p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://jabber.org/protocol/profile' namespace.</p>
<p>A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in <cite>XEP-0163</cite> to implement this model.</p>
<p>As with data management, there are several possible approaches to representing profile data for communication over XMPP networks, including the following:</p>
<p>Such data formats have the advantage of being human-readable. However:</p>
<ol>
<li>They are not easily extensible: developers of specialized community services would need to write their own structured data formats, even to add one new field.</li>
<li>They are not easy to map to backend data storage facilities (e.g., database administrators generally would prefer to have generic database schemas and re-usable code for parsing the XML wire protocol into the database fields).</li>
<li>They would require specialized interface handlers for each data structure, rather than a generic interface handler.</li>
</ol>
</li>
<li>
<p><strong>A format represented by means of &w3rdf;.</strong></p>
<p>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:</p>
<li>RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML, which is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).</li>
<li>RDF requires a specialized parser rather than the normal XML parser that comes standard with all XMPP implementations.</li>
<li>As long as it is possible to define a consistent mapping of profile data to RDF representations, it should be straightforward to convert the XMPP data formats into those RDF representations if desired (e.g., to output a FOAF file).</li>
<li>Data forms have a generic schema that is easy to map to common data storage mechanisms (usually databases).</li>
<li>Data forms provide a consistent abstraction layer for XMPP applications, thus shielding them from changes in the profile data formats being defined by other Internet projects and standards development organizations.</li>
<li>The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).</li>
<p>Therefore, this proposal specifies that profile data shall be scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). 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 <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
<p>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:</p>
<p>By specifying that all fields are scoped by a FORM_TYPE of 'http://jabber.org/protocol/profile', 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/profile' 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.</p>
<p>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 (<cite>RFC 2426</cite>) 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.</p>
<p>In order to address most (if not all) of the pieces of information described in existing profile specifications, this document 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 <linkurl='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
<section1topic='Producer Use Cases'anchor='producer'>
<section2topic='Publishing a Full Profile'anchor='producer-full'>
<p>In order to publish a full profile, an entity sends an IQ-set to its server with a child element of <profile/> containing the full profile information.</p>
<examplecaption='Entity publishes full profile'><![CDATA[
<p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://jabber.org/protocol/profile" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>XEP-0163</cite>.</p>
<p>If the field(s) published are "public", the publisher SHOULD then repost the full profile as described above in order to keep the full profile in sync.</p>
<p>Note: The account owner MAY decide to effectively maintain two profile subsets: public profile fields (posted via the "full profile" protocol) and restricted profile fields (published only via PEP). If so, the client MUST keep track of which fields are in the public profile subset and which fields are in the restricted profile subset, and MUST NOT update the full profile if the account owner has updated a field in the restricted profile set.</p>
</section2>
</section1>
<section1topic='Consumer Use Cases'anchor='consumer'>
<p>If an entity can provide profile data directly using the standalone 'http://jabber.org/protocol/profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:</p>
<p>Note: Because the foregoing request was sent to the bare JID <hamlet@denmark.lit>, the response is provided by the <denmark.lit> server on behalf of the registered account. The answer indicates that the server can also provide profile data on behalf of the registered account.</p>
</section2>
<section2topic='Requesting Full Profile'anchor='consumer-full'>
<p>In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty <profile/> element qualified by the 'http://jabber.org/protocol/profile' namespace. In this example, the request is sent to a server:</p>
<examplecaption='A request for profile data'><![CDATA[
<p>If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a whitelist of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:</p>
<examplecaption='Server returns service unavailable error'><![CDATA[
<p>In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID (&BAREJID;) and specify a node of "http://jabber.org/protocol/profile":</p>
<examplecaption='Entity subscribes to profile node'><![CDATA[
<p>It is the responsibility of the receiving entity to correctly process the notification and update the contact's profile information accordingly.</p>
<p>The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the XMPP Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;) <note>This specification does not require that profile data fields mapped to LDAP fields must adhere to the X.500 data types that are re-used by LDAP. However, implementations MAY enforce those data types if desired.</note>, and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.</p>
<p>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".</p>
<p>The Data Forms field that represents a display name is "display_name".</p>
<p>A familiar name is a shortened or modified form of someone's given name that may be used in somewhat informal contexts or that is preferred by the person (e.g., "Chuck" instead of "Charles").</p>
<p>The Data Forms field that represents a familiar name is "familiar_name".</p>
<p>This field maps to:</p>
<ul>
<li>eduPersonNickname</li>
</ul>
<examplecaption='Familiar Name'><![CDATA[
<fieldvar='familiar_name'>
<value>Pete</value>
</field>
]]></example>
</section3>
<section3topic='Family Name'anchor='family_name'>
<p>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".</p>
<p>The Data Forms field that represents a family name is "family_name".</p>
<p>This field maps to:</p>
<ul>
<li>vCard FAMILY</li>
<li>LDAP sn</li>
<li>xNAL LastName</li>
<li>FOAF family_name</li>
<li>FOAF surname</li>
</ul>
<examplecaption='Family Name'><![CDATA[
<fieldvar='family_name'>
<value>Saint-Andre</value>
</field>
]]></example>
</section3>
<section3topic='Given Name'anchor='given_name'>
<p>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".</p>
<p>The Data Forms field that represents a given name is "given_name".</p>
<p>This field maps to:</p>
<ul>
<li>vCard GIVEN</li>
<li>LDAP givenName</li>
<li>xNAL FirstName</li>
<li>FOAF first_name</li>
<li>FOAF givenname</li>
</ul>
<examplecaption='Given Name'><![CDATA[
<fieldvar='given_name'>
<value>J.</value>
</field>
]]></example>
</section3>
<section3topic='Middle Name'anchor='middle_name'>
<p>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".</p>
<p>The Data Forms field that represents a middle name is "middle_name".</p>
<p>This field maps to:</p>
<ul>
<li>vCard MIDDLE</li>
<li>xNAL MiddleName</li>
</ul>
<examplecaption='Middle Name'><![CDATA[
<fieldvar='middle_name'>
<value>Peter</value>
</field>
]]></example>
</section3>
<section3topic='Name Prefix'anchor='name_prefix'>
<p>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".</p>
<p>The Data Forms field that represents a name prefix is "name_prefix".</p>
<p>This field maps to:</p>
<ul>
<li>vCard PREFIX</li>
<li>xNAL Title</li>
<li>FOAF title</li>
</ul>
<examplecaption='Name Prefix'><![CDATA[
<fieldvar='name_prefix'>
<value>Mr</value>
</field>
]]></example>
</section3>
<section3topic='Name Suffix'anchor='name_suffix'>
<p>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).</p>
<p>The Data Forms field that represents a name suffix is "name_suffix".</p>
<p>This field maps to:</p>
<ul>
<li>vCard SUFFIX</li>
<li>xNAL GeneralSuffix</li>
</ul>
<examplecaption='Name Suffix'><![CDATA[
<fieldvar='name_suffix'>
<value>Esq</value>
</field>
]]></example>
</section3>
<section3topic='Nickname'anchor='nickname'>
<p>A nickname is a global, memorable (but not unique) friendly or informal name chosen by the owner of a JID. The purpose of a nickname is to associate a distinctive mapping between the person's unique JID and non-unique nickname. A nickname is normally used in online contexts (e.g., in chatrooms) that are less formal than real life (where a person's <linkurl='#familiar_name'>Familiar Name</link> would be more appropriate). Sometimes also called an "alias". A person SHOULD specify only one nickname (i.e., not more than one).</p>
<p>The Data Forms field that represents a nickname is "nickname".</p>
<p>This field maps to:</p>
<ul>
<li>vCard NICKNAME</li>
<li>xNAL Alias</li>
<li>FOAF nick</li>
</ul>
<examplecaption='Nickname'><![CDATA[
<fieldvar='nickname'>
<value>stpeter</value>
</field>
]]></example>
</section3>
<section3topic='Patronymic'anchor='patronymic'>
<p>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".</p>
<p>The Data Forms field that represents a patronymic is "patronymic".</p>
<examplecaption='A Patronymic'><![CDATA[
<fieldvar='patronymic'>
<value>Ivanovich</value>
</field>
]]></example>
</section3>
</section2>
<section2topic='Physical Address Data Aspects'anchor='fields-physicaladdress'>
<p>A country is the sovereign nation in which a person is located. Sometimes also called a "nation".</p>
<p>The Data Forms fields that represent a country are "country", "home_country", and "work_country" for generic addresses, home addresses, and work addresses respectively.</p>
<p>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".</p>
<p>The Data Forms field that represents a region is "region".</p>
<p>The Data Forms fields that represent a region are "home_region" and "work_region" for home addresses and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard REGION, optionally supplemented with the "HOME" or "WORK" type</li>
<p>A locality is a defined place within the region in which a person is located. Sometimes also called a "city", "town", or "village".</p>
<p>The Data Forms fields that represent a locality are "locality", "home_locality", and "work_locality" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard LOCALITY, optionally supplemented with the "HOME" or "WORK" type</li>
<p>An area is a sub-division within the locality in which a person is located. Sometimes also called a "neighborhood", "suburb", "district", or "section".</p>
<p>The Data Forms fields that represent a area are "area", "home_area", and "work_area" for generic addresses, home addresses, and work addresses respectively.</p>
<p>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".</p>
<p>The Data Forms fields that represent a street are "street", "home_street", and "work_street" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard STREET, optionally supplemented with the "HOME" or "WORK" type</li>
<p>A building is the name for a specific structure on a street or within an area.</p>
<p>The Data Forms fields that represent a building are "building", "home_building", and "work_building" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<p>A floor is a named or numbered floor or level within a building. Sometimes also called a "level", "block", or "suite".</p>
<p>The Data Forms fields that represent a floor are "floor", "home_floor", and "work_floor" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<p>A room is a named or numbered subdivision of a floor. Sometimes also called a "unit" or "apartment".</p>
<p>The Data Forms fields that represent a room are "room", "home_room", and "work_room" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<p>A postal box is a set of numeric or alphanumeric characters used to identify a mailbox at a postal delivery center.</p>
<p>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.</p>
<p>This field maps to:</p>
<ul>
<li>vCard POBOX, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP postOfficeBox</li>
</ul>
<examplecaption='Postal Box'><![CDATA[
<fieldvar='postalbox'>
<value>1641</value>
</field>
]]></example>
</section3>
<section3topic='Postal Code'anchor='postalcode'>
<p>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.).</p>
<p>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.</p>
<p>This field maps to:</p>
<ul>
<li>vCard PCODE, optionally supplemented with the "HOME" or "WORK" type</li>
<p>A postal address is a free-form mailing address, which may be easier to enter (or, in some cultural contexts, more appropriate) than the atomic address parts such as street, floor, etc.</p>
<p>The Data Forms fields that represent a postal address are "postaladdress", "home_postaladdress", and "work_postaladdress" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>LDAP postalAddress, homePostalAddress</li>
</ul>
<examplecaption='Postal Address'><![CDATA[
<fieldvar='work_postaladdress'>
<value>1899 Wynkoop Street</value>
<value>Suite 600</value>
<value>Denver, CO 80202</value>
<value>USA</value>
</field>
]]></example>
</section3>
</section2>
<section2topic='Geolocation Data Aspects'anchor='fields-geoloc'>
<p>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.</p>
<p>The Data Forms field that represents altitude is "alt".</p>
<p>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.</p>
<p>The Data Forms field that represents latitude is "lat".</p>
<p>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.</p>
<p>The Data Forms field that represents longitude is "lon".</p>
<section2topic='Telephony Address Data Aspects'anchor='fields-tel'>
<section3topic='Fax Number'anchor='fax'>
<p>A fax number is a number for a machine that handles fascimile transmissions.</p>
<p>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.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL (+ "FAX" modifier), optionally supplemented with the "HOME" or "WORK" type</li>
<p>A landline telephone number is a number for a traditional "PSTN" or "POTS" telephone.</p>
<p>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.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL, optionally supplemented with the "HOME" or "WORK" type</li>
<p>A mobile telephone number is a number for a mobile phone or cell phone on a wireless network.</p>
<p>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.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL (+ "CELL" modifier), optionally supplemented with the "HOME" or "WORK" type</li>
<p>A pager number is a number for a dedicated alphanumeric paging device.</p>
<p>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.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL (+ "PAGER" modifier), optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP pager</li>
</ul>
<examplecaption='Pager Number'><![CDATA[
<fieldvar='pager'>
<value>303-555-1212</value>
</field>
]]></example>
</section3>
<section3topic='SIP Address'anchor='sip_address'>
<p>A SIP address is a sip: or sips: URI at which a person can be contacted for Voice over Internet Protocol (VoIP) communications.</p>
<p>The Data Forms field that represents a SIP address is "sip_address".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<p>A videophone address is an address used for for H.323 video conferencing systems.</p>
<p>The Data Forms field that represents a videophone address is "video_phone".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<examplecaption='Videophone Address'><![CDATA[
<fieldvar='video_phone'>
<value>foo</value>
</field>
]]></example>
</section3>
</section2>
<section2topic='Electronic Address Data Aspects'anchor='fields-net'>
<section3topic='AIM Screen Name'anchor='aim_id'>
<p>An AIM screen name is an address at which a person or other entity can be contacted on the AOL Instant Messenger service.</p>
<p>The Data Forms field that represents an AIM screen name is "aim_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF aimChatID</li>
</ul>
<examplecaption='AIM Screen Name'><![CDATA[
<fieldvar='aim_id'>
<value>psaintandre</value>
</field>
]]></example>
</section3>
<section3topic='Email Address'anchor='email'>
<p>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.</p>
<p>The Data Forms field that represents longitude is "email".</p>
<p>This field maps to:</p>
<ul>
<li>vCard EMAIL</li>
<li>LDAP mail</li>
</ul>
<examplecaption='Email address'><![CDATA[
<fieldvar='email'>
<value>stpeter@jabber.org</value>
<value>stpeter@gmail.com</value>
</field>
]]></example>
</section3>
<section3topic='ICQ Number'anchor='icq_id'>
<p>An ICQ number is an address at which a person or other entity can be contacted on the ICQ instant messaging service.</p>
<p>The Data Forms field that represents an ICQ number is "icq_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF icqChatID</li>
</ul>
<examplecaption='ICQ number'><![CDATA[
<fieldvar='icq_id'>
<value>70902454</value>
</field>
]]></example>
</section3>
<section3topic='Jabber ID'anchor='jid'>
<p>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.</p>
<p>The Data Forms field that represents a Jabber ID is "jid".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF jabberID</li>
</ul>
<examplecaption='Jabber ID'><![CDATA[
<fieldvar='jid'>
<value>stpeter@jabber.org</value>
<value>peter@saint-andre.com</value>
</field>
]]></example>
</section3>
<section3topic='MSN Address'anchor='msn_id'>
<p>An MSN address is address at which a person or other entity can be contacted on the MSN instant messaging service.</p>
<p>The Data Forms field that represents an MSN address is "msn_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF msnChatID</li>
</ul>
<examplecaption='MSN Address'><![CDATA[
<fieldvar='msn_id'>
<value>petersaintandre@hotmail.com</value>
</field>
]]></example>
</section3>
<section3topic='Yahoo ID'anchor='yahoo_id'>
<p>A Yahoo ID is address at which a person or other entity can be contacted on the Yahoo! Instant Messenger service.</p>
<p>The Data Forms field that represents a Yahoo ID is "yahoo_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF yahooChatID</li>
</ul>
<examplecaption='Yahoo ID'><![CDATA[
<fieldvar='yahoo_id'>
<value>psaintandre</value>
</field>
]]></example>
</section3>
</section2>
<section2topic='World Wide Web Resource Aspects'anchor='fields-www'>
<section3topic='Avatar URL'anchor='avatar_url'>
<p>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).</p>
<p>An avatar can come in two forms: the avatar data itself, or a URL for a avatar.</p>
<p>The Data Forms field that represents the URL for an avatar is "avatar_url".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<p>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.</p>
<p>The Data Forms field that represents a homepage URL is "homepage".</p>
<p>This field maps to:</p>
<ul>
<li>LDAP labelledURI</li>
<li>FOAF homepage</li>
</ul>
<examplecaption='Homepage URL'><![CDATA[
<fieldvar='homepage'>
<value>http://www.saint-andre.com/</value>
</field>
]]></example>
</section3>
<section3topic='Photo URL'anchor='photo_url'>
<p>A photograph provides a pictorial representation of a person. Sometimes also called a "mugshot".</p>
<p>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.</p>
<p>The Data Forms field that represents the URL for a photograph is "photo_url".</p>
<p>A resume URL is the value of an http: URI at which can be found a person's resume or curriculum vitae.</p>
<p>The Data Forms field that represents a resume URL is "resume".</p>
<examplecaption='Resume URL'><![CDATA[
<fieldvar='resume'>
<value>http://www.saint-andre.com/work/</value>
</field>
]]></example>
</section3>
<section3topic='Status URL'anchor='status_url'>
<p>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).</p>
<p>The Data Forms field that represents a homepage URL is "status_url".</p>
<p>It may be appropriate to list others who can be contacted if the individual is not available.</p>
<examplecaption='Alternative Contact'><![CDATA[
<fieldvar='alt_contact'>
<value>xmpp:peter@jabber.org</value>
</field>
]]></example>
</section3>
<section3topic='Affiliation'anchor='affiliation'>
<p>An affiliation is a person's relationship to an institution, such as student, faculty, intern, fellow. An affiliation is in general less rigid than an <linkurl='#employee_type'>Employee Type</link>, which may not be relevant in noncommercial organizations.</p>
<p>The Data Forms field that represents an organizational affiliation is "affiliation".</p>
<p>This field maps to:</p>
<ul>
<li>LDAP eduPersonAffiliation</li>
</ul>
<examplecaption='Affiliation'><![CDATA[
<fieldvar='affiliation'>
<value>faculty</value>
</field>
]]></example>
</section3>
<section3topic='Assistant'anchor='assistant'>
<p>In some organizations, a person may be assisted by another individual.</p>
<p>The Data Forms field that represents an assistant is "assistant".</p>
<p>An affiliation is a person's relationship to an institution, such as student, faculty, intern, fellow. (An affiliation is in general less rigid than an <linkurl='#employee_type'>Employee Type</link>, which may not be relevant in noncommercial organizations.) Since a person may be affiliated with multiple organizations (e.g., multiple research institutions), the primary affiliation is used to describe a person's affiliation to their primary organization.</p>
<p>The Data Forms field that represents a primary organizational affiliation is "primary_affiliation".</p>
<p>An organizational name is the official name of an organization (company, school, etc.) within which a person works. Since a person may be affiliated with multiple organizations (e.g., multiple research institutions), the primary organizational name is used to differentiate the main organization with which a person is affiliated.</p>
<p>The Data Forms field that represents the name of a primary organization is "primary_org_name".</p>
<p>An organizational role describes a person's profession or how a person contributes within an organization. Since a person may be affiliated with multiple organizations (e.g., multiple research institutions), the primary organizational role is used to differentiate the person's role at their primary organization.</p>
<p>The Data Forms field that represents an organizational role is "primary_org_role".</p>
<p>An organizational unit is the name of part (subsidiary, department, etc.) of an organization Since a person may be affiliated with multiple organizational units (e.g., multiple schools within a university), the primary organizational name is used to differentiate the main organization with which a person is affiliated.</p>
<p>The Data Forms field that represents an organizational unit is "primary_org_unit".</p>
<p>A birth day-of-month is the day of the month in which a person was born. (Note: This data field is <em>not</em> 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.)</p>
<p>The Data Forms field that represents a birth day-of-month is "birth_dayofmonth".</p>
<p>When combined with other birthday-related fields, this field maps to:</p>
<ul>
<li>vCard BDAY</li>
</ul>
<examplecaption='Birth Day-of-Month'><![CDATA[
<fieldvar='birth_dayofmonth'>
<value>06</value>
</field>
]]></example>
</section3>
<section3topic='Birth Month'anchor='birth_month'>
<p>A birth month is the month of the year in which a person was born.</p>
<p>The Data Forms field that represents a birth month is "birth_month".</p>
<p>When combined with other birthday-related fields, this field maps to:</p>
<ul>
<li>vCard BDAY</li>
</ul>
<examplecaption='Birth Month'><![CDATA[
<fieldvar='birth_month'>
<value>08</value>
</field>
]]></example>
</section3>
<section3topic='Birth Year'anchor='birth_year'>
<p>A birth year is the year in which a person was born.</p>
<p>The Data Forms field that represents a birth year is "birth_year".</p>
<p>When combined with other birthday-related fields, this field maps to:</p>
<ul>
<li>vCard BDAY</li>
</ul>
<examplecaption='Birth Year'><![CDATA[
<fieldvar='birth_year'>
<value>1966</value>
</field>
]]></example>
</section3>
<section3topic='Description'anchor='description'>
<p>It can be helpful to provide a natural-language description of a person.</p>
<p>The Data Forms field that represents a description of a person is "description".</p>
<p>This field maps to:</p>
<ul>
<li>LDAP description</li>
</ul>
<examplecaption='Description'><![CDATA[
<fieldvar='description'>
<value>I'm a Jabber fanatic.</value>
</field>
]]></example>
</section3>
<section3topic='Eye Color'anchor='eye_color'>
<p>Some people may want to know the color of a person's eyes. The allowable or recommended values for this field are not specified.</p>
<p>The Data Forms field that represents a person's eye color is "eye_color".</p>
<examplecaption='Eye Color'><![CDATA[
<fieldvar='eye_color'>
<value>blue</value>
</field>
]]></example>
</section3>
<section3topic='Gender'anchor='gender'>
<p>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".</p>
<p>The Data Forms field that represents a person's gender is "gender".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF gender</li>
</ul>
<examplecaption='Gender'><![CDATA[
<fieldvar='gender'>
<value>male</value>
</field>
]]></example>
</section3>
<section3topic='Hair Color'anchor='hair_color'>
<p>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.</p>
<p>The Data Forms field that represents a person's hair color is "hair_color".</p>
<examplecaption='Hair Color'><![CDATA[
<fieldvar='hair_color'>
<value>none</value>
</field>
]]></example>
</section3>
<section3topic='Height'anchor='height'>
<p>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).</p>
<p>The Data Forms field that represents a person's height is "height".</p>
<examplecaption='Height'><![CDATA[
<fieldvar='height'>
<value>178</value>
</field>
]]></example>
</section3>
<section3topic='Weight'anchor='weight'>
<p>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).</p>
<p>The Data Forms field that represents a person's weight is "weight".</p>
<examplecaption='Weight'><![CDATA[
<fieldvar='weight'>
<value>75</value>
</field>
]]></example>
</section3>
</section2>
<section2topic='Extended Personal Data Aspects'anchor='fields-extended'>
<section3topic='Areas of Expertise'anchor='expertise'>
<p>An area of expertise is a subject in which a person has a great deal of knowledge.</p>
<p>The Data Forms field that represents an area of expertise is "expertise".</p>
<examplecaption='Areas of Expertise'><![CDATA[
<fieldvar='expertise'>
<value>Jabber</value>
<value>XMPP</value>
</field>
]]></example>
</section3>
<section3topic='Avatar Data'anchor='avatar_data'>
<p>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).</p>
<p>An avatar can come in two forms: the avatar data itself, or a URL for a avatar.</p>
<p>The Data Forms field that represents avatar data is "avatar_data".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<examplecaption='Avatar Data'><![CDATA[
<fieldvar='avatar_data'>
<value>base64-encoded-image-data</value>
</field>
]]></example>
</section3>
<section3topic='Clubs'anchor='clubs'>
<p>Some people are members of clubs or other voluntary organizations.</p>
<p>The Data Forms field that represents club memberships is "clubs".</p>
<p>Some people have dietary preferences (vegan, vegetarian, kosher, peanut allergy, no shellfish, etc.).</p>
<p>The Data Forms field that represents dietary preferences is "dietary_preferences".</p>
<examplecaption='Dietary Preferences'><![CDATA[
<fieldvar='dietary_preferences'>
<value>none</value>
</field>
]]></example>
</section3>
<section3topic='Hobbies'anchor='hobby'>
<p>A hobby is a non-work activity that a person enjoys pursuing. Also called an "avocation".</p>
<p>The Data Forms field that represents a hobby is "hobby".</p>
<examplecaption='Some Hobbies'><![CDATA[
<fieldvar='hobby'>
<value>guitar</value>
<value>songwriting</value>
<value>blogging</value>
<value>reading</value>
<value>hiking</value>
</field>
]]></example>
</section3>
<section3topic='Interests'anchor='interest'>
<p>An interest a thing that a person cares about or is curious about. It is, generally, less active than a hobby.</p>
<p>The Data Forms field that represents an interest is "interest".</p>
<examplecaption='Some Interests'><![CDATA[
<fieldvar='interest'>
<value>history</value>
<value>baseball</value>
<value>economics</value>
</field>
]]></example>
</section3>
<section3topic='Languages Known Less Well'anchor='languages_lesswell'>
<p>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.</p>
<p>The value of this field MUST be an abbreviation for a language as specified in &rfc3066;.</p>
<p>The Data Forms field that represents a language known less that well is "languages_lesswell".</p>
<examplecaption='Languages Known Less than Well'><![CDATA[
<fieldvar='languages_lesswell'>
<value>cz</value>
<value>de</value>
<value>nl</value>
</field>
]]></example>
</section3>
<section3topic='Languages Known Well'anchor='languages_well'>
<p>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.</p>
<p>The value of this field MUST be an abbreviation for a language as specified in <cite>RFC 3066</cite>.</p>
<p>The Data Forms field that represents a language known well is "languages_well".</p>
<p>Human beings often get married, sometimes get divorced, become widowed, etc.</p>
<p>The Data Forms field that represents whether a person's marital status is "marital_status".</p>
<examplecaption='Marital Status'><![CDATA[
<fieldvar='marital_status'>
<value>married</value>
</field>
]]></example>
</section3>
<section3topic='Myers-Briggs Type Indicator'anchor='mbti'>
<p>A Myers-Briggs type indicator is four-letter acronym that is a popular way to characterize different personality types.</p>
<p>The Data Forms field that represents a Myers-Briggs type indicator is "mbti".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF myersBriggs</li>
</ul>
<examplecaption='Myers-Briggs Type Indicator'><![CDATA[
<fieldvar='mbti'>
<value>INTP</value>
</field>
]]></example>
</section3>
<section3topic='Photo Data'anchor='photo_data'>
<p>A photo provides a pictorial representation of a person. Sometimes also called a "mugshot".</p>
<p>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).</p>
<p>The Data Forms field that represents photo data is "photo_data".</p>
<p>This field maps to:</p>
<ul>
<li>vCard PHOTO</li>
<li>LDAP jpegPhoto</li>
</ul>
<examplecaption='Photo Data'><![CDATA[
<fieldvar='photo_data'>
<value>base64-encoded-image-data</value>
</field>
]]></example>
</section3>
<section3topic='Profession'anchor='profession'>
<p>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.</p>
<p>The Data Forms field that represents a profession is "profession".</p>
<p>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.</p>
<p>The Data Forms field that represents favorite quotes is "fav_quotes".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<examplecaption='Favorite Quotes'><