/
xep-0008.xml
150 lines (148 loc) · 8.59 KB
/
xep-0008.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>IQ-Based Avatars</title>
<abstract>This specification provides historical documentation of an IQ-based protocol for exchanging user avatars.</abstract>
&LEGALNOTICE;
<number>0008</number>
<status>Obsolete</status>
<type>Historical</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
</dependencies>
<supersedes/>
<supersededby>
<spec>XEP-0084</spec>
<spec>XEP-0153</spec>
</supersededby>
<shortname>None</shortname>
&temas;
&xvirge;
<author>
<firstname>Jens</firstname>
<surname>Alfke</surname>
<email>jens@mac.com</email>
</author>
&pgmillard;
<revision>
<version>0.3.1</version>
<date>2022-03-08</date>
<initials>egp</initials>
<remark><ul>
<li>Move from deferred to obsolete.</li>
<li>Add the two superseding specifications.</li>
</ul></remark>
</revision>
<revision>
<version>0.3</version>
<date>2005-06-16</date>
<initials>psa</initials>
<remark>Coincident with publication of XEP-0153, changed type to Historical.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-05-06</date>
<initials>psa</initials>
<remark>At the request of the authors, the status of this document has been changed to Retracted.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2001-09-14</date>
<initials>tm</initials>
<remark>Initial release</remark>
</revision>
</header>
<section1 topic='Introduction'>
<p>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.</p>
</section1>
<section1 topic='Image Requirements'>
<p>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 <note>It is highly recommended that clients never scale up images when displaying them.</note>. 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.</p>
</section1>
<section1 topic='Avatar Availability'>
<p>There are two methods of showing that a client has an avatar available:</p>
<ol>
<li>Embedding the jabber:x:avatar namespace within <presence/> packets using Jabber's <x/> element</li>
<li>Displaying the jabber:iq:avatar namespace in browse requests</li>
</ol>
<p>Partly because Jabber browsing is relatively undeveloped, this proposal focuses on the first option.</p>
<p>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:</p>
<example>
<presence>
<x xmlns='jabber:x:avatar'>
<hash>SHA1 of image data</hash>
</x>
</presence>
</example>
<p>If the avatar-generating user changes the avatar, a new presence packet is sent out with the updated information:</p>
<example>
<presence>
<x xmlns='jabber:x:avatar'>
<hash>SHA1 of new image data</hash>
</x>
</presence>
</example>
<p>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:</p>
<example>
<presence>
<x xmlns='jabber:x:avatar'/>
</presence>
</example>
<p>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:</p>
<example>
<presence/>
</example>
</section1>
<section1 topic='Avatar Retrieval'>
<p>There are two methods for retrieving the actual avatar data:</p>
<ol>
<li>An exchange between clients of <iq/> elements in the jabber:iq:avatar namespace</li>
<li>Public XML storage from the avatar-generating client to the server and public XML retrieval from the server to the avatar-requesting client (see &xep0049;).</li>
</ol>
<p>The first of these methods is preferred. On this model, a query is sent directly to the avatar-generating client using an <iq/> element of type "get" in the jabber:iq:avatar namespace <note>Whenever possible, the avatar-requesting client should attempt to determine if the avatar-generating client has an avatar available before requesting it.</note> <note>It is suggested that no request be made if it is known (such as through a browse reply) that a client does not support the jabber:iq:avatar namespace.</note>:</p>
<example>
<iq id='2' type='get' to='user@server/resource'>
<query xmlns='jabber:iq:avatar'/>
</iq>
</example>
<p>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:</p>
<example>
<iq id='2' type='result' to='user@server/resource'>
<query xmlns='jabber:iq:avatar'>
<data mimetype='image/jpeg'>
Base64-Encoded Data
</data>
</query>
</iq>
</example>
<p>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:</p>
<example>
<iq id='0' type='set' to='user@server'>
<query xmlns='storage:client:avatar'>
<data mimetype='image/jpeg'>
Base64 Encoded Data
</data>
</query>
</iq>
</example>
<p>Once such data has been set, the avatar can be retrieved by any requesting client from the avatar-generating client's public XML storage:</p>
<example>
<iq id='1' type='get' to='user@server'>
<query xmlns='storage:client:avatar'/>
</iq>
</example>
</section1>
<section1 topic='Future Considerations'>
<p>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.</p>
</section1>
<section1 topic='Author Note' anchor='authornote'>
<p>Peter Millard, a co-author of this specification from version 0.1 through version 0.3, died on April 26, 2006.</p>
</section1>
</xep>