Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization.
Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization; modified experimental namespaces to conform to XEP-0053.
The process for publishing and updating user avatars is as follows:
This process flow is described more fully in the following sections.
-Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in XEP-0163.
-In order to publish notifications related to its avatar, the user MUST first create a node for his or her avatar metadata:
-The NodeID MUST be "http://jabber.org/protocol/avatar#metadata" and the access model SHOULD be "presence". Note: If the default access model (see XEP-0163) is the same as the desired access model, the user can send an empty <configure/> element rather than including a data form as shown above.
-Next, the user SHOULD create a node for his or her avatar data (however, note that data publication via XMPP is not required since the data could be made available at an HTTP URL):
-If the user creates a data note, the NodeID MUST be "http://jabber.org/protocol/avatar#data" and the access model SHOULD be "presence".
-Note: Before publishing avatar data and metadata, the user MUST determine if his or her server supports the PEP subset of pubsub by following the procedures specified in XEP-0163, since such support simplifies avatar publication. The following examples assume the availability of a PEP service.
Before updating the avatar metadata node, the publisher MUST make sure that the avatar data is available at the data node or URL. When publishing the avatar data to the data node, the publisher MUST ensure that the value of the pubsub ItemID is the SHA1 hash of the data for the "image/png" content-type (this is used by the subscriber to determine if a locally cached copy can be displayed).
The following example illustrates the XML structure to be sent when publishing avatar data to the data node.
The PEP subset of pubsub requires that there shall exist a one-to-one relationship between namespaces and nodes. Because the protocol defined herein stipulates the use of two nodes (one for avatar data and one for avatar metadata), we define two namespaces, each with a corresponding root element:
These are further specified below.
The <data/> element is used to communicate the avatar data itself, and only for the "image/png" content-type (support for which is REQUIRED):
+
IMAGE DATA
]]>
@@ -314,7 +273,7 @@
The <info/> child element is used to communicate avatar metadata:
+
The <pointer/> child element is used to point to an avatar that is not published via pubsub or HTTP, but rather is provided by a third-party service such as an online gaming system or virtual world:
+
... APPLICATION-SPECIFIC DATA ...
-
+
]]>
The <pointer/> element MAY possess the following attributes if the publishing application has the relevant information:
@@ -365,7 +324,7 @@
The <stop/> child element is used to signal that avatar publishing has been disabled:
+
]]>
@@ -380,9 +339,9 @@
-
+
-
-
+
-
+
-
-
+
-
]]>
@@ -485,8 +444,8 @@
This document makes use of IANA-registered content types, but requires no interaction with &IANA;.
The ®ISTRAR; shall include 'http://jabber.org/protocol/avatar#data' and 'http://jabber.org/protocol/avatar#metadata' in its registry of protocol namespaces.
+Until this specification advances to a status of Draft, its associated namespaces shall be "http://www.xmpp.org/extensions/xep-0084.html#ns-data" and "http://www.xmpp.org/extensions/xep-0084.html#ns-metadata"; upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.