JEP-0084: User Avatars in Jabber

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.


JEP Information

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

Author Information

Thomas Muldowney

Email: temas@jabber.org
JID: temas@jabber.org

Peter Millard

Email: me@pgmillard.com
JID: pgmillard@jabber.org

Julian Missig

Email: julian@jabber.org
JID: julian@jabber.org

Legal Notice

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/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

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.

Conformance Terms

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.


Table of Contents

1. Introduction
2. Basic Usage
2.1. Avatar Availability
2.2. Avatar Retrieval
2.3. Publishing an Avatar
3. Detailed Usage
3.1. PubSub and Disco Interaction
3.2. <avatar> Element Description
3.3. Image Requirements
4. Implementation Notes
5. Security Considerations
6. IANA Considerations
7. Jabber Registrar Considerations
8. Formal Definition
8.1. Schema
Notes
Revision History


1. Introduction

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.

2. Basic Usage

2.1 Avatar Availability

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>
      
    

2.2 Avatar Retrieval

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>
      
    

2.3 Publishing an Avatar

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>
      
    

3. Detailed Usage

3.1 PubSub and Disco Interaction

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.

3.2 <avatar> Element Description

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:

All four of these attributes MUST be present when publising an information update, and there MUST NOT be CDATA.

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.

3.3 Image Requirements

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.

4. Implementation Notes

5. Security Considerations

There are no security features or concerns related to this proposal.

6. IANA Considerations

This JEP makes use of IANA-registered MIME types. No further interaction is required with the IANA.

7. Jabber Registrar Considerations

The Jabber Registrar shall register the 'http://jabber.org/protocol/avatar' namespace.

8. Formal Definition

8.1 Schema

      
<?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>
      
    


Notes

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/>.

4. PNG Specification

5. MNG Specification


Revision History

Version 0.4 (2003-05-20)

Lessen the image requirements. Include the mime-type in info. (tjm)

Version 0.3 (2003-05-08)

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. (tjm)

Version 0.2 (2003-05-07)

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. (tjm)

Version 0.1 (2003-05-07)

Initial release (tjm)


END