Updated to reflect stable PEP protocol; added OpenID field; specified XML schema; changed namespace to conform to XMPP Registrar procedures.
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 &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace &NSNOTE;.
+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;.
Pubsub (publish-and-subscribe) semantics.
@@ -167,13 +173,13 @@Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' &NSNOTE;, 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 ®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 XEP-0068.
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 XEP-0068. 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 XEP-0068.
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:
By specifying that all fields are scoped by a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'http://www.xmpp.org/extensions/xep-0154.html#ns' 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.
+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.
@@ -198,10 +204,10 @@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.
Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.
In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "http://www.xmpp.org/extensions/xep-0154.html#ns" at its server using the PEP subset of the publish-subscribe extension, as specified in XEP-0163.
+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.
If an entity can provide profile data directly using the standalone 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:
+If an entity can provide profile data directly using the standalone 'urn:xmpp:tmp:profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:
Note: Because the foregoing request was sent to the bare JID <hamlet@denmark.lit>, the response is provided by the <denmark.lit> server on behalf of the registered account. The answer indicates that the server can also provide profile data on behalf of the registered account.
+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.
In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty <profile/> element qualified by the 'http://www.xmpp.org/extensions/xep-0154.html#ns' namespace. In this example, the request is sent to a server:
+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, &xep0045; rooms, and the like):
The server then replies:
@@ -310,10 +317,10 @@ from='shakespeare.lit' to='hamlet@denmark.lit/elsinore' id='iq1'> -If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a whitelist of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:
@@ -373,7 +380,7 @@ from='hamlet@denmark.lit' to='bard@shakespeare.lit/globe' id='iq2'> -In order to receive updated fields for a contact's profile, an entity shall send a pubsub subscription request to the contact's bare JID &LOCALBARE; and specify a node of "http://www.xmpp.org/extensions/xep-0154.html#ns":
-If the server allows the subscription, it MUST return an IQ-result (see XEP-0163 for error scenarios):
-When the contact sends updated fields to the profile node, the entity will receive notifications:
+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 &xep0115; 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:
It is the responsibility of the receiving entity to correctly process the notification and update the contact's profile information accordingly.
+It is the responsibility of the receiving entity to correctly process the notification and update the local representation of the contact's profile information.
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:
+This document requires no interaction with &IANA;.
Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:profile"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.
+To follow.
-
+
+
+
+
+
+
+
+
+
+
+ ]]>
+