<p>The following issues must be solved for in this specification.</p>
<ul>
<li><b>Here and Now</b>: The convention should not rely on technologies such as feature negotiation or generic pub/sub which do not exist yet in Jabber in order to work properly. The convention should be a "here and now" solution, relying only on the current Jabber protocol.</li>
<li><b>Meaningful</b>: The convention for creating the icons must be meaningful to users of clients without icon support, or even users on the other side of transports. Whatever method is used, it should not be cryptic or difficult to understand in text-only mode, in case the user does not have or want the capability to view the icons.</li>
<li><b>Component Friendly</b>: In order for gateways, bots, and other "semi-intelligent" components to be able to convert or otherwise use the specification (such as to and from the MSN icon style, or use icons in conversations with Artificially Intelligent bots), a specific list of icons must be possible. Since these bots do not have an intelligent human behind them deciding their every action, they cannot deal with unlimited possibilities.</li>
<li><b>Protect Privacy</b>: Sender-defined external data must not be required to properly display the icons because it can be used by the sender to track the user, circumventing their privacy. When the sender can define their own graphics or sounds to be used for the icons, they can use unique URLs and monitor when these unique URLs are accessed. External data may be allowed as long as it is not required for proper use of the icons, but it would be best to leave external data completely out of the system.</li>
<li><b>Conserve Bandwidth</b>: The amount of markup used within the messages to define the icons should be kept to a minimum, as well as keeping the media files used for the icons from being transferred over the wire with the messages themselves. These easily consume too much bandwidth, a precious resource to most of the Internet.</li>
<li><b>Be Passive</b>: The convention should not force transports or recipients to take any action to properly display the icons. Not only does it put extra strain on the components, but it would also unnecessarily break old clients. Transports and recieving clients may have the option of taking some actions, but they should not be forced to.</li>
<li><b>Internationalization</b>: The convention must be inherently international in order to ease adoption of Jabber throughout the world and prevent later growing pains. The use of English must be kept to a minimum, restricted to "meta information" about the icons themselves, and must dynamically allow for non-English language sets.</li>
<li><strong>Here and Now</strong>: The convention should not rely on technologies such as feature negotiation or generic pub/sub which do not exist yet in Jabber in order to work properly. The convention should be a "here and now" solution, relying only on the current Jabber protocol.</li>
<li><strong>Meaningful</strong>: The convention for creating the icons must be meaningful to users of clients without icon support, or even users on the other side of transports. Whatever method is used, it should not be cryptic or difficult to understand in text-only mode, in case the user does not have or want the capability to view the icons.</li>
<li><strong>Component Friendly</strong>: In order for gateways, bots, and other "semi-intelligent" components to be able to convert or otherwise use the specification (such as to and from the MSN icon style, or use icons in conversations with Artificially Intelligent bots), a specific list of icons must be possible. Since these bots do not have an intelligent human behind them deciding their every action, they cannot deal with unlimited possibilities.</li>
<li><strong>Protect Privacy</strong>: Sender-defined external data must not be required to properly display the icons because it can be used by the sender to track the user, circumventing their privacy. When the sender can define their own graphics or sounds to be used for the icons, they can use unique URLs and monitor when these unique URLs are accessed. External data may be allowed as long as it is not required for proper use of the icons, but it would be best to leave external data completely out of the system.</li>
<li><strong>Conserve Bandwidth</strong>: The amount of markup used within the messages to define the icons should be kept to a minimum, as well as keeping the media files used for the icons from being transferred over the wire with the messages themselves. These easily consume too much bandwidth, a precious resource to most of the Internet.</li>
<li><strong>Be Passive</strong>: The convention should not force transports or recipients to take any action to properly display the icons. Not only does it put extra strain on the components, but it would also unnecessarily break old clients. Transports and recieving clients may have the option of taking some actions, but they should not be forced to.</li>
<li><strong>Internationalization</strong>: The convention must be inherently international in order to ease adoption of Jabber throughout the world and prevent later growing pains. The use of English must be kept to a minimum, restricted to "meta information" about the icons themselves, and must dynamically allow for non-English language sets.</li>
</ul>
<p>Because icons in Jabber should be easy to use, extensible, and customizable, they will be created using style definition files which can be exchanged between users and supporting clients. The specification will not allow external data, in order to protect the privacy of users, and will not rely on file transfers or directory services in order to not break old clients or components.</p>
</section1>
@ -92,12 +91,12 @@
@@ -92,12 +91,12 @@
<section2topic="Meta Elements">
<p>The meta elements contain information about the Icon Style itself, rather that the individual icons. They are contained within the <tt><meta></tt> element, which is directly under the root element. There is one and only one the <tt><meta></tt> element.</p>
<ul>
<li><b>Name</b>: This is an arbitrary text string (spaces allowed) which is the full name of the Icon Style. Only one name can be included.</li>
<li><b>Version</b>: This is an arbitrary text string (no spaces allowed) which is the version number of the Icon Style. Any version format is allowed, but the <tt>major.minor</tt> or <tt>major.minor.trivial</tt> formats are recommended. Only one version can be included.</li>
<li><b>Description</b>: This is the full description of the Icon Style. It summarizes the look and types of the icons, and can be used for keywords in searching. This is optional, but recommended.</li>
<li><b>Author</b>: This is the full name of the author. Multiple authors are allowed.</li>
<li><b>Creation</b>: This is the date of the creation of this version of the Icon Style. The date is in the <linkurl="http://www.w3.org/TR/NOTE-datetime">ISO 8601</link> standard format.</li>
<li><b>Home</b>: This is the full HTTP web address of the Icon Style's homepage. This is optional.</li>
<li><strong>Name</strong>: This is an arbitrary text string (spaces allowed) which is the full name of the Icon Style. Only one name can be included.</li>
<li><strong>Version</strong>: This is an arbitrary text string (no spaces allowed) which is the version number of the Icon Style. Any version format is allowed, but the <tt>major.minor</tt> or <tt>major.minor.trivial</tt> formats are recommended. Only one version can be included.</li>
<li><strong>Description</strong>: This is the full description of the Icon Style. It summarizes the look and types of the icons, and can be used for keywords in searching. This is optional, but recommended.</li>
<li><strong>Author</strong>: This is the full name of the author. Multiple authors are allowed.</li>
<li><strong>Creation</strong>: This is the date of the creation of this version of the Icon Style. The date is in the <linkurl="http://www.w3.org/TR/NOTE-datetime">ISO 8601</link> standard format.</li>
<li><strong>Home</strong>: This is the full HTTP web address of the Icon Style's homepage. This is optional.</li>
</ul>
</section2>
@ -196,29 +195,29 @@
@@ -196,29 +195,29 @@
<section2topic='Core Icons'>
<p>Although any text string can be turned into an icon by defining it in an <tt>icondef.xml</tt> file, it is highly reccomended they either follow traditional ASCII Art (smileys and frownys, for example) or full keywords in simple markup such as double-colons. If you want to design icons, always keep in mind that not every Jabber user uses graphics to "translate" this to something visual, as explained in the "Meaningful" requirement, above. Here is a short list of recommended "core" icons that should be in most definitions, as well as possibly be used by transports:</p>
<ul>
<li><b>:-)</b> and <b>:)</b> - A smiling face.</li>
<li><b>:-(</b> and <b>:(</b> - A frowing face.</li>
<li><b>;-)</b> and <b>;)</b> - A winking smiling face.</li>
<li><b>:'-(</b> and <b>:'(</b> - A crying face.</li>
<li><b>>:-(</b> and <b>>:(</b> - An angry face.</li>
<li><b>:yes:</b> - A thumbs-up or checkmark.</li>
<li><b>:no:</b> - A thumbs-down or a crossmark.</li>
<li><b>:wait:</b> - An open hand, palm outstretched.</li>
<li><b>@->--</b> and <b>:rose:</b> - A rose flower.</li>
<li><b>:telephone:</b> - A telephone.</li>
<li><b>:email:</b> - An electronic-looking envelope.</li>
<remark>Corrected David Sutton's JID and email. It has been pointed out
to me by amoungst others Rob Norris that things such as lists of JIDs
and lists in general are really the province of disco and browse and
that at least one of the suggested 'core' statistics doesn't
make sense for all components so removed these from the document. This namespace
was starting to become a generic data gathering namespace and we already
have one of those, so i've reworked yet again hopefully for the
final time it should now be simpler to implement and more consistent in
all cases.</remark>
</revision>
<remark>
Corrected David Sutton's JID and email.
It has been pointed out to me by amoungst others Rob Norris that things
such as lists of JIDs and lists in general are really the province of
disco and browse and that at least one of the suggested 'core'
statistics doesn't make sense for all components so removed these from
the document.
This namespace was starting to become a generic data gathering namespace
and we already have one of those, so I've reworked yet again hopefully
for the final time it should now be simpler to implement and more
consistent in all cases.
</remark>
</revision>
<revision>
<version>0.5.0</version>
<date>2002-11-03</date>
<initials>rkd</initials>
<remark>Heavily modified document according to suggestions from Matt Miller (linuxwolf). rkd had some additional thoughts on the name attribute, this version reflects those. Reorganized the description section.</remark>
</revision>
</revision>
<revision>
<version>0.4.2</version>
<date>2002-10-25</date>
<initials>rkd</initials>
<remark>Changed rkd's email address and jid. Modified namespace to use http uri.</remark>
</revision>
</revision>
<revision>
<version>0.4.1</version>
<date>2002-08-20</date>
<initials>rkd</initials>
<remark>Corrected error codes</remark>
</revision>
</revision>
<revision>
<version>0.4</version>
<date>2002-08-18</date>
<initials>rkd</initials>
<remark>Fixed two silly typos that crept back in. Rewrote SNMP
to read better. Added the DTD</remark>
</revision>
</revision>
<revision>
<version>0.3</version>
<date>2002-08-16</date>
@ -83,9 +90,9 @@
@@ -83,9 +90,9 @@
<remark>Added <display/> so a server or component may
optionally return data in a human readable format. It is nothing
more than a bit of visual fluff but it has potential to be quite
useful. Renumbered the revisions to allow room for stpeter's new
document numbering scheme, sorry if it is now confusing but I hadn't
left much room to grow with the previous revision numbering. A
useful. Renumbered the revisions to allow room for stpeter's new
document numbering scheme, sorry if it is now confusing but I hadn't
left much room to grow with the previous revision numbering. A
little more prettying and judicious use of punctuation has occurred.</remark>
</revision>
<revision>
@ -99,7 +106,7 @@
@@ -99,7 +106,7 @@
<date>2002-08-14</date>
<initials>rkd</initials>
<remark>I seem to have misunderstood one of Ryan Eatmon's
suggestions and didn't make this generic enough. I have
suggestions and didn't make this generic enough. I have
fixed that now. Clarified error codes and reworked how errors
are indicated to work with the new generic
namespace. Rearranged the order of the sections a bit make this
@ -157,15 +164,14 @@
@@ -157,15 +164,14 @@
<initials>rkd</initials>
<remark>Initial version.</remark>
</revision>
<dependencies>XEP-0053</dependencies>
</header>
<section1topic='Introduction'>
<p>As things currently stand it is not possible to obtain statistics
from a jabber component or server without resorting to parsing the
various log files. This makes it extremely difficult to obtain statistics
that are of any use in real world situations. This document attempts to
rectify this situation by defining a new namespace that would be used
to obtain statistics from a component or server so that they may be
from a jabber component or server without resorting to parsing the
various log files. This makes it extremely difficult to obtain statistics
that are of any use in real world situations. This document attempts to
rectify this situation by defining a new namespace that would be used
to obtain statistics from a component or server so that they may be
manipulated and used in a useful manner. For the purposes of this namespace
a statistic is anything that maybe expressed in a numeric form, such as the
uptime of a server, the <strong>number</strong> of registered users and the
@ -182,7 +188,7 @@
@@ -182,7 +188,7 @@
<stat name='' units='' value=''/>
</query>
</code>
<p> There is one variation in the case of an error invalidating one or
<p> There is one variation in the case of an error invalidating one or
more errors in a single returned query that does not actually
invalidate the whole query.</p>
<code>
@ -194,8 +200,8 @@
@@ -194,8 +200,8 @@
<section2topic='Name Attribute'>
<p>The name of the statistic. The format for this attribute is the
generic statistic type such as bandwidth, users, time etc. followed by
a '/' character and then then the name of the actual statistic. For
example bandwidth/packets-in, time/uptime and users/online. This will
a '/' character and then then the name of the actual statistic. For
example bandwidth/packets-in, time/uptime and users/online. This will
be assigned and administered by JANA<note>See Name Registration</note>.</p>
<remark>At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by &xep0065;.</remark>
<remark>At the request of the author, the status of this specification has been changed to Retracted since it has been superseded by XEP-0065.</remark>
</revision>
<revision>
<version>0.8</version>
@ -87,36 +91,36 @@
@@ -87,36 +91,36 @@
<p>A REL-compatible stream transport must have the following properties:</p>
<ul>
<li>Provides a reliable bytestream between two Jabber entities, which means that the bytestream transport handles all data delivery issues, such that the application need not worry about them.</li>
<li>Has a the following link states:
<tablecaption='Link states'>
<tr>
<th>Code</th>
<th>Description</th>
</tr>
<tr>
<td><tt>INIT</tt></td>
<td>Initiation</td>
</tr>
<tr>
<td><tt>GOOD</tt></td>
<td>Successful initiation (connected)</td>
</tr>
<tr>
<td><tt>BAD</tt></td>
<td>Unsuccessful initiation (stream is closed, no further state)</td>
</tr>
<tr>
<td><tt>CLOS</tt></td>
<td>Successful closure after establishment (stream is closed, no further state)</td>
</tr>
<tr>
<td><tt>ERR</tt></td>
<td>Link failure after establishment (stream is closed, no further state)</td>
</tr>
</table>
<li>Has link states from the following table.
</li>
<li>Defines a stream identifier, which MUST have a unique ASCII representation. The stream protocol MUST be able to use any ASCII identifier chosen during REL negotiation, as long as the sending party doesn't use the same identifier more than once.</li>
</ul>
<tablecaption='Link states'>
<tr>
<th>Code</th>
<th>Description</th>
</tr>
<tr>
<td><tt>INIT</tt></td>
<td>Initiation</td>
</tr>
<tr>
<td><tt>GOOD</tt></td>
<td>Successful initiation (connected)</td>
</tr>
<tr>
<td><tt>BAD</tt></td>
<td>Unsuccessful initiation (stream is closed, no further state)</td>
</tr>
<tr>
<td><tt>CLOS</tt></td>
<td>Successful closure after establishment (stream is closed, no further state)</td>
</tr>
<tr>
<td><tt>ERR</tt></td>
<td>Link failure after establishment (stream is closed, no further state)</td>
</tr>
</table>
<p>The following stream transports that meet these guidelines are:</p>
<tablecaption='Supported streams'>
<tr>
@ -146,7 +150,7 @@
@@ -146,7 +150,7 @@
</iq>
]]></example>
The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol.
<p>The remote entity will advertise the "http://jabber.org/protocol/rel" namespace as a feature to represent they implement this protocol.</p>
<p>A typical XML stream is a pair of XML documents, one for each direction of communication between the two peers. An simple example of these might look like this:</p>
<p>Currently, the prefix for each namespace is fixed; it cannot vary at all, since implementations use it for matching. The desire is to be able to use arbitrary prefixes:</p>
<examplecaption="XML stream with arbitrary namespace prefixes (1)"><
Sam Whited
6 years ago