<remark><p>Changed height and width attributes from required to recommended; updated security considerations to reflect problems with SHA-1; further specified datatypes.</p></remark>
<remark><p>Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization; modified experimental namespaces to conform to XEP-0053.</p></remark>
<remark><p>Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2006-01-17</date>
<initials>psa</initials>
<remark><p>Updated to use PEP.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2005-04-13</date>
<initials>psa</initials>
<remark><p>Major modification per list discussion: specified that metadata may include the same avatar in multiple alternate formats; allowed pointers to third-party avatars not available via pubsub or HTTP; changed pixel size restrictions; specified that bytes, content-type, height, id, and width are required metadata; changed type attribute to content-type; made explicit that URLs can be http: or https: URIs; more fully specified protocol, updated the examples, updated the schemas.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2005-03-28</date>
<initials>psa/pgm</initials>
<remark><p>Friendly fork per Council discussion: allowed data to be stored in a pubsub data repository or at a URL accessible via HTTP; also split text into publisher and subscriber use cases, specified requirements, added more examples, etc.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2003-05-20</date>
<initials>tjm</initials>
<remark><p>Lessen the image requirements. Include the content type in info.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-05-08</date>
<initials>tjm</initials>
<remark><p>Drastic change to use two nodes on pubsub, allowing for hash updates independently of the data. This makes client caching much easier. Allow only PNG and MNG currently.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-05-07</date>
<initials>tjm</initials>
<remark><p>Clarified the use of "current" as the item id. Fixed some example errors. Made the interaction with disco more clear. The reason to use pubsub is made more clear as well.</p></remark>
<p>Many communication applications allow for the association of a small image or icon with a user of that application. Usually, such an "avatar" is not intended to be an accurate picture of the user's actual physical appearance, but rather a representation (often fanciful) of the user's desired self-image or a transient state of the user (such as a mood or activity). This document outlines a way to incorporate avatars into current Jabber/XMPP systems by layering this functionality on top of the XMPP &xep0060; extension ("pubsub"), specifically the &xep0163; subset ("PEP"), which is designed for use in the context of XMPP instant messaging and presence systems that conform to &rfc3921;.</p>
<p>The protocol defined herein uses two pubsub nodes: one node for "metadata" about the avatar state (called the "metadata node") and one for the avatar data itself (called the "data node"). This separation of metadata from data conserves bandwidth and enables both the publisher and the subscriber to cache the avatar data. (For example, a user might toggle between two or three avatars, in which case the user's contacts can display a locally cached version of the images without having to retrieve or receive the full image each time.)</p>
<p>This protocol also allows storage of avatar data at a URL accessible via HTTP (see &rfc2616;). <note>By "accessible via HTTP" is meant that the data is available at an http: or https: URI.</note> This can be helpful as a fallback mechanism if a pubsub-aware data repository is not available. It also makes it possible for avatar images to be hosted on public websites (e.g., an end-user-oriented community site) and retrieved from that site rather than handled directly by the publishing client in any fashion.</p>
<p>Finally, this protocol also enables XMPP applications to optionally integrate with third-party services that host user avatars (e.g., online gaming systems and virtual worlds).</p>
</section1>
<section1topic='Requirements'anchor='reqs'>
<p>This document addresses the following use cases for avatar publishers:</p>
<ol>
<li>Publishing avatar data</li>
<li>Updating metadata about the current avatar</li>
<li>Disabling avatars</li>
</ol>
<p>This document addresses the following use cases for avatar subscribers:</p>
<ol>
<li>Discovering avatar availability</li>
<li>Receiving notification of avatar changes</li>
<li>Retrieving avatar data via pubsub</li>
<li>Retrieving avatar data via HTTP</li>
</ol>
</section1>
<section1topic='Basic Process Flow'anchor='process'>
<p>The process for publishing and updating user avatars is as follows:</p>
<ol>
<li>User publishes avatar data for "image/png" content-type to data node and optionally publishes other content-types to HTTP URLs</li>
<li>User publishes notification of updated avatar to metadata node, with ItemID that matches SHA1 hash of image data for "image/png" content-type (note: this is a hash of the image data itself, not the base64-encoded version)</li>
<li>Subscribers receive notification</li>
<li>Optionally (and if necessary), subscribers retrieve avatar data identified by ItemID from data node using pubsub get-items feature (or via HTTP)</li>
<li>Optionally, user disables avatar display.</li>
</ol>
<p>This process flow is described more fully in the following sections.</p>
<p>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 <cite>XEP-0163</cite>, since such support simplifies avatar publication. The following examples assume the availability of a PEP service.</p>
<p>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).</p>
<p>The following example illustrates the XML structure to be sent when publishing avatar data to the data node.</p>
<examplecaption='Publishing avatar data to data node'><