This JEP defines a protocol for exchanging user avatars in Jabber/XMPP.
WARNING: Consideration of this JEP has been Deferred by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended.
Status: Deferred
Type: Standards Track
Number: 0084
Version: 0.4
Last Updated: 2003-05-20
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0030, JEP-0060
Supersedes: JEP-0008
Superseded By: None
Short Name: avatar
Email: temas@jabber.org
JID: temas@jabber.org
Email: me@pgmillard.com
JID: pgmillard@jabber.org
Email: julian@jabber.org
JID: julian@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Many communication applications now allow for the association of a small image or buddy icon (avatar) with a user of that application. The avatar is not intended to be a defining portrait of the user, but rather a simple expression of the user's appearance, mood, status, and the like. This proposal outlines a way to incorporate avatars into the current Jabber platform by layering this functionality on top of Publish-Subscribe [1].
Publish-Subscribe was chosen as the base layer for avatars because of the need to publish a large amount of data to any number of users. PubSub provides an easy mechanism for any user to subscribe to the avatar source and receive notifications from the publisher. Furthermore, the publiser only has to send the data once to the pubsub component, and it relays it to all the subscribers.
The protocol defined herein uses two pubsub nodes: one node for "meta-information" about the avatar state (called the "info-node") and one for the avatar data itself (called the "data-node"). This separation of meta-information from data conserves bandwidth and enables both the publisher and the subscriber to cache the avatar data.
Other clients can see if avatar support is available by sending a Service Discovery [2] items request to the other client and looking for the avatar item. The request MUST be sent to the bare JID (<user@host>) of the other user, further specified by a disco node of "http://jabber.org/protocol/avatar". (Sending the request to the bare JID enables one to discover whether an offline user has published disco information regarding avatars).
Example 1. Disco Items Request
<iq
type='get'
from='romeo@montague.net/orchard'
to='juliet@capulet.com'
id='items1'>
<query
xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/avatar'/>
</iq>
The result contains an item with the JID of the pubsub component where the owner's avatar information is published and the specific node for that information:
Example 2. Disco Items Result
<iq
type='result'
from='juliet@capulet.com'
to='romeo@montague.net/orchard'
id='items1'>
<query
xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/avatar'>
<item
jid='pubsub.shakespeare.lit'
node='avatar/info/juliet@capulet.com'/>
</query>
</iq>
The owner of an avatar SHOULD publish their information to the server, so that when the owner is offline the avatar can still be retrieved:
Example 3. Publishing Disco Items
<iq
type='set'
from='juliet@capulet.com/chamber'
id='dset1'>
<query
xmlns="http://jabber.org/protocol/disco#items"
node='http://jabber.org/protocol/avatar'>
<item
jid='pubsub.shakespeare.lit'
node='avatar/info/juliet@capulet.com'
action='update' />
</query>
</iq>
The avatar information is retrieved from the pubsub component. There MUST only be one item in the information node, so we limit the request with max_items:
Example 4. Retrieving the Avatar Information
<iq
type='get'
from='romeo@montague.net/orchard'
to='pubsub.shakespeare.lit'
id='ps-items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='avatar/info/juliet@capulet.com' max_items='1'/>
</pubsub>
</iq>
The item returned contains information about the currently active avatar. Most important is the id attribute, which is also the SHA1 sum of the current avatar image data. This can be used to see if a cached copy is still valid:
Example 5. Result from Avatar Information Request
<iq
type='result'
from='pubsub.shakespeare.lit'
to='romeo@montague.net/orchard''
id='ps-items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='avatar/info/juliet@capulet.com'>
<item>
<avatar
xmlns='http://jabber.org/protocol/avatar'
jid='pubsub.shakespeare.lit'
node='avatar/data/juliet@capulet.com'
mime-type='image/png'
id='a94a8fe5ccb19ba61c4c0873d391e987982fbbd3'/>
</item>
</items>
</pubsub>
</iq>
In order to retrieve the actual avatar image data the JID and node from the avatar information describe the pubsub node to interact with. The retrieval is done for the item id as specified in the avatar information:
Example 6. Retrieving the Current Avatar
<iq
type="get"
from="romeo@montague.net/orchard"
to="pubsub.shakespeare.lit"
id="ps-items2">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="avatar/data/juliet@capulet.com">
<item id='a94a8fe5ccb19ba61c4c0873d391e987982fbbd3'/>
</items>
</pubsub>
</iq>
The result contains the avatar image data. The format of the element is described in detail below:
Example 7. Retrieval Result
<iq type="result" from="pubsub.shakespeare.lit" id="ps-items2">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="avatar/data/juliet@capulet.com">
<item id="a94a8fe5ccb19ba61c4c0873d391e987982fbbd3">
<avatar
xmlns="http://jabber.org/protocol/avatar"
mime-type='image/png'>
qANQR1DBwU4DX7jmYZnncm...
</avatar>
</item>
</items>
</pubsub>
</iq>
Whenever the owner wishes to change the current avatar, the info-node MUST be updated. If the actual image has not been previously published, it also MUST be published to the data-node before the info-node is changed.
Example 8. Publishing Avatar Data
<iq
type="set"
from="juliet@capulet.com/orchard"
to="pubsub.shakespeare.lit"
id="publish1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="avatar/data/juliet@capulet.com">
<item id="109f4b3c50d7b0df729d299bc6f8e9ef9066971f">
<avatar
xmlns="http://jabber.org/protocol/avatar"
mime-type="image/png">
qANQR1DBwU4DX7jmYZnncm...
</avatar>
</item>
</publish>
</pubsub>
</iq>
The result from the pubsub component:
Example 9. Data Publish Result
<iq
type="result"
from="pubsub.shakespeare.lit"
to="juliet@capulet.com/chamber"
id="publish1"/>
Finally the avatar info-node must be updated. The <avatar> id attribute MUST be the same as the item id stored previously:
Example 10. Publishing Avatar Information
<iq
type='set'
from='juliet@capulet.com/orchard'
to='pubsub.shakespeare.lit'
id='publish2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='avatar/info/juliet@capulet.com'>
<item id='current'>
<avatar
xmlns='http://jabber.org/protocol/avatar'
jid='pubsub.shakespeare.lit'
node='avatar/data/juliet@capulet.com'
mime-type='image/png'
id='109f4b3c50d7b0df729d299bc6f8e9ef9066971f' />
</item>
</publish>
</pubsub>
</iq>
Subscribers to the avatar would then receive an update from the info-node:
Example 11. Receiving a Published Avatar
<message to="romeo@montague.net" from="pubsub.shakespeare.lit">
<x xmlns="http://jabber.org/protocol/pubsub#event">
<items node="avatar/info/juliet@capulet.com">
<item id="current">
<avatar
xmlns="http://jabber.org/protocol/avatar"
jid='pubsub.shakespeare.lit'
node='avatar/data/juliet@capulet.com'
mime-type='image/png'
id='109f4b3c50d7b0df729d299bc6f8e9ef9066971f' />
</item>
</items>
</x>
</message>
In order to temporarily disable the avatar an empty <avatar/> node is published to the info-node:
Example 12. Temporarily Disabling an Avatar
<iq
type="set"
from="juliet@capulet.com/orchard"
to="pubsub.shakespeare.lit"
id="publish3">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="avatar/info/juliet@capulet.com">
<item id="current">
<avatar xmlns="http://jabber.org/protocol/avatar"/>
</item>
</publish>
</pubsub>
</iq>
The avatar info-node that is used on the pubsub component for all interaction MUST be created by the avatar owner as described in JEP-0060. The node identifier is then used for all updates and in the disco items retrieval.
Once the pubsub node is created with the component, it MUST be listed in disco item results for the node "http://jabber.org/protocol/avatar". The node SHOULD also be published via disco to the avatar owner's server so that it is available even when the owner is offline.
The <avatar> element is the root and only element in the http://jabber.org/protocol/avatar namespace. It has three forms, first is:
<avatar xmlns='http://jabber.org/protocol/avatar'/>
This is only used when disabling an avatar. The second format is more common:
<avatar
xmlns='http://jabber.org/protocol/avatar'
jid='pubsub.shakespeare.lit'
node='avatar/data/juliet@capulet.com'
id='109f4b3c50d7b0df729d299bc6f8e9ef9066971f' />
This is the format used to publish an information update. The attributes of the node are:
The final format of the avatar data-node is the carrier of the data:
<avatar
xmlns='http://jabber.org/protocol/avatar'
mime-type='image/png'>
BASE 64 DATA
</avatar>
This is the main carrier of the image data. The mime-type MUST be one of the following MIME types as registered with the Internet Assigned Numbers Authority (IANA) [3]:
image/png support is REQUIRED, image/jpeg and image/gif SHOULD be implemented, all other formats are OPTIONAL.Other formats MAY be used, but interoperability is unsure at that point.
The CDATA of the <avatar> MUST be the Base64 encoded image data. If the CDATA for the image data is present, the 'mime-type' attribute MUST be included.
Certain restrictions are placed upon the image. First, the image height and width MUST be between thirty-two (32) and sixty-four (64) pixels. The suggested size is sixty-four (64) pixels high and sixty-four (64) pixels wide. Images SHOULD be square, but this is not required. Images SHOULD be in PNG or MNG format, although it is more formats will be allowed in the future. Finally, images MUST use less than eight (8) kilobytes of data.
There are no security features or concerns related to this proposal.
This JEP makes use of IANA-registered MIME types. No further interaction is required with the IANA.
The Jabber Registrar shall register the 'http://jabber.org/protocol/avatar' namespace.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/avatar'
xmlns='http://jabber.org/protocol/avatar'
elementFormDefault='qualified'>
<xs:element name='avatar'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name='mime-type' type='xs:string' use='optional'/>
<xs:attribute name='jid' type='xs:string' use='optional'/>
<xs:attribute name='node' type='xs:string' use='optional'/>
<xs:attribute name='id' type='xs:string' use='optional'/>
</xs:extension>
</xsd:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
1. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
2. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
3. 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/>.
END