XEP-0084: User Avatar

This document defines an XMPP protocol extension for exchanging user avatars, which are small images or icons associated with human users. The protocol specifies payload formats for both avatar metadata and the image data itself. The payload formats are typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163.

NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

Document Information

Author Information

Legal Notices

Copyright

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Discussion Venue

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 XMPP Standards 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 document 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 following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

1. Introduction
2. Requirements
3. Basic Process Flow
    3.1. User Publishes Data
    3.2. User Publishes Metadata Notification
    3.3. Subscribers Receive Metadata Notification
    3.4. Subscribers Retrieve Data
    3.5. Publisher Disables Avatar Publishing
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. Implementation Notes
    7.1. Multiple Resources
    7.2. Avatar Synchronization
    7.3. Image Handling
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
    10.1. Protocol Namespaces
11. XML Schema
    11.1. Data Namespace
    11.2. Metadata Namespace
12. 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 defines 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 ("PEP"), 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 or receive 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).

It is intended that this specification will supersede both IQ-Based Avatars [6] and vCard-Based Avatars [7] once the PEP subset of XMPP publish-subscribe is implemented and deployed widely enough.

2. Requirements

3. Basic Process Flow

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 XEP-0163, since such support simplifies avatar publication. The following examples assume the availability of a PEP service.

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

The following example illustrates the XML structure to be sent when publishing avatar data to the data node.

Example 1. Publishing avatar data to data node

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

Example 2. Pubsub service replies with success

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

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

3.2 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 3. Publishing avatar metadata

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

The following example shows metadata specifying avatar data that is available at an HTTP URL.

Example 4. Publishing avatar metadata

<iq type='set' from='juliet@capulet.lit/chamber' id='publish2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:avatar:metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='urn:xmpp:avatar:metadata'>
          <info bytes='23456'
                height='64'
                id='222f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/gif'
                url='http://avatars.example.org/happy.gif'
                width='64'/>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

3.3 Subscribers Receive Metadata Notification

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 Entity Capabilities [8] feature of "urn:xmpp:avatar:metadata+notify".

Example 5. Subscribers receive avatar metadata notification

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

As shown, depending on node configuration, the item may include Extended Stanza Addressing [9] information about the publishing resource (see XEP-0060 for details).

3.4 Subscribers Retrieve Data

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.

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.

Example 6. Subscriber requests last item by ItemID

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

The PEP service running at the user's server then SHOULD return the avatar data.

Example 7. PEP service returns avatar data

<iq type='result' 
    from='juliet@capulet.lit' 
    to='romeo@montague.lit/home' 
    id='retrieve1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:avatar:data'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <data xmlns='urn:xmpp:avatar:data'>
          qANQR1DBwU4DX7jmYZnncm...
        </data>
      </item>
    </items>
  </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 specification (see RFC 2616).

3.5 Publisher Disables Avatar Publishing

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

Example 8. Temporarily disabling an avatar

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

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

Example 9. Subscribers receive avatar metadata notification

<message to='romeo@montague.lit' from='juliet@capulet.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:avatar:metadata'>
      <item>
        <metadata xmlns='urn:xmpp:avatar:metadata'>
          <stop/>
        </metadata>
      </item>
    </items>
  </event>
  <addresses xmlns='http://jabber.org/protocol/address'>
    <address type='replyto' jid='juliet@capulet.lit/chamber'/>
  </addresses>
</message>

4. Protocol Syntax

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:

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='urn:xmpp: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 4 of RFC 4648 [10]. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)

The <data/> element MUST NOT possess any attributes.

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:

<info/>
<pointer/>
<stop/>

These are further specified below.

4.2.1 Info Element

The <info/> child element is used to communicate avatar metadata. Support for the <info/> element is REQUIRED.

<metadata xmlns='urn:xmpp:avatar:metadata'>
  <info bytes='size-of-image-data-in-bytes'
        height='image-height-in-pixels'
        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>

The <info/> child element MUST be empty.

The defined attributes of the <info/> element are specified in the following table.

Table 1: Info Attributes

Name	Definition	Inclusion
bytes	The size of the image data in bytes.	REQUIRED
height	The height of the image in pixels.	RECOMMENDED
id	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 RFC 3174 [11] (with binary output).	REQUIRED
type	The IANA-registered content type of the image data.	REQUIRED
url	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.	OPTIONAL
width	The width of the image in pixels	RECOMMENDED

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". [12] 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.

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.

<metadata xmlns='urn:xmpp:avatar:metadata'>
  <pointer>
    ... APPLICATION-SPECIFIC DATA ...
  </pointer>
</metadata>

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

bytes -- The size of the image data in bytes.
height -- The height of the image in pixels.
id -- The SHA-1 hash of the image data for the specified content-type.
type -- The IANA-registered content type of the image data.
width -- The width of the image in pixels.

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='urn:xmpp: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 10. Publishing avatar metadata (multiple formats)

<iq type='set' from='juliet@capulet.lit/chamber' id='publish3'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:avatar:metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='urn:xmpp:avatar:metadata'>
          <info bytes='12345'
                height='64'
                id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/png'
                width='64'/>
          <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'
                url='http://avatars.example.org/happy.gif'
                width='64'/>
          <info bytes='78912'
                height='64'
                id='333f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/mng'
                url='http://avatars.example.org/happy.mng'
                width='64'/>
        </metadata>
      </item>
    </publish>
  </pubsub>
</iq>

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

5.2 Metadata With Pointer

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.

Example 11. Publishing avatar metadata (with pointer)

<iq type='set' from='juliet@capulet.lit/chamber' id='publish4'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:avatar:metadata'>
      <item id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'>
        <metadata xmlns='urn:xmpp:avatar:metadata'>
          <info bytes='12345'
                height='64'
                id='111f4b3c50d7b0df729d299bc6f8e9ef9066971f'
                type='image/png'
                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

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 Service Discovery [13] items ("disco#items") request to the user's bare JID <localpart@domain.tld>.

Example 12. Disco items request

<iq type='get'
    from='romeo@montague.lit/orchard'
    to='juliet@capulet.lit'
    id='items1'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

If the user publishes avatar data to an PEP node, the result MUST contain the appropriate items.

Example 13. Disco items result

<iq type='result'
    from='juliet@capulet.lit'
    to='romeo@montague.lit/orchard'
    id='items1'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='juliet@capulet.lit' node='urn:xmpp:avatar:data'/>
    <item jid='juliet@capulet.lit' node='urn:xmpp:avatar:metadata'/>
  </query>
</iq>

The contact then MAY subscribe to the metadata node following the protocol specified in XEP-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. Implementation Notes

7.1 Multiple Resources

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.

7.2 Avatar Synchronization

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 XEP-0115) or using the "retrieve-items" method described in XEP-0060.

7.3 Image Handling

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

The receiving application SHOULD NOT scale up an image when displaying it.

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 vcard-temp [14]) or other profile information.

8. Security Considerations

See XEP-0060 and XEP-0163 regarding security considerations related to the underlying transport protocol.

It is possible that output of the SHA-1 hashing algorithm can result in collisions; however, the use of SHA-1 in producing a hash of the avatar data is not security-critical.

9. IANA Considerations

10. XMPP Registrar Considerations

10.1 Protocol Namespaces

The XMPP Registrar [16] includes "urn:xmpp:avatar:data" and "urn:xmpp:avatar:metadata" in its registry of protocol namespaces (see <http://www.xmpp.org/registrar/namespaces.html>).

11. XML Schema

11.1 Data Namespace

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

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

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0084: http://www.xmpp.org/extensions/xep-0084.html
    </xs:documentation>
  </xs:annotation>

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

</xs:schema>

11.2 Metadata Namespace

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

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

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0084: http://www.xmpp.org/extensions/xep-0084.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='metadata'>
    <xs:complexType>
      <xs:choice>
        <xs:sequence minOccurs='0' maxOccurs='1'>
          <xs:element ref='info' minOccurs='1' 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:unsignedShort' use='required'/>
          <xs:attribute name='height' type='xs:unsignedByte' use='optional'/>
          <xs:attribute name='id' type='xs:string' use='required'/>
          <xs:attribute name='type' type='xs:string' use='required'/>
          <xs:attribute name='url' type='xs:anyURI' use='optional'/>
          <xs:attribute name='width' type='xs:unsignedByte' use='optional'/>
        </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>

12. Author Note

Peter Millard, a co-author of this specification from version 0.1 through version 0.7, died on April 26, 2006. The remaining authors are thankful for his work on user avatars.

Notes

1. XEP-0060: Publish-Subscribe <http://www.xmpp.org/extensions/xep-0060.html>.

2. XEP-0163: Personal Eventing via Pubsub <http://www.xmpp.org/extensions/xep-0163.html>.

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

4. RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://tools.ietf.org/html/rfc2616>.

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

6. XEP-0008: IQ-Based Avatars <http://www.xmpp.org/extensions/xep-0008.html>.

7. XEP-0153: vCard-Based Avatars <http://www.xmpp.org/extensions/xep-0153.html>.

8. XEP-0115: Entity Capabilities <http://www.xmpp.org/extensions/xep-0115.html>.

9. XEP-0033: Extended Stanza Addressing <http://www.xmpp.org/extensions/xep-0033.html>.

10. RFC 4648: The Base16, Base32, and Base64 Data Encodings <http://tools.ietf.org/html/rfc4648>.

11. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>.

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

Document Information

Author Information

Peter Saint-Andre

Peter Millard

Thomas Muldowney

Julian Missig