JEP-0084: User Avatar

This document defines an XMPP protocol extension for exchanging user avatars.

WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

JEP Information

Status: Experimental
Type: Standards Track
Number: 0084
Version: 0.7
Last Updated: 2006-01-17
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0030, JEP-0060, JEP-0163
Supersedes: JEP-0008
Superseded By: None
Short Name: avatar
Wiki Page: <http://wiki.jabber.org/index.php/User Avatar (JEP-0084)>

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Peter Millard

See Author Note

Thomas Muldowney

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

Julian Missig

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

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 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.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

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 (RFC 3920) and XMPP IM (RFC 3921) 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 protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension 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. Requirements
3. Basic Process Flow
3.1. User Creates Metadata Node
3.2. User Creates Data Node
3.3. User Publishes Data
3.4. User Publishes Metadata Notification
3.5. Subscribers Receive Metadata Notification
3.6. Subscribers Retrieve Data
3.7. Publisher Disables Avatars
4. Protocol Syntax
4.1. Data Element
4.2. Metadata Element
4.2.1. Info Element
4.2.2. Pointer Element
4.2.3. Stop Element
5. Additional Examples
5.1. Metadata With Multiple Content-Types
5.2. Metadata With Pointer
6. Service Discovery
6.1. Discovering Avatar Availability
7. Business Rules
7.1. Image Requirements
8. Implementation Notes
9. Security Considerations
10. IANA Considerations
11. Jabber Registrar Considerations
11.1. Protocol Namespaces
12. XML Schema
12.1. Data Namespace
12.2. Metadata Namespace
13. Author Note
Notes
Revision History

1. Introduction

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 Publish-Subscribe [1] extension ("pubsub"), specifically the Personal Eventing via Pubsub [2] subset ("SPPS"), which is designed for use in the context of XMPP instant messaging and presence systems that conform to RFC 3921 [3].

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 the full image each time.)

This protocol also allows storage of avatar data at a URL accessible via HTTP (see RFC 2616 [4]). [5] 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.

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

2. Requirements

This document addresses the following use cases for avatar publishers:

  1. Publishing avatar data
  2. Updating metadata about the current avatar
  3. Disabling avatars

This document addresses the following use cases for avatar subscribers:

  1. Discovering avatar availability
  2. Receiving notification of avatar changes
  3. Retrieving avatar data via pubsub
  4. Retrieving avatar data via HTTP

3. Basic Process Flow

The process for publishing and updating user avatars is as follows:

  1. User creates metadata node
  2. User creates data node for "image/png" content-type
  3. User publishes avatar data for "image/png" content-type to data node and optionally publishes other content-types to HTTP URLs
  4. 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)
  5. Subscribers receive notification
  6. Optionally (and if necessary), subscribers retrieve avatar data identified by ItemID from data node using pubsub get-items feature (or via HTTP)
  7. Optionally, user disables avatar display.

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 SPPS subset of pubsub by following the procedures specified in JEP-0163.

3.1 User Creates Metadata Node

In order to publish notifications related to its avatar, the user MUST first create a node for his or her avatar metadata:

Example 1. Pubsub metadata node creation request

<iq type='set' from='juliet@capulet.com/chamber' id='create1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node='http://jabber.org/protocol/avatar#metadata' access='presence'/>
    <configure/>
  </pubsub>
</iq>

The NodeID MUST be "http://jabber.org/protocol/avatar#metadata" and the access model SHOULD be "presence".

Example 2. Pubsub service replies with success

<iq type='result' to='juliet@capulet.com/chamber' id='create1'/>

3.2 User Creates Data Node

Next, the user MUST create a node for his or her avatar data:

Example 3. Pubsub data node creation request

<iq type='set' from='juliet@capulet.com/chamber' id='create2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node='http://jabber.org/protocol/avatar#data' access='presence'/>
    <configure/>
  </pubsub>
</iq>

The NodeID MUST be "http://jabber.org/protocol/avatar#data" and the access model SHOULD be "presence".

Example 4. Pubsub service replies with success

<iq type='result' to='juliet@capulet.com/chamber' id='create2'/>

3.3 User Publishes Data

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.

Example 5. Publishing avatar data to data node

<iq type='set' from='juliet@capulet.com/chamber' id='publish1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/avatar#data'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <data xmlns='http://jabber.org/protocol/avatar#data'>
          qANQR1DBwU4DX7jmYZnncm...
        </data>
      </item>
    </publish>
  </pubsub>
</iq>

Example 6. Pubsub service replies with success

<iq type='result' to='juliet@capulet.com/chamber' id='publish1'/>

3.4 User Publishes Metadata Notification

Whenever the publisher wishes to change its current avatar, it MUST update the metadata node.

The following example shows metadata specifying avatar data that is available in only one format ("image/png") and accessible only at the data node:

Example 7. Publishing avatar metadata

<iq type='set' from='juliet@capulet.com/chamber' id='publish2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/avatar#metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='http://jabber.org/protocol/avatar#metadata'>
          <info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/png'
                bytes='12345'
                height='64'
                width='64'/>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

3.5 Subscribers Receive Metadata Notification

Subscribers to the metadata node would then receive the notification:

Example 8. Subscribers receive avatar metadata notification

<message to='romeo@montague.net' from='juliet@capulet.com/chamber'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='http://jabber.org/protocol/avatar#metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='http://jabber.org/protocol/avatar#metadata'>
          <info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/png'
                bytes='12345'
                height='64'
                width='64'/>
        </metadata>
      </item>
    </items>
  </event>
</message>

3.6 Subscribers Retrieve Data

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.

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 get-items request to the data node, specifying the appropriate ItemID:

Example 9. Subscriber requests last item by ItemID

<iq type='get'
    from='romeo@montague.net/home'
    to='juliet@capulet.com'
    id='retrieve1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='http://jabber.org/protocol/avatar#metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
    </items>
  </pubsub>
</iq>

The SPPS service running at the user's server then SHOULD return the avatar data:

Example 10. Publishing avatar data to data node

<iq type='result' from='juliet@capulet.com' to='romeo@montague.net/home' id='publish1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/avatar#data'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <data xmlns='http://jabber.org/protocol/avatar#data'>
          qANQR1DBwU4DX7jmYZnncm...
        </data>
      </item>
    </publish>
  </pubsub>
</iq>

If the <info/> 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.

3.7 Publisher Disables Avatars

In order to temporarily disable any avatar, the user publishes an empty <stop/> element to the metadata node (this item SHOULD NOT possess an ItemID):

Example 11. Temporarily disabling an avatar

<iq type='set' from='juliet@capulet.com/chamber' id='publish3'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='avatar/info/juliet@capulet.com'>
      <item>
        <metadata xmlns='http://jabber.org/protocol/avatar#metadata'>
          <stop/>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

As before, subscribers to the metadata node would then receive the notification:

Example 12. Subscribers receive avatar metadata notification

<message to='romeo@montague.net' from='juliet@capulet.com/chamber'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='http://jabber.org/protocol/avatar#metadata'>
      <item>
        <metadata xmlns='http://jabber.org/protocol/avatar#metadata'>
          <stop/>
        </metadata>
      </item>
    </items>
  </event>
</message>

4. Protocol Syntax

The SPPS 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.

4.1 Data Element

The <data/> element is used to communicate the avatar data itself, and only for the "image/png" content-type (support for which is REQUIRED):

<data xmlns='http://jabber.org/protocol/avatar#data'>
  IMAGE DATA
</data>

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 3 of RFC 3548 [6]. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)

Support for the <data/> element is REQUIRED.

4.2 Metadata Element

The <metadata/> element is used to communicate information about the avatar. There are three allowable children of the <metadata/> element:

These are further specified below.

4.2.1 Info Element

The <info/> child element is used to communicate avatar metadata:

<metadata xmlns='http://jabber.org/protocol/avatar#metadata'
  <info id='SHA1-hash-of-image-data'
        url='HTTP-URL-for-image-data'
        id='SHA1-hash-of-image-data'
        type='content-type-of-image-data'
        bytes='size-of-image-data-in-bytes'
        height='image-height-in-pixels'
        width='image-width-in-pixels'/>
</metadata>

The <info/> child element MUST be empty.

The <info/> child element MUST possess the following attributes:

The <info/> element MAY possess the following attribute:

The <metadata/> root element MAY contain more than one <info/> element. Each <info/> 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". [7] 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.

The value of the 'id' attribute MUST be the SHA1 (RFC 3174 [8]) hash of the image data for the specified content-type.

Support for the <info/> element is REQUIRED.

4.2.2 Pointer Element

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:

<avatar xmlns='http://jabber.org/protocol/avatar'>
  <pointer>
    ... APPLICATION-SPECIFIC DATA ...
  </pointer>
</avatar>

The <pointer/> element MAY possess the following attributes if the publishing application has the relevant information:

The content of the <pointer/> element MUST be a properly-namespaced child element that specifies information about how to retrieve the avatar from the third-party service. The structure for any such child element is out of scope for this document.

Even if the <pointer> element is included, it MUST be preceded by at least one instance of the <info/> element so that implementations that do not support the <pointer/> element can display a "fallback" format of the avatar (at a minimum, "image/png").

Support for the <pointer/> element is OPTIONAL.

4.2.3 Stop Element

The <stop/> child element is used to signal that avatar publishing has been disabled:

<metadata xmlns='http://jabber.org/protocol/avatar#metadata'>
  <stop/>
</metadata>

The <stop/> element MUST be empty and MUST NOT possess any attributes.

Support for the <stop/> element is REQUIRED.

5. Additional Examples

5.1 Metadata With Multiple Content-Types

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:

Example 13. Publishing avatar metadata (multiple formats)

<iq type='set' from='juliet@capulet.com/chamber' id='publish3'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/avatar#metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='http://jabber.org/protocol/avatar#metadata'>
          <info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/png'
                bytes='12345'
                height='64'
                width='64'/>
          <info id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                url='http://avatars.jabberstudio.org/happy.gif'
                type='image/gif'
                bytes='23456'
                height='64'
                width='64'/>
          <info id='333f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                url='http://avatars.jabberstudio.org/happy.mng'
                type='image/mng'
                bytes='78912'
                height='64'
                width='64'/>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

5.2 Metadata With Pointer

The following example shows metadata specifying avatar data that is available in "image/png" and also with a pointer to an external service.

Example 14. Publishing avatar metadata (with pointer)

<iq type='set' from='juliet@capulet.com/chamber' id='publish4'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='http://jabber.org/protocol/avatar#metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='http://jabber.org/protocol/avatar#metadata'>
          <info id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/png'
                bytes='12345'
                height='64'
                width='64'/>
          <pointer>
            <x xmlns='http://example.com/virtualworlds'>
              <game>Ancapistan</game>
              <character>Kropotkin</character>
            </x>
          </pointer>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

6. Service Discovery

6.1 Discovering Avatar Availability

A contact can determine if another user publishes avatars using this protocol by sending a Service Discovery [9] items ("disco#items") request to the user's bare JID (<node@domain.tld>):

Example 15. 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'/>
</iq>

If the user publishes avatar data to an SPPS node, the result MUST contain the appropriate items:

Example 16. 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'>
    <item jid='juliet@capulet.com' node='http://jabber.org/protocol/avatar#data'/>
    <item jid='juliet@capulet.com' node='http://jabber.org/protocol/avatar#metadata'/>
  </query>
</iq>

The contact then may subscribe to the metadata node following the protocol specified in JEP-0060. However, the contact SHOULD NOT subscribe to the data node (instead, it SHOULD simply retrieve items from that node when needed, as described above).

7. Business Rules

7.1 Image Requirements

Certain restrictions are placed upon the image. First, the image height and width SHOULD be between thirty-two (32) and ninety-six (96) 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. Finally, images SHOULD use less than eight (8) kilobytes of data.

8. Implementation Notes

9. Security Considerations

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

10. IANA Considerations

This document makes use of IANA-registered content types, but requires no interaction with the Internet Assigned Numbers Authority (IANA) [11].

11. Jabber Registrar Considerations

11.1 Protocol Namespaces

The Jabber Registrar [12] shall include 'http://jabber.org/protocol/avatar#data' and 'http://jabber.org/protocol/avatar#metadata' in its registry of protocol namespaces.

12. XML Schema

12.1 Data Namespace 

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/avatar#metadata'
    xmlns='http://jabber.org/protocol/avatar#metadata'
    elementFormDefault='qualified'>

  <xs:element name='data' type='xs:base64Binary'>

</xs:schema>

12.2 Metadata Namespace 

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/avatar#metadata'
    xmlns='http://jabber.org/protocol/avatar#metadata'
    elementFormDefault='qualified'>

  <xs:element name='metadata'>
    <xs:complexType>
      <xs:choice>
        <xs:sequence>
          <xs:element ref='info' maxOccurs='unbounded'/>
          <xs:element ref='pointer' minOccurs='0' maxOccurs='unbounded'/>
        </xs:sequence>
        <xs:element name='stop' type='empty'/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

  <xs:element name='info'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='bytes' type='xs:string' use='required'/>
          <xs:attribute name='type' type='xs:string' use='required'/>
          <xs:attribute name='height' type='xs:string' use='required'/>
          <xs:attribute name='id' type='xs:string' use='required'/>
          <xs:attribute name='url' type='xs:string' use='optional'/>
          <xs:attribute name='width' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='pointer'>
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace='##other'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

13. Author Note

Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006.

Notes

1. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.

2. JEP-0163: Personal Eventing via Pubsub <http://www.jabber.org/jeps/jep-0163.html>.

3. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

4. RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>.

5. By "accessible via HTTP" is meant that the data is available at an http: or https: URI.

6. RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://www.ietf.org/rfc/rfc3548.txt>.

7. The IANA registry of content types is located at <http://www.iana.org/assignments/media-types/>.

8. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://www.ietf.org/rfc/rfc3174.txt>.

9. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

10. JEP-0054: vcard-temp <http://www.jabber.org/jeps/jep-0054.html>.

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

12. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

Revision History

Version 0.7 (2006-01-17)

Updated to use Simplified Personal Publish-Subscribe. (psa)

Version 0.6 (2005-04-13)

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

Version 0.5 (2005-03-28)

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. (psa/pgm)

Version 0.4 (2003-05-20)

Lessen the image requirements. Include the content 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 version. (tjm)

END