1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1201 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-08-31 14:39:55 +00:00
parent 01d6a9ba9e
commit c6b7d2c337

View File

@ -21,6 +21,7 @@
</dependencies>
<supersedes>
<spec>XEP-0008</spec>
<spec>XEP-0153</spec>
</supersedes>
<supersededby/>
<shortname>TO BE ASSIGNED</shortname>
@ -28,6 +29,12 @@
&pgmillard;
&temas;
&xvirge;
<revision>
<version>0.12</version>
<date>2007-08-31</date>
<initials>psa</initials>
<remark><p>Clarified HTTP publishing; completed copy edit.</p></remark>
</revision>
<revision>
<version>0.11</version>
<date>2007-07-25</date>
@ -100,6 +107,7 @@
<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>
<p>It is intended that this specification will supersede both &xep0008; and &xep0153; once the PEP subset of XMPP publish-subscribe is implemented and deployed widely enough.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following use cases for avatar publishers:</p>
@ -119,16 +127,16 @@
<section1 topic='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 retrieve-items feature (or via HTTP)</li>
<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 SHA-1 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 retrieve-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>
<section2 topic='User Publishes Data' anchor='process-pubdata'>
<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>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 a SHA-1 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>
<example caption='Publishing avatar data to data node'><![CDATA[
<iq type='set' from='juliet@capulet.com/chamber' id='publish1'>
@ -146,20 +154,40 @@
<example caption='Pubsub service replies with success'><![CDATA[
<iq type='result' to='juliet@capulet.com/chamber' id='publish1'/>
]]></example>
<p>If the avatar will be made available via HTTP instead of a pubsub data node, the publisher MUST either verify that the avatar exists at the HTTP URL or publish it via standard HTTP methods (such methods are out of scope for this specification; refer to <cite>RFC 2616</cite>).</p>
</section2>
<section2 topic='User Publishes Metadata Notification' anchor='process-pubmeta'>
<p>Whenever the publisher wishes to change its current avatar, it MUST update the metadata node.</p>
<p>The following example shows metadata specifying avatar data that is available in only one format ("image/png") and accessible only at the data node:</p>
<p>The following example shows metadata specifying avatar data that is available in only one format ("image/png") and accessible only at the data node.</p>
<example caption='Publishing avatar metadata'><![CDATA[
<iq type='set' from='juliet@capulet.com/chamber' id='publish2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/png'
bytes='12345'
<info bytes='12345'
id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
height='64'
type='image/png'
width='64'/>
</metadata>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<p>The following example shows metadata specifying avatar data that is available at an HTTP URL.</p>
<example caption='Publishing avatar metadata'><![CDATA[
<iq type='set' from='juliet@capulet.com/chamber' id='publish2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<info bytes='23456'
height='64'
id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/gif'
url='http://avatars.example.org/happy.gif'
width='64'/>
</metadata>
</item>
@ -169,17 +197,17 @@
]]></example>
</section2>
<section2 topic='Subscribers Receive Metadata Notification' anchor='process-subnotify'>
<p>Subscribers to the metadata node would then receive the notification:</p>
<p>The user's virtual pubsub service would then send the metadata notification to entities that have subscribed to the user's metadata node or contacts who have advertised an interest in receiving avatar metadata by including a &xep0115; feature of "http://www.xmpp.org/extensions/xep-0084.html#ns-metadata+notify" &NSNOTE;.</p>
<example caption='Subscribers receive avatar metadata notification'><![CDATA[
<message to='romeo@montague.net' from='juliet@capulet.com'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/png'
bytes='12345'
<info bytes='12345'
height='64'
id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/png'
width='64'/>
</metadata>
</item>
@ -190,11 +218,11 @@
</addresses>
</message>
]]></example>
<p>Depending on node configuration, the item may include &xep0033; information about the publishing resource (see <cite>XEP-0163</cite> and <cite>XEP-0060</cite> for details).</p>
<p>As shown, depending on node configuration, the item may include &xep0033; information about the publishing resource (see <cite>XEP-0060</cite> for details).</p>
</section2>
<section2 topic='Subscribers Retrieve Data' anchor='process-subretrieve'>
<p>Upon receiving the notification, each subscriber SHOULD determine if it has a locally cached copy of that avatar (which it can determine by searching for an image identified by the ItemID). If the subscriber already has a locally cached copy of the avatar image, it MUST NOT retrieve the image data.</p>
<p>If the subscriber does not have a locally cached copy of the avatar image, it SHOULD retrieve the data. It can do this by sending a pubsub retrieve-items request to the data node, specifying the appropriate ItemID:</p>
<p>Upon receiving the notification, each subscriber SHOULD determine if it has a locally cached copy of that avatar (which it can do by searching for an image identified by the ItemID). If the subscriber already has a locally cached copy of the avatar image, it MUST NOT retrieve the image data.</p>
<p>If the subscriber does not have a locally cached copy of the avatar image, it SHOULD retrieve the data. It can do this by sending a pubsub retrieve-items request to the data node, specifying the appropriate ItemID.</p>
<example caption='Subscriber requests last item by ItemID'><![CDATA[
<iq type='get'
from='romeo@montague.net/home'
@ -207,7 +235,7 @@
</pubsub>
</iq>
]]></example>
<p>The PEP service running at the user's server then SHOULD return the avatar data:</p>
<p>The PEP service running at the user's server then SHOULD return the avatar data.</p>
<example caption='Publishing avatar data to data node'><![CDATA[
<iq type='result'
from='juliet@capulet.com'
@ -224,10 +252,10 @@
</pubsub>
</iq>
]]></example>
<p>If the &lt;info/&gt; element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this document.</p>
<p>If the &lt;info/&gt; element sent to the metadata node possesses a 'url' attribute, the avatar data is hosted at a URL. Therefore, in order to retrieve the avatar image data for that content-type, the requesting entity MUST send an HTTP request to the specified URL. Methods for doing so are out of scope for this specification (see <cite>RFC 2616</cite>).</p>
</section2>
<section2 topic='Publisher Disables Avatars' anchor='pub-stop'>
<p>In order to temporarily disable any avatar, the user publishes an empty &lt;stop/&gt; element to the metadata node (this item SHOULD NOT possess an ItemID):</p>
<p>In order to temporarily disable any avatar, the user publishes an empty &lt;stop/&gt; element to the metadata node (this item SHOULD NOT possess an ItemID).</p>
<example caption='Temporarily disabling an avatar'><![CDATA[
<iq type='set' from='juliet@capulet.com/chamber' id='publish3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
@ -241,7 +269,7 @@
</pubsub>
</iq>
]]></example>
<p>As before, subscribers to the metadata node would then receive the notification:</p>
<p>As before, subscribers to the metadata node would then receive the notification.</p>
<example caption='Subscribers receive avatar metadata notification'><![CDATA[
<message to='romeo@montague.net' from='juliet@capulet.com'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
@ -261,20 +289,21 @@
</section2>
</section1>
<section1 topic='Protocol Syntax' anchor='proto'>
<p>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:</p>
<p>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 &NSNOTE;:</p>
<ul>
<li>&lt;data xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-data'/&gt;</li>
<li>&lt;metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'/&gt;</li>
</ul>
<p>These are further specified below.</p>
<section2 topic='Data Element' anchor='proto-data'>
<p>The &lt;data/&gt; element is used to communicate the avatar data itself, and only for the "image/png" content-type (support for which is REQUIRED):</p>
<p>The &lt;data/&gt; element is used to communicate the avatar data itself, and only for the "image/png" content-type (support for which is REQUIRED).</p>
<code><![CDATA[
<data xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-data'>
IMAGE DATA
</data>
]]></code>
<p>The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of &rfc4648;. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)</p>
<p>The &lt;data/&gt; element MUST NOT possess any attributes.</p>
<p>Support for the &lt;data/&gt; element is REQUIRED.</p>
</section2>
<section2 topic='Metadata Element' anchor='proto-meta'>
@ -286,40 +315,60 @@
</ul>
<p>These are further specified below.</p>
<section3 topic='Info Element' anchor='proto-info'>
<p>The &lt;info/&gt; child element is used to communicate avatar metadata:</p>
<p>The &lt;info/&gt; child element is used to communicate avatar metadata. Support for the &lt;info/&gt; element is REQUIRED.</p>
<code><![CDATA[
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<info bytes='size-of-image-data-in-bytes'
height='image-height-in-pixels'
id='SHA1-hash-of-image-data'
id='SHA-1-hash-of-image-data'
type='content-type-of-image-data'
url='HTTP-URL-for-image-data'
width='image-width-in-pixels'/>
</metadata>
]]></code>
<p>The &lt;info/&gt; child element MUST be empty.</p>
<p>The &lt;info/&gt; child element MUST possess the following attributes:</p>
<ul>
<li><em>bytes</em> -- The size of the image data in bytes.</li>
<li><em>id</em> -- The SHA1 hash of the image data for the specified content-type.</li>
<li><em>type</em> -- The IANA-registered content type of the image data.</li>
</ul>
<p>The &lt;info/&gt; child element SHOULD possess the following attributes:</p>
<ul>
<li><em>height</em> -- The height of the image in pixels.</li>
<li><em>width</em> -- The width of the image in pixels.</li>
</ul>
<p>The &lt;info/&gt; element MAY possess the following attribute:</p>
<ul>
<li><em>url</em> -- An http: or https: URI at which the image data file may be found.</li>
</ul>
<p>If the &lt;info/&gt; element element does not possess a 'url' attribute, then it is assumed that the data is available at the data node rather than an HTTP URL.</p>
<p>The defined attributes of the &lt;info/&gt; element are specified in the following table.</p>
<table caption='Info Attributes'>
<tr>
<th>Name</th>
<th>Definition</th>
<th>Inclusion</th>
</tr>
<tr>
<td>bytes</td>
<td>The size of the image data in bytes.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>height</td>
<td>The height of the image in pixels.</td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td>id</td>
<td>A hash of the image data for the specified content-type, where the hash is produced in accordance with the SHA-1 algorithm as specified in &rfc3174; (with binary output).</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>type</td>
<td>The IANA-registered content type of the image data.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>url</td>
<td>The http: or https: URL at which the image data file is hosted; this attribute MUST NOT be included unless the image data file can be retrieved via HTTP.</td>
<td>OPTIONAL</td>
</tr>
<tr>
<td>width</td>
<td>The width of the image in pixels</td>
<td>RECOMMENDED</td>
</tr>
</table>
<p>The &lt;metadata/&gt; root element MAY contain more than one &lt;info/&gt; element. Each &lt;info/&gt; element MUST specify metadata for the same avatar image but in alternate content-types (e.g., "image/png", "image/gif", and "image/jpeg"), and one of the formats MUST be "image/png" to ensure interoperability. The value of the 'type' attribute MUST be an IANA-registered content type of type "image" or "video". <note>The IANA registry of content types is located at &lt;<link url='http://www.iana.org/assignments/media-types/'>http://www.iana.org/assignments/media-types/</link>&gt;.</note> Support for the "image/png" content type is REQUIRED. Support for the "image/gif" and "image/jpeg" content types is RECOMMENDED. Support for any other content type is OPTIONAL.</p>
<p>The value of the 'id' attribute MUST be the SHA1 (&rfc3174;) hash of the image data for the specified content-type.</p>
<p>Support for the &lt;info/&gt; element is REQUIRED.</p>
</section3>
<section3 topic='Pointer Element' anchor='proto-pointer'>
<p>The &lt;pointer/&gt; 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:</p>
<p>The &lt;pointer/&gt; 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.</p>
<code><![CDATA[
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<pointer>
@ -331,7 +380,7 @@
<ul>
<li><em>bytes</em> -- The size of the image data in bytes.</li>
<li><em>height</em> -- The height of the image in pixels.</li>
<li><em>id</em> -- The SHA1 hash of the image data for the specified content-type.</li>
<li><em>id</em> -- The SHA-1 hash of the image data for the specified content-type.</li>
<li><em>type</em> -- The IANA-registered content type of the image data.</li>
<li><em>width</em> -- The width of the image in pixels.</li>
</ul>
@ -340,7 +389,7 @@
<p>Support for the &lt;pointer/&gt; element is OPTIONAL.</p>
</section3>
<section3 topic='Stop Element' anchor='proto-stop'>
<p>The &lt;stop/&gt; child element is used to signal that avatar publishing has been disabled:</p>
<p>The &lt;stop/&gt; child element is used to signal that avatar publishing has been disabled.</p>
<code><![CDATA[
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<stop/>
@ -353,29 +402,35 @@
</section1>
<section1 topic='Additional Examples' anchor='examples'>
<section2 topic='Metadata With Multiple Content-Types' anchor='examples-multiple'>
<p>The following example shows metadata specifying avatar data that is available in multiple formats ("image/png", "image/gif", and "image/mng"), where the "image/png" content-type is available only at the data node and the other content-types are available HTTP URLs:</p>
<p>The following example shows metadata specifying avatar data that is available in multiple formats ("image/png", "image/gif", and "image/mng"), where the "image/png" content-type is available only at the data node and the other content-types are available HTTP URLs.</p>
<example caption='Publishing avatar metadata (multiple formats)'><![CDATA[
<iq type='set' from='juliet@capulet.com/chamber' id='publish3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
<info bytes='12345'
height='64'
id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/png'
bytes='12345'
height='64'
width='64'/>
<info id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f'
url='http://avatars.jabberstudio.org/happy.gif'
<info bytes='12345'
height='64'
id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/png'
url='http://avatars.example.org/happy.png'
width='64'/>
<info bytes='23456'
height='64'
id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/gif'
bytes='23456'
height='64'
url='http://avatars.example.org/happy.gif'
width='64'/>
<info id='333f4b3c50d7b0df729d299bc6f8e9ef9066971f'
url='http://avatars.jabberstudio.org/happy.mng'
type='image/mng'
bytes='78912'
<info bytes='78912'
height='64'
id='333f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/mng'
url='http://avatars.example.org/happy.mng'
width='64'/>
</metadata>
</item>
@ -383,6 +438,7 @@
</pubsub>
</iq>
]]></example>
<p>In the foregoing example, the image encapsulated in the "image/png" content type is available both at a pubsub data node and at an HTTP URL; therefore it is included twice (the second time with a 'url' attribute).</p>
</section2>
<section2 topic='Metadata With Pointer' anchor='examples-pointer'>
<p>The following example shows metadata specifying avatar data that is available in "image/png" at the data node and also with a pointer to an external service.</p>
@ -392,10 +448,10 @@
<publish node='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
<metadata xmlns='http://www.xmpp.org/extensions/xep-0084.html#ns-metadata'>
<info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/png'
bytes='12345'
<info bytes='12345'
height='64'
id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
type='image/png'
width='64'/>
<pointer>
<x xmlns='http://example.com/virtualworlds'>
@ -413,7 +469,7 @@
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<section2 topic='Discovering Avatar Availability' anchor='disco-sub'>
<p>The pubsub "auto-subscribe" and "filtered-notifications" features enable a contact to automatically subscribe to a user's avatar. However, a contact can also explicitly determine if another user publishes avatars using this protocol by sending a &xep0030; items ("disco#items") request to the user's bare JID (&BAREJID;):</p>
<p>The pubsub "auto-subscribe" and "filtered-notifications" features enable a contact to automatically subscribe to a user's avatar. However, a contact can also explicitly determine if another user publishes avatars using this protocol by sending a &xep0030; items ("disco#items") request to the user's bare JID (&BAREJID;).</p>
<example caption='Disco items request'><![CDATA[
<iq type='get'
from='romeo@montague.net/orchard'
@ -422,7 +478,7 @@
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
]]></example>
<p>If the user publishes avatar data to an PEP node, the result MUST contain the appropriate items:</p>
<p>If the user publishes avatar data to an PEP node, the result MUST contain the appropriate items.</p>
<example caption='Disco items result'><![CDATA[
<iq type='result'
from='juliet@capulet.com'
@ -439,15 +495,15 @@
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Multiple Resources' anchor='impl-resources'>
<p>If a user has multiple online resources at the same time, each resource MAY publish a different avatar. The PEP service SHOULD include the replyto address of the publishing resource as shown above in order to facilitate differentiation between per-resource avatars.</p>
<p>If a user has multiple online resources at the same time, each resource MAY publish a different avatar. The PEP service SHOULD include the "replyto" address of the publishing resource as shown above in order to facilitate differentiation between per-resource avatars.</p>
</section2>
<section2 topic='Avatar Synchronization' anchor='impl-sync'>
<p>When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar, either automatically by sending presence with the appropriate &xep0115; information or using the "retrieve-items" method described in <cite>XEP-0060</cite>.</p>
<p>When a user logs in with a new resource and before publishing an avatar, its client SHOULD retrieve its last published avatar, either automatically by sending presence with the appropriate entity capabilities information (see <cite>XEP-0115</cite>) or using the "retrieve-items" method described in <cite>XEP-0060</cite>.</p>
</section2>
<section2 topic='Image Handling' anchor='impl-images'>
<p>It is the responsibility of the receiving application to determine which avatar format to retrieve (e.g., "image/gif" rather than "image/png") and to determine the appropriate method for retrieval (e.g., HTTP rather than pubsub).</p>
<p>The receiving application SHOULD NOT scale up an image when displaying it.</p>
<p>If an avatar is not available for a contact, the receiving MAY display the contact's photo, e.g., as provided in the contact's vCard (see &xep0054;) or other profile information.</p>
<p>If an avatar is not available for a contact, the receiving application MAY display the contact's photo, e.g., as provided in the contact's vCard (see &xep0054;) or other profile information.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>