XEP-0154: User Profile

Abstract:This document specifies how to represent and manage profile data about IM users and other XMPP entities using the XMPP Data Forms extension.
Author:Peter Saint-Andre
Copyright:© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Deferred
Type:Standards Track
Version:0.6
Last Updated:2008-04-18

WARNING: Consideration of this document has been Deferred by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended.


Table of Contents


1. Introduction
2. Requirements
3. Concepts and Approach
    3.1. Data Management
    3.2. Data Representation
4. Producer Use Cases
    4.1. Publishing a Full Profile
    4.2. Updating One or More Profile Fields
5. Consumer Use Cases
    5.1. Discovering Support
    5.2. Requesting Full Profile
    5.3. Receiving Profile Updates
6. Data Representation
    6.1. Name Data Aspects
       6.1.1. Display Name
       6.1.2. Familiar Name
       6.1.3. Family Name
       6.1.4. Given Name
       6.1.5. Middle Name
       6.1.6. Name Prefix
       6.1.7. Name Suffix
       6.1.8. Nickname
       6.1.9. Patronymic
    6.2. Physical Address Data Aspects
       6.2.1. Country
       6.2.2. Region
       6.2.3. Locality
       6.2.4. Area
       6.2.5. Street
       6.2.6. Building
       6.2.7. Floor
       6.2.8. Room
       6.2.9. Postal Box
       6.2.10. Postal Code
       6.2.11. Postal Address
    6.3. Geolocation Data Aspects
       6.3.1. Altitude
       6.3.2. Latitude
       6.3.3. Longitude
    6.4. Telephony Address Data Aspects
       6.4.1. Fax Number
       6.4.2. Landline Telephone Number
       6.4.3. Mobile Telephone Number
       6.4.4. Pager Number
       6.4.5. SIP Address
       6.4.6. Skype Address
       6.4.7. Videophone Address
    6.5. Electronic Address Data Aspects
       6.5.1. AIM Screen Name
       6.5.2. Email Address
       6.5.3. ICQ Number
       6.5.4. Jabber ID
       6.5.5. MSN Address
       6.5.6. Yahoo ID
    6.6. World Wide Web Resource Aspects
       6.6.1. Avatar URL
       6.6.2. Biographical URL
       6.6.3. FOAF URL
       6.6.4. Homepage URL
       6.6.5. OpenID
       6.6.6. Photo URL
       6.6.7. Publications URL
       6.6.8. Resume URL
       6.6.9. Status URL
       6.6.10. Organizational URL
       6.6.11. Weblog URL
    6.7. Organizational Data Aspects
       6.7.1. Alternative Contact
       6.7.2. Affiliation
       6.7.3. Assistant
       6.7.4. Business Category
       6.7.5. Department Name
       6.7.6. Department Number
       6.7.7. Employee Number
       6.7.8. Employee Type
       6.7.9. Job Title
       6.7.10. Manager
       6.7.11. Organizational Name
       6.7.12. Organizational Role
       6.7.13. Organizational Unit
       6.7.14. Primary Affiliation
       6.7.15. Primary Organizational Name
       6.7.16. Primary Organizational Role
       6.7.17. Primary Organizational Unit
       6.7.18. System Username
       6.7.19. Teams
       6.7.20. Workstation Address
    6.8. Basic Personal Data Aspects
       6.8.1. Birth Day-of-Month
       6.8.2. Birth Month
       6.8.3. Birth Year
       6.8.4. Description
       6.8.5. Eye Color
       6.8.6. Gender
       6.8.7. Hair Color
       6.8.8. Height
       6.8.9. Weight
    6.9. Extended Personal Data Aspects
       6.9.1. Areas of Expertise
       6.9.2. Avatar Data
       6.9.3. Clubs
       6.9.4. Dietary Preferences
       6.9.5. Hobbies
       6.9.6. Interests
       6.9.7. Languages Known Less Well
       6.9.8. Languages Known Well
       6.9.9. License Plate Number
       6.9.10. Marital Status
       6.9.11. Myers-Briggs Type Indicator
       6.9.12. Photo Data
       6.9.13. Profession
       6.9.14. Religious Affiliation
       6.9.15. Sexual Orientation
       6.9.16. Smoker
       6.9.17. Wishlist
       6.9.18. Zodiac Sign (Chinese)
       6.9.19. Zodiac Sign (Western)
    6.10. Security Data Aspects
       6.10.1. PGP Key
       6.10.2. PGP Key Fingerprint
       6.10.3. PGP Key ID
       6.10.4. X.509 Fingerprint (MD5)
       6.10.5. X.509 Fingerprint (SHA-1)
    6.11. Personal Favorites
       6.11.1. Favorite Authors
       6.11.2. Favorite Athletes
       6.11.3. Favorite Beverages
       6.11.4. Favorite Charities
       6.11.5. Favorite Chatrooms
       6.11.6. Favorite Drinks
       6.11.7. Favorite Foods
       6.11.8. Favorite Games
       6.11.9. Favorite Movies
       6.11.10. Favorite Music
       6.11.11. Favorite Quotes
       6.11.12. Favorite Sports Teams
       6.11.13. Favorite TV Shows
    6.12. Personal History
       6.12.1. Places Lived
       6.12.2. Schools Attended
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations
    9.1. Protocol Namespaces
    9.2. Field Standardization
10. XML Schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

It is widely acknowledged within the Jabber/XMPP community that the vcard-temp (XEP-0054) [1] specification (XEP-0054) has outlived its usefulness. There are several reasons for this conclusion:

  1. XEP-0054 is not fully consistent with the Internet-Draft on which it was based.
  2. The Internet-Draft on which it was based was never approved by the IETF.
  3. Because of confusion over aspects of the vcard-temp specification, there exist incompatible implementations.
  4. vCard (RFC 2426 [2]) captures only a limited set of information.
  5. vCard (even in its XML representation [3]) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.
  6. vCard data tends to be monolithic (the basic unit of information is the full vCard, not parts thereof).
  7. The publication model for XEP-0054 is to set the full vCard, rather than only the parts that need to be modified.
  8. The retrieval model for XEP-0054 is to get the full vCard, rather than only the parts that have been modified.

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 XEP-0054, this document specifies methods for the representation of profile data in terms of the Data Forms (XEP-0004) [7] protocol (further qualified using the standardization concepts specified in Field Standardization for Data Forms (XEP-0068) [8]) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, Publish-Subscribe (XEP-0060) [9] semantics (specifically the simplified subset of those semantics specified in Personal Eventing Protocol (XEP-0163) [10]). The rationale behind these design decisions is provided below.

2. Requirements

This document addresses the following requirements for data management:

  1. Enable an entity to publish profile data about itself.
  2. Enable requesting entities to retrieve profile data about other entities.

This document addresses the following requirements for data representation:

  1. Specify how to represent profile data in an XMPP-friendly manner for communication over the wire.
  2. Ensure that the protocol is extensible (e.g., not limited to existing vCard fields). [11]
  3. Where possible, map profile data fields to existing vCard fields and other common formats.

3. Concepts and Approach

3.1 Data Management

There are several possible approaches to representing profile data for communication over XMPP networks, including the following:

  1. IQ (request-and-response) semantics.

    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 Service Discovery Extensions (XEP-0128) [12], 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 (see Protocol Namespaces regarding issuance of one or more permanent namespaces).

  2. Pubsub (publish-and-subscribe) semantics.

    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 XEP-0163 to implement this model.

3.2 Data Representation

As with data management, there are several possible approaches to representing profile data for communication over XMPP networks, including the following:

Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' (see Protocol Namespaces regarding issuance of one or more permanent namespaces), in accordance with the field standardization methods defined in XEP-0068. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the XMPP Registrar [17] (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 XEP-0068. [18]

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

<profile xmlns='urn:xmpp:tmp:profile'>
  <x xmlns='jabber:x:data' type='result'>
    <field var='FORM_TYPE' type='hidden'>
      <value>urn:xmpp:tmp:profile</value>
    </field>
    <field var='common_name'>
      <value>Peter Saint-Andre</value>
    </field>
    <field var='nickname'>
      <value>stpeter</value>
    </field>
    <field var='x-favorite_painters'>
      <value>Joaquin Sorolla</value>
      <value>Jan Vermeer</value>
    </field>
  </x>
</profile>
    

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.

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 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 XMPP Registrar Considerations section of this document.

4. Producer Use Cases

4.1 Publishing a Full Profile

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.

Example 2. Entity publishes full profile

<iq type='set' id='setfull'>
  <profile xmlns='urn:xmpp:tmp:profile'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:tmp:profile</value>
      </field>
      <field var='nickname'>
        <value>Hamlet</value>
      </field>
      <field var='country'>
        <value>DK</value>
      </field>
      <field var='locality'>
        <value>Elsinore</value>
      </field>
      <field var='email'>
        <value>hamlet@denmark.lit</value>
      </field>
    </x>
  </profile>
</iq>
    

If the server can successfully process the request and host the full profile, it MUST return an IQ-result:

Example 3. Server acknowledges success

<iq type='result' to='hamlet@denmark.lit/elsinore' id='setfull'/>
    

Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be <service-unavailable/>.

4.2 Updating One or More Profile Fields

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 "urn:xmpp:tmp:profile" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.

Example 4. Account owner publishes profile field(s)

<iq type='set' id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:tmp:profile'>
      <item>
        <profile xmlns='urn:xmpp:tmp:profile'>
          <x xmlns='jabber:x:data' type='result'>
            <field var='weblog'>
              <value>http://www.denmark.lit/blogs/princely_musings</value>
            </field>
          </x>
        </profile>
      </item>
    </publish>
  </pubsub>
</iq>
    

The PEP service then MUST send notifications containing the updated field(s) to the node subscribers:

Example 5. Server generates notifications

<message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:tmp:profile'>
      <item>
        <profile xmlns='urn:xmpp:tmp:profile'>
          <x xmlns='jabber:x:data' type='result'>
            <field var='weblog'>
              <value>http://www.denmark.lit/blogs/princely_musings</value>
            </field>
          </x>
        </profile>
      </item>
    </items>
  </event>
</message>

.
.
.
    

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.

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.

5. Consumer Use Cases

5.1 Discovering Support

If an entity can provide profile data directly using the standalone 'urn:xmpp:tmp:profile' namespace, it SHOULD advertise that feature in response to Service Discovery (XEP-0030) [19] information requests:

Example 6. A request for service discovery information

<iq type='get'
    from='bard@shakespeare.lit/globe'
    to='hamlet@denmark.lit'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

Example 7. A service discovery information response

<iq type='result'
    from='hamlet@denmark.lit'
    to='bard@shakespeare.lit/globe'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='account' type='registered'/>
    <identity category='pubsub' type='pep'/>
    ...
    <feature var='urn:xmpp:tmp:profile'/>
    ...
  </query>
</iq>
    

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 provide profile data on behalf of the registered account and that it supports the personal eventing profile of XMPP Publish-Subscribe.

5.2 Requesting Full Profile

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 'urn:xmpp:tmp:profile' namespace. In this example, the request is sent to a server, not a user (any XMPP entity can have a profile, including servers, gateways, Multi-User Chat (XEP-0045) [20] rooms, and the like):

Example 8. A request for profile data

<iq type='get'
    from='hamlet@denmark.lit/elsinore'
    to='shakespeare.lit'
    id='iq1'>
  <profile xmlns='urn:xmpp:tmp:profile'/>
</iq>
    

The server then replies:

Example 9. A basic profile data response

<iq type='result'
    from='shakespeare.lit'
    to='hamlet@denmark.lit/elsinore'
    id='iq1'>
  <profile xmlns='urn:xmpp:tmp:profile'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:tmp:profile</value>
      </field>
      <field var='common_name'>
        <value>shakespeare.lit IM server</value>
      </field>
      <field var='country'>
        <value>UK</value>
      </field>
      <field var='region'>
        <value>England</value>
      </field>
      <field var='locality'>
        <value>London</value>
      </field>
      <field var='area'>
        <value>Bankside</value>
      </field>
      <field var='street'>
        <value>21 New Globe Walk</value>
      </field>
      <field var='postalcode'>
        <value>SE1 9DT</value>
      </field>
      <field var='lat'>
        <value>51.5076</value>
      </field>
      <field var='lon'>
        <value>-0.0953</value>
      </field>
      <field var='landline_phone'>
        <value>+44 20 7902 1400</value>
      </field>
      <field var='fax'>
        <value>+44 20 7902 1401</value>
      </field>
      <field var='building'>
        <value>Globe Theatre</value>
      </field>
      <field var='email'>
        <value>admin@shakespeare.lit</value>
      </field>
    </x>
  </profile>
</iq>
    

If a server supports stored profile data for user accounts that it hosts, a requesting entity can request the full profile for such an account:

Example 10. A request for hosted profile data

<iq type='get'
    from='bard@shakespeare.lit/globe'
    to='hamlet@denmark.lit'
    id='iq2'>
  <profile xmlns='urn:xmpp:tmp:profile'/>
</iq>
    

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 <service-unavailable/> error:

Example 11. Server returns service unavailable error

<iq type='error'
    from='hamlet@denmark.lit'
    to='bard@shakespeare.lit/globe'
    id='iq2'>
  <profile xmlns='urn:xmpp:tmp:profile'/>
  <error code='503' type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

If the requested account does not exist or has not published profile data, the server also SHOULD return a <service-unavailable/> error.

Otherwise, the server SHOULD return the profile for the hosted account.

Example 12. Server returns profile data

<iq type='result'
    from='hamlet@denmark.lit'
    to='bard@shakespeare.lit/globe'
    id='iq2'>
  <profile xmlns='urn:xmpp:tmp:profile'>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:tmp:profile</value>
      </field>
      <field var='nickname'>
        <value>Hamlet</value>
      </field>
      <field var='country'>
        <value>DK</value>
      </field>
      <field var='locality'>
        <value>Elsinore</value>
      </field>
      <field var='email'>
        <value>hamlet@denmark.lit</value>
      </field>
      <field var='weblog'>
        <value>http://www.denmark.lit/blogs/princely_musings</value>
      </field>
    </x>
  </profile>
</iq>
    

5.3 Receiving Profile Updates

In order to receive updated fields for a contact's profile, an entity shall encapsulate a feature of "urn:xmpp:tmp:profile+notify" in its Entity Capabilities (XEP-0115) [21] data. If the contact's server supports the personal eventing profile of XMPP Publish-Subscribe as described in XEP-0163, the entity will receive notifications whenever the contact sends updated profile fields to the profile node:

Example 13. Entity receives notification

<message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:tmp:profile'>
      <item>
        <profile xmlns='urn:xmpp:tmp:profile'>
          <x xmlns='jabber:x:data' type='result'>
            <field var='weblog'>
              <value>http://www.denmark.lit/blogs/princely_musings</value>
            </field>
          </x>
        </profile>
      </item>
    </items>
  </event>
</message>
    

It is the responsibility of the receiving entity to correctly process the notification and update the local representation of the contact's profile information.

6. Data Representation

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 RFC 2252 [22], RFC 2256 [23], and RFC 2798 [24]) [25], and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.

6.1 Name Data Aspects

Mappings are provided to vCard, LDAP, xNAL, and FOAF.

6.1.1 Display Name

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 14. Display Name

<field var='display_name'>
  <value>Peter Saint-Andre</value>
</field>
      

6.1.2 Familiar Name

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").

The Data Forms field that represents a familiar name is "familiar_name".

This field maps to:

Example 15. Familiar Name

<field var='familiar_name'>
  <value>Pete</value>
</field>
      

6.1.3 Family Name

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 16. Family Name

<field var='family_name'>
  <value>Saint-Andre</value>
</field>
      

6.1.4 Given Name

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 17. Given Name

<field var='given_name'>
  <value>J.</value>
</field>
      

6.1.5 Middle Name

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 18. Middle Name

<field var='middle_name'>
  <value>Peter</value>
</field>
      

6.1.6 Name Prefix

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 19. Name Prefix

<field var='name_prefix'>
  <value>Mr</value>
</field>
      

6.1.7 Name Suffix

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 20. Name Suffix

<field var='name_suffix'>
  <value>Esq</value>
</field>
      

6.1.8 Nickname

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 Familiar Name would be more appropriate). Sometimes also called an "alias". A person SHOULD specify only one nickname (i.e., not more than one).

The Data Forms field that represents a nickname is "nickname".

This field maps to:

Example 21. Nickname

<field var='nickname'>
  <value>stpeter</value>
</field>
      

6.1.9 Patronymic

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 22. A Patronymic

<field var='patronymic'>
  <value>Ivanovich</value>
</field>
      

6.2 Physical Address Data Aspects

Mappings are provided to vCard, xNAL, and XEP-0112 (User Physical Location (XEP-0112) [26]).

6.2.1 Country

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 23. Country

<field var='country'>
  <value>USA</value>
</field>
      

6.2.2 Region

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 24. Region

<field var='region'>
  <value>New York</value>
</field>
      

6.2.3 Locality

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 25. Locality

<field var='locality'>
  <value>New York City</value>
</field>
      

6.2.4 Area

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 26. Area

<field var='area'>
  <value>Manhattan</value>
</field>
      

6.2.5 Street

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 27. Street

<field var='street'>
  <value>Fifth Avenue and 34th Street</value>
</field>
      

6.2.6 Building

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 28. Building

<field var='building'>
  <value>Empire State Building</value>
</field>
      

6.2.7 Floor

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 29. Floor

<field var='floor'>
  <value>102</value>
</field>
      

6.2.8 Room

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 30. Room

<field var='room'>
  <value>Observatory</value>
</field>
      

6.2.9 Postal Box

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 31. Postal Box

<field var='postalbox'>
  <value>1641</value>
</field>
      

6.2.10 Postal Code

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 32. Postal Code

<field var='postalcode'>
  <value>10002</value>
</field>
      

6.2.11 Postal Address

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.

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.

This field maps to:

Example 33. Postal Address

<field var='work_postaladdress'>
  <value>1899 Wynkoop Street</value>
  <value>Suite 600</value>
  <value>Denver, CO 80202</value>
  <value>USA</value>
</field>
      

6.3 Geolocation Data Aspects

Mappings are provided to vCard and XEP-0080 (User Geolocation (XEP-0080) [27]).

6.3.1 Altitude

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 34. Altitude

<field var='alt'>
  <value>1609</value>
</field>
      

6.3.2 Latitude

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 35. Latitude

<field var='lat'>
  <value>39.75477</value>
</field>
      

6.3.3 Longitude

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 36. Latitude

<field var='lon'>
  <value>-104.99768</value>
</field>
      

6.4 Telephony Address Data Aspects

6.4.1 Fax Number

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 37. Fax Number

<field var='fax'>
  <value>303-308-3215</value>
</field>
      

6.4.2 Landline Telephone Number

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 38. Landline Telephone Number

<field var='landline_phone'>
  <value>303-308-3282</value>
</field>
      

6.4.3 Mobile Telephone Number

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 39. Mobile Telephone Number

<field var='mobile_phone'>
  <value>303-555-1212</value>
</field>
      

6.4.4 Pager Number

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 40. Pager Number

<field var='pager'>
  <value>303-555-1212</value>
</field>
      

6.4.5 SIP Address

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 41. SIP Address

<field var='sip_address'>
  <value>sip:stpeter@sipspeare.lit</value>
</field>
      

6.4.6 Skype Address

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 Skype address is "skype_address".

This field does not map to data in vCard or any other profile representation format.

Example 42. Skype Address

<field var='skype_address'>
  <value>SomeSkypeUser</value>
</field>
      

6.4.7 Videophone Address

A videophone address is an address used for for H.323 video conferencing systems.

The Data Forms field that represents a videophone address is "video_phone".

This field does not map to data in vCard or any other profile representation format.

Example 43. Videophone Address

<field var='video_phone'>
  <value>foo</value>
</field>
      

6.5 Electronic Address Data Aspects

6.5.1 AIM Screen Name

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 44. AIM Screen Name

<field var='aim_id'>
  <value>psaintandre</value>
</field>
      

6.5.2 Email Address

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 45. Email address

<field var='email'>
  <value>stpeter@jabber.org</value>
  <value>stpeter@gmail.com</value>
</field>
      

6.5.3 ICQ Number

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 46. ICQ number

<field var='icq_id'>
  <value>70902454</value>
</field>
      

6.5.4 Jabber ID

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 47. Jabber ID

<field var='jid'>
  <value>stpeter@jabber.org</value>
  <value>peter@saint-andre.com</value>
</field>
      

6.5.5 MSN Address

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 48. MSN Address

<field var='msn_id'>
  <value>petersaintandre@hotmail.com</value>
</field>
      

6.5.6 Yahoo ID

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 49. Yahoo ID

<field var='yahoo_id'>
  <value>psaintandre</value>
</field>
      

6.6 World Wide Web Resource Aspects

6.6.1 Avatar URL

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 50. Avatar URL

<field var='avatar_url'>
  <value>http://www.saint-andre.com/images/stpeter_small.jpg</value>
</field>
      

6.6.2 Biographical URL

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 51. Biographical URL

<field var='bio'>
  <value>http://www.xmpp.org/xsf/people/stpeter.shtml</value>
  <value>http://www.saint-andre.com/me/</value>
</field>
      

6.6.3 FOAF URL

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 52. FOAF URL

<field var='foaf_url'>
  <value>http://www.saint-andre.com/me/foaf.rdf</value>
</field>
      

6.6.4 Homepage URL

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 53. Homepage URL

<field var='homepage'>
  <value>http://www.saint-andre.com/</value>
</field>
      

6.6.5 OpenID

An OpenID is the value of a URI by which a person can sign onto multiple websites or other Internet services using a single identifier (see <http://openid.net/>).

The Data Forms field that represents an OpenID is "openid".

This field maps to:

Example 54. OpenID

<field var='openid'>
  <value>https://stpeter.startssl.com/</value>
</field>
      

6.6.6 Photo URL

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 55. 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>
      

6.6.7 Publications URL

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 56. Publications URL

<field var='publications'>
  <value>http://www.saint-andre.com/thoughts/publications.html</value>
</field>
      

6.6.8 Resume URL

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 57. Resume URL

<field var='resume'>
  <value>http://www.saint-andre.com/work/</value>
</field>
      

6.6.9 Status URL

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 58. Status URL

<field var='status_url'>
  <value>http://status.jabber.org/</value>
</field>
      

6.6.10 Organizational URL

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 59. Organizational URL

<field var='org_url'>
  <value>http://www.jabber.org/</value>
</field>
      

6.6.11 Weblog URL

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 60. Weblog URL

<field var='weblog'>
  <value>http://www.saint-andre.com/blog/</value>
</field>
      

6.7 Organizational Data Aspects

6.7.1 Alternative Contact

It may be appropriate to list others who can be contacted if the individual is not available.

Example 61. Alternative Contact

<field var='alt_contact'>
  <value>xmpp:peter@jabber.org</value>
</field>
      

6.7.2 Affiliation

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 Employee Type, which may not be relevant in noncommercial organizations.

The Data Forms field that represents an organizational affiliation is "affiliation".

This field maps to:

Example 62. Affiliation

<field var='affiliation'>
  <value>faculty</value>
</field>
      

6.7.3 Assistant

In some organizations, a person may be assisted by another individual.

The Data Forms field that represents an assistant is "assistant".

This field maps to:

Example 63. Assistant

<field var='assistant'>
  <value>Peter Pan</value>
</field>
      

6.7.4 Business Category

The kind of business performed by an organization.

The Data Forms field that represents a business category is "business_category".

This field maps to:

Example 64. Business Category

<field var='business_category'>
  <value>Automobile sales</value>
</field>
      

6.7.5 Department Name

Some organizations have departments, which can be named or numbered.

The Data Forms field that represents a department name is "department_name".

Example 65. Department Name

<field var='department_name'>
  <value>Executive</value>
</field>
      

6.7.6 Department Number

Some organizations have departments, which can be named or numbered.

The Data Forms field that represents a department number is "department_number".

This field maps to:

Example 66. Department Number

<field var='department_number'>
  <value>5674</value>
</field>
      

6.7.7 Employee Number

Some organizations assign numbers to employees.

The Data Forms field that represents an employee number is "employee_number".

This field maps to:

Example 67. Employee Number

<field var='employee_number'>
  <value>1</value>
</field>
      

6.7.8 Employee Type

Some organizations have different types of employees, such as "full-time", "part-time", "contractor", and "temp".

The Data Forms field that represents an employee type is "employee_type".

This field maps to:

Example 68. Employee Type

<field var='employee_type'>
  <value>volunteer</value>
</field>
      

6.7.9 Job Title

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 69. Job Title

<field var='job_title'>
  <value>Executive Director</value>
</field>
      

6.7.10 Manager

In most organizations, a person is managed by or reports to another individual (often not exposed outside the organization).

The Data Forms field that represents a manager is "manager".

This field maps to:

Example 70. Manager

<field var='manager'>
  <value>William Shakespeare</value>
</field>
      

6.7.11 Organizational Name

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 71. Organizational Name

<field var='org_name'>
  <value>XMPP Standards Foundation</value>
</field>
      

6.7.12 Organizational Role

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 72. Organizational Role

<field var='org_role'>
  <value>Patron Saint</value>
  <value>Chief Evangelist</value>
  <value>Glorified Tech Writer</value>
</field>
      

6.7.13 Organizational Unit

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 73. Organizational Unit

<field var='org_unit'>
  <value>Jabber Council</value>
</field>
      

6.7.14 Primary Affiliation

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 Employee Type, 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.

The Data Forms field that represents a primary organizational affiliation is "primary_affiliation".

This field maps to:

Example 74. Primary Affiliation

<field var='primary_affiliation'>
  <value>fellow</value>
</field>
      

6.7.15 Primary Organizational Name

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.

The Data Forms field that represents the name of a primary organization is "primary_org_name".

This field maps to:

Example 75. Primary Organizational Name

<field var='primary_org_name'>
  <value>Columbia University</value>
</field>
      

6.7.16 Primary Organizational Role

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.

The Data Forms field that represents an organizational role is "primary_org_role".

This field maps to:

Example 76. Primary Organizational Role

<field var='primary_org_role'>
  <value>Professor Emeritus</value>
</field>
      

6.7.17 Primary Organizational Unit

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.

The Data Forms field that represents an organizational unit is "primary_org_unit".

This field maps to:

Example 77. Primary Organizational Unit

<field var='primary_org_unit'>
  <value>Jabber Council</value>
</field>
      

6.7.18 System Username

Usually a person has a system or network username within an organization (usually not exposed outside the organization).

The Data Forms field that represents such a username is "system_username".

This field maps to:

Example 78. System Username

<field var='system_username'>
  <value>psaintandre</value>
</field>
      

6.7.19 Teams

People often work in teams. Sometimes it can be helpful to list those teams.

The Data Forms field that represents a work team is "teams".

Example 79. Teams

<field var='teams'>
  <value>Infrastructure Team</value>
  <value>Jabber Council</value>
</field>
      

6.7.20 Workstation Address

Often a person has a dedicated workstation address or name within an organization (usually not exposed outside the organization).

The Data Forms field that represents such a username is "workstation".

Example 80. Workstation Address

<field var='workstation'>
  <value>squire</value>
</field>
      

6.8 Basic Personal Data Aspects

These data fields are not necessarily permanent, but do not tend to change very often if at all.

6.8.1 Birth Day-of-Month

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 81. Birth Day-of-Month

<field var='birth_dayofmonth'>
  <value>06</value>
</field>
      

6.8.2 Birth Month

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 82. Birth Month

<field var='birth_month'>
  <value>08</value>
</field>
      

6.8.3 Birth Year

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 83. Birth Year

<field var='birth_year'>
  <value>1966</value>
</field>
      

6.8.4 Description

It can be helpful to provide a natural-language description of a person.

The Data Forms field that represents a description of a person is "description".

This field maps to:

Example 84. Description

<field var='description'>
  <value>I'm a Jabber fanatic.</value>
</field>
      

6.8.5 Eye Color

Some people may want to know the color of a person's eyes. The allowable or recommended values for this field are not specified.

The Data Forms field that represents a person's eye color is "eye_color".

Example 85. Eye Color

<field var='eye_color'>
  <value>blue</value>
</field>
      

6.8.6 Gender

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 86. Gender

<field var='gender'>
  <value>male</value>
</field>
      

6.8.7 Hair Color

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 87. Hair Color

<field var='hair_color'>
  <value>none</value>
</field>
      

6.8.8 Height

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 88. Height

<field var='height'>
  <value>178</value>
</field>
      

6.8.9 Weight

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 89. Weight

<field var='weight'>
  <value>75</value>
</field>
      

6.9 Extended Personal Data Aspects

6.9.1 Areas of Expertise

An area of expertise is a subject in which a person has a great deal of knowledge.

The Data Forms field that represents an area of expertise is "expertise".

Example 90. Areas of Expertise

<field var='expertise'>
  <value>Jabber</value>
  <value>XMPP</value>
</field>
      

6.9.2 Avatar Data

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 91. Avatar Data

<field var='avatar_data'>
  <value>base64-encoded-image-data</value>
</field>
      

6.9.3 Clubs

Some people are members of clubs or other voluntary organizations.

The Data Forms field that represents club memberships is "clubs".

Example 92. Club Memberships

<field var='clubs'>
  <value>DENSA</value>
</field>
      

6.9.4 Dietary Preferences

Some people have dietary preferences (vegan, vegetarian, kosher, peanut allergy, no shellfish, etc.).

The Data Forms field that represents dietary preferences is "dietary_preferences".

Example 93. Dietary Preferences

<field var='dietary_preferences'>
  <value>none</value>
</field>
      

6.9.5 Hobbies

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 94. Some Hobbies

<field var='hobby'>
  <value>guitar</value>
  <value>songwriting</value>
  <value>blogging</value>
  <value>reading</value>
  <value>hiking</value>
</field>
      

6.9.6 Interests

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 95. Some Interests

<field var='interest'>
  <value>history</value>
  <value>baseball</value>
  <value>economics</value>
</field>
      

6.9.7 Languages Known Less Well

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 4646 [28].

The Data Forms field that represents a language known less that well is "languages_lesswell".

Example 96. Languages Known Less than Well

<field var='languages_lesswell'>
  <value>cz</value>
  <value>de</value>
  <value>nl</value>
</field>
      

6.9.8 Languages Known Well

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 4646.

The Data Forms field that represents a language known well is "languages_well".

This field maps to:

Example 97. Languages Known Well

<field var='languages_well'>
  <value>en</value>
</field>
      

6.9.9 License Plate Number

Many people own automobiles, which usually have license or registration numbers.

The Data Forms field that represents a car license or registration number is "car_license_number".

This field maps to:

Example 98. License Plate Number

<field var='car_license_number'>
  <value>JABBER</value>
</field>
      

6.9.10 Marital Status

Human beings often get married, sometimes get divorced, become widowed, etc.

The Data Forms field that represents whether a person's marital status is "marital_status".

Example 99. Marital Status

<field var='marital_status'>
  <value>married</value>
</field>
      

6.9.11 Myers-Briggs Type Indicator

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 100. Myers-Briggs Type Indicator

<field var='mbti'>
  <value>INTP</value>
</field>
      

6.9.12 Photo Data

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 101. Photo Data

<field var='photo_data'>
  <value>base64-encoded-image-data</value>
</field>
      

6.9.13 Profession

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 102. A Profession

<field var='profession'>
  <value>software engineer</value>
</field>
      

6.9.14 Religious Affiliation

Many people feel affiliated with a religious belief system.

The Data Forms field that represents a religious affiliation is "religion".

Example 103. Religious Affiliation

<field var='religion'>
  <value>none</value>
</field>
      

6.9.15 Sexual Orientation

The allowable or recommended values for this field are not specified.

The Data Forms field that represents a person's sexual orientation is "sexual_orientation".

Example 104. Sexual Orientation

<field var='sexual_orientation'>
  <value>straight</value>
</field>
      

6.9.16 Smoker

Some people smoke tobacco in various forms (cigarettes, cigars, pipes, etc.).

The Data Forms field that represents whether a person smokes is "smoker".

Example 105. Smoker

<field var='smoker'>
  <value>no</value>
</field>
      

6.9.17 Wishlist

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 106. Wishlist

<field var='wishlist'>
  <value>A Mini Cooper</value>
</field>
      

6.9.18 Zodiac Sign (Chinese)

A Chinese zodiac sign denotes the type of year in which a person was born according to the Chinese calendar (e.g., the year of the dragon).

The Data Forms field that represents a Chinese zodiac sign is "zodiac_chinese".

Example 107. Zodiac Sign (Chinese)

<field var='zodiac_chinese'>
  <value>horse</value>
</field>
      

6.9.19 Zodiac Sign (Western)

A Western zodiac sign is that part of the astrological belt under which a person was born; each sign is named after one of the constellations.

The Data Forms field that represents a Western zodiac sign is "zodiac_western".

Example 108. Zodiac Sign (Western)

<field var='zodiac_western'>
  <value>Leo</value>
</field>
      

6.10 Security Data Aspects

Some people have PGP keys, X.509 certificates, and the like.

6.10.1 PGP Key

The ASCII armored output of a PGP key.

The Data Forms field that represents a PGP key is "pgpkey".

This field maps to:

Example 109. PGP Key

<field var='pgpkey'>
  <value>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.4 (Darwin)

mQGiBEGSeUQRBADTT8NqGpxDQ1GjmAJBDNET0blyb1LF6exYLxydX+hzcooE5WxP
Zdo5Xx0RrLYlKmmcKv0Z8cG/kei2pkS05h/oqluphGmzMBIeC/ox22z87PKpVDfj
OEYQOZqhqdFI+KRIa4M89CQOO1N5V2KlX9GaNjxRearKvLgsoeTzpPtybwCgl91i
SqQnry1YV+PFOjRcDT7cX+UD/2JxXU5d1Z1WZf7ttM3QjSaPc9CA4fS+axinRkn/
IbRJ/Lj8Tz+Vb4kBbBhmFG8JCoRtj2J8bsDdaFCh7nHqT2u4oXy0NJSCKrDRBcuL
bEQfasT/cuBXIM2A7nB1UtlUCYXnINxakYLIsW9BvvFN935FhZ81EJvLW34W2Mf7
Y+9ZA/0adScaI05UUE5RRcZSiXs8/p+R6SeaW2gjS5beL5Wv6ExRlDe92rGqrjtN
PmBRiDiVBSoYlqOepBZk+wM+/B4WMsmUFVeXsXWjWMlghyyni2rI1Z2v1UH8KBKm
259k7SlU/BbnEAHIzuHPSQHJNUX+YqWArz1v5tDcQn7L1Wo7PbRAUGV0ZXIgU2Fp
bnQtQW5kcmUgKHhtcHA6c3RwZXRlckBqYWJiZXIub3JnKSA8c3RwZXRlckBqYWJi
ZXIub3JnPoheBBMRAgAeBQJBknlEAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJ
EFmFiWTXBRKsfeQAoJdO0PvP1Mi/kJ9U1zVpa4GPpXYCAJ9oFjonfr+Z3ZTefjSb
tZpE2mny57kCDQRBknlzEAgAisWlkK6daVjrxouZK9KvX8tt3CKVse4CY52Lq7xi
dtEAhDcXX9SgTnlxgrcCnBipj/OMi/B2M0U88qv3TcsZ0dWZt7H4FnHJvU4xloK8
qRkJ7xa6gCEoPAc7ESdr//6J/eEvWMqixstOUyfRg2AQp/eSHX0Cl/TQImRVZbh6
HYCehrqpErAnz0VY8nvun3709LgvIMUvKrnV7lF9wOuuhWCK9IYdpmgoD4d/Gr4t
ZVuE1jYN4tBLyQXtJDAR/UvKHEiXUAhsfXOtfCUQV5MaxM6YQce63BGl05kS7oLH
Sx+KYOX1vEi3k1OFfH5CpqYaxmfhSzdyz7Hhdsl+IbkhzwAECwf/YQfpx4z9dnJn
3ePrZhz5SI4KjdbOCmqhLFd8aVoQ9BCriePH3kPjjoE9Qz+0NlFqzuG4/tkZkAok
BA0GqYE4XXgvpwGpK95mlUvxDOowu0fLVQA8NfpU3U7YItZkfAPZ2M+PnmayRILi
0yBmm1taVllCD2mc2vhsMRUoD1DUworSzQuTG9YlQ89Q2/1LsoQzYjBz9XIfYV4A
MPr/PKPkKy3D7BYHi/DOnkcP9hLXJSCjgV5TpuWuCVX9aYU2Yb7BfY1OFORBCUaV
B1YLAPtXqfqjz25pIQPDEUbpKzhEO7xNU4EPT8ZsSfqqOd3aMet8McieRfMd+VIe
4J1OUIg1oYhJBBgRAgAJBQJBknlzAhsMAAoJEFmFiWTXBRKs/GgAn0R63qTEQd/e
XhK8hFkPvXjudl7xAJ95+2fAHfmHheZJVaO8VaJiL54Tvw==
=ZRIc
-----END PGP PUBLIC KEY BLOCK-----
  </value>
</field>
      

6.10.2 PGP Key Fingerprint

The fingerprint (hashed value) of a PGP key.

The Data Forms field that represents a PGP fingerprint is "pgp_fingerprint".

Example 110. PGP Fingerprint

<field var='pgp_fingerprint'>
  <value>E5CA EAE7 C8D6 CFE2 6D7A  8653 5985 8964 D705 12AC</value>
</field>
      

6.10.3 PGP Key ID

The ID of a PGP key.

The Data Forms field that represents a PGP key ID is "pgpkey_id".

Example 111. PGP Key ID

<field var='pgpkey_id'>
  <value>D70512AC</value>
</field>
      

6.10.4 X.509 Fingerprint (MD5)

The fingerprint of an X.509 certificate, hashed using MD5.

The Data Forms field representing such a value is "x509_fingerprint_md5".

Example 112. X.509 Fingerprint (MD5)

<field var='x509_fingerprint_md5'>
  <value>5D 41 20 54 7C 90 49 A1 78 36 07 29 75 9B A7 D0</value>
</field>
      

6.10.5 X.509 Fingerprint (SHA-1)

The fingerprint of an X.509 certificate, hashed using SHA-1.

The Data Forms field representing such a value is "x509_fingerprint_sha1".

Example 113. X.509 Fingerprint (SHA-1)

<field var='x509_fingerprint_sha1'>
  <value>C3 88 33 27 F3 47 3B 8B 07 71 3E 96 44 A7 EE E2 E0 50 4A 5B</value>
</field>
      

6.11 Personal Favorites

Most people have favorite movies, authors, TV shows, musical artists, foods, games, etc.

6.11.1 Favorite Authors

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 114. Favorite Authors

<field var='fav_authors'>
  <value>Jacob Bronowski</value>
  <value>Friedrich Nietzsche</value>
  <value>Carroll Quigley</value>
  <value>Yevgeny Zamyatin</value>
</field>
      

6.11.2 Favorite Athletes

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 115. Favorite Athletes

<field var='fav_athletes'>
  <value>Lance Armstrong</value>
  <value>Andre Agassiz</value>
</field>
      

6.11.3 Favorite Beverages

The Data Forms field that represents favorite beverages is "favorite_beverages".

This field maps to:

Example 116. Favorite Beverages

<field var='favorite_beverages'>
  <value>Guinness</value>
</field>
      

6.11.4 Favorite Charities

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 117. Favorite Charities

<field var='fav_charities'>
  <value>Institute for Justice</value>
  <value>PERC</value>
</field>
      

6.11.5 Favorite Chatrooms

The Data Forms field that represents favorite chatrooms is "fav_chatrooms".

This field does not map to data in vCard or any other profile representation format.

Example 118. Favorite Chatrooms

<field var='fav_chatrooms'>
  <value>jabber@conference.jabber.org</value>
  <value>jdev@conference.jabber.org</value>
</field>
      

6.11.6 Favorite Drinks

The Data Forms field that represents favorite drinks is "fav_drinks".

This field does not map to data in vCard or any other profile representation format.

Example 119. Favorite Drinks

<field var='fav_drinks'>
  <value>Guinness</value>
</field>
      

6.11.7 Favorite Foods

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 120. Favorite Foods

<field var='fav_foods'>
  <value>Thai</value>
  <value>Mexican</value>
  <value>Italian</value>
</field>
      

6.11.8 Favorite Games

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 121. Favorite Games

<field var='fav_games'>
  <value>chess</value>
</field>
      

6.11.9 Favorite Movies

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 122. 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>
      

6.11.10 Favorite Music

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 123. Favorite Music

<field var='fav_music'>
  <value>J.S. Bach</value>
  <value>Duke Ellington</value>
  <value>Mellow Candle</value>
  <value>Yes</value>
</field>
      

6.11.11 Favorite Quotes

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 124. Favorite Quotes

<field var='fav_quotes'>
  <value>I am large, I contain multitudes.</value>
  <value>&quot;Think like a man of action, act like a man of thought.&quot; --Henri Bergson</value>
  <value>One crowded hour of glorious life is worth an age without a name.</value>
</field>
      

6.11.12 Favorite Sports Teams

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 125. Favorite Sports Teams

<field var='fav_teams'>
  <value>New York Yankees</value>
  <value>Colorado Rockies</value>
</field>
      

6.11.13 Favorite TV Shows

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 126. Favorite TV Shows

<field var='fav_tv'>
  <value>Antiques Road Show</value>
</field>
      

6.12 Personal History

6.12.1 Places Lived

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 127. 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>
      

6.12.2 Schools Attended

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 128. Schools Attended

<field var='schools'>
  <value>Columbia University</value>
  <value>American Renaissance School</value>
  <value>Maranacook Community School</value>
</field>
      

7. Security Considerations

Profile data can be personally significant and even security critical. Due care should be taken in determining who shall have access to such information. In particular, an entity SHOULD ensure that its public profile contains only information that it deems safe to be world-readable, SHOULD ensure that any pubsub node it may create for profile data has an access model of "presence" or "roster", and SHOULD NOT publish private or restricted data except to such a pubsub node.

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [29].

9. XMPP Registrar Considerations

9.1 Protocol Namespaces

Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:profile"; upon advancement of this specification, the XMPP Registrar [30] shall issue a permanent namespace in accordance with the process defined in Section 4 of XMPP Registrar Function (XEP-0053) [31].

9.2 Field Standardization

To follow.

10. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:tmp:profile'
    xmlns='urn:xmpp:tmp:profile'
    elementFormDefault='qualified'>

  <xs:import
      namespace='jabber:x:data'
      schemaLocation='http://www.xmpp.org/schemas/x-data.xsd'/>

  <xs:element name='profile'>
    <xs:complexType>
      <xs:sequence xmlns:data='jabber:x:data'>
        <xs:element ref='data:x'/>
      </xs:sequence>
    </xs:complexType>

</xs:schema>
  

Appendices


Appendix A: Document Information

Series: XEP
Number: 0154
Publisher: XMPP Standards Foundation
Status: Deferred
Type: Standards Track
Version: 0.6
Last Updated: 2008-04-18
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0004, XEP-0060, XEP-0068, XEP-0163
Supersedes: XEP-0054
Superseded By: None
Short Name: TO-BE-ASSIGNED
Source Control: HTML
This document in other formats: XML  PDF


Appendix B: Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/


Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2014 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards 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 document 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.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. XEP-0054: vcard-temp <http://xmpp.org/extensions/xep-0054.html>.

2. RFC 2426: vCard MIME Directory Profile <http://tools.ietf.org/html/rfc2426>.

3. For links to the experimental XML representation of vCard, see XEP-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. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

8. XEP-0068: Field Data Standardization for Data Forms <http://xmpp.org/extensions/xep-0068.html>.

9. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

10. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

11. 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.

12. XEP-0128: Service Discovery Extensions <http://xmpp.org/extensions/xep-0128.html>.

13. XEP-0080: User Geolocation <http://xmpp.org/extensions/xep-0080.html>.

14. XEP-0112: User Physical Location <http://xmpp.org/extensions/xep-0112.html>.

15. Resource Description Framework (RDF) <http://www.w3.org/RDF/>.

16. XEP-0134: XMPP Design Guidelines <http://xmpp.org/extensions/xep-0134.html>.

17. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

18. Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.

19. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

20. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

21. XEP-0115: Entity Capabilities <http://xmpp.org/extensions/xep-0115.html>.

22. RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions <http://tools.ietf.org/html/rfc2252>.

23. RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 <http://tools.ietf.org/html/rfc2256>.

24. RFC 2798: Definition of the inetOrgPerson LDAP Object Class <http://tools.ietf.org/html/rfc2798>.

25. 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.

26. XEP-0112: User Physical Location <http://xmpp.org/extensions/xep-0112.html>.

27. XEP-0080: User Geolocation <http://xmpp.org/extensions/xep-0080.html>.

28. RFC 4646: Tags for Identifying Languages <http://tools.ietf.org/html/rfc4646>.

29. 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/>.

30. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

31. XEP-0053: XMPP Registrar Function <http://xmpp.org/extensions/xep-0053.html>.


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.6 (2008-04-18)

Updated to reflect stable PEP protocol; added OpenID field; specified XML schema; changed namespace to conform to XMPP Registrar procedures.

(psa)

Version 0.5 (2006-08-02)

Updated to reflect changes to XEP-0163; added some mappings to the eduPerson object class.

(psa)

Version 0.4 (2006-01-16)

Defined data management methods using IQ and the PEP subset of pubsub; added various data fields from LDAP; changed namespace from profiledata to profile.

(psa)

Version 0.3 (2005-11-11)

Added postaladdress, fav_chatrooms, alt_contact, teams; added various security-related fields.

(psa)

Version 0.2 (2005-07-25)

Added mappings to common LDAP schemas.

(psa)

Version 0.1 (2005-06-16)

Initial version.

(psa)

Version 0.0.5 (2005-06-13)

Defined how to handle vCard types such as home vs. work addresses.

(psa)

Version 0.0.4 (2005-04-07)

Reworked field standardization; added support for telephony addresses, electronic addresses, and organizational data.

(psa)

Version 0.0.3 (2005-03-11)

Added open issues.

(psa)

Version 0.0.2 (2005-01-06)

Explained requirements and design decisions in more detail, especially with regard to extensibility; split photo into two elements (data and URL).

(psa)

Version 0.0.1 (2004-11-10)

First draft.

(psa)

END