<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>Updated to reflect stable PEP protocol; added OpenID field; specified XML schema; changed namespace to conform to XMPP Registrar procedures.</p></remark>
<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>
<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>
<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 'urn:xmpp:tmp:profile' namespace &NSNOTE;.</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; this 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 represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' &NSNOTE;, 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 'urn:xmpp:tmp: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 'urn:xmpp:tmp: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'><