WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state. Implementation of the protocol described herein is not recommended for production systems. However, exploratory implementations are encouraged to resume the standards process.

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.

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 [1]. Images should be square, but this is not required. Images should be in GIF, JPEG, or PNG format, although it is possible that in future revisions of this spec more formats will be allowed. Finally, images must use less than eight (8) kilobytes of data.

Partly because Jabber browsing is relatively undeveloped, this proposal focuses on the first option.

The <x/> element in the jabber:x:avatar namespace contains a SHA1 hash (hexadecimal, not base64) of the image data itself (not the base64-encoded version) in a <hash/> element. (Because the odds of creating an identical hash are small, the hash is considered unique to the image and can be used to cache images between client sessions, resulting in fewer requests for the image.) The initial announcement of the availability of an avatar is done by sending a presence packet with the jabber:x:avatar information, as follows:

To disable the avatar, the avatar-generating user's client will send a presence packet with the jabber:x:avatar namespace but with no hash information:

Example 3.

<presence>
<x xmlns='jabber:x:avatar'/>
</presence>

Clients should send the current avatar hash in every <presence/> packet even if the avatar has not changed. Remember that other clients logging in will receive a copy of the most recent <presence/> element, which should therefore always contain the most recent avatar hash. However, if the client's connection is lost unexpectedly or the client disconnects without sending an unavailable presence, the server will send other clients a <presence/> element containing no jabber:x:avatar extension. Therefore if, after receiving one or more presence packets containing jabber:x:avatar information, an avatar-receiving client receives a presence packet that does not include the jabber:x:avatar namespace, it is recommended that the client save the avatar image until the next set of information is received. In this case the avatar-generating client might send something as simple as the following:

The avatar-generating client will reply with an <iq/> element of type "result" in the jabber:iq:avatar namespace; this reply will contain a query element that in turn contains a <data/> element with the MIME type in the 'mimetype' attribute and the data base64-encoded in the body of the <data/> element:

If the first method fails, the second method that should be attempted by sending a request to the server for the avatar-generating user's public XML containing the avatar data. This data is to be stored in the storage:client:avatar namespace. This method presumes that the avatar-generating client has already stored its avatar data on the server:

It is acknowledged that sending avatar information within presence packets is less than desirable in many respects (e.g., in network traffic generated); however, there currently exists in Jabber no generic framework for addressing these shortcomings. Possible solutions on the horizon include live browsing and a pub/sub model, but these are still embryonic and experimental. Once something of that nature is accepted by the Council, the avatar spec will be modified to work within that framework rather than by attaching to presence.

Jens Alfke

Peter Millard

Appendix C: 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. ##

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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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 can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Appendix F: Requirements Conformance

The following requirements 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".

Appendix G: Notes

1. It is highly recommended that clients never scale up images when displaying them.