The following issues must be solved for in this specification.
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.
The meta elements contain information about the Icon Style itself, rather that the individual icons. They are contained within the <meta> element, which is directly under the root element. There is one and only one the <meta> element.
Although any text string can be turned into an icon by defining it in an icondef.xml 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:
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 number of registered users and the @@ -182,7 +188,7 @@ <stat name='' units='' value=''/> </query> -
There is one variation in the case of an error invalidating one or +
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.
@@ -194,8 +200,8 @@
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 JANASee Name Registration .
@@ -218,7 +224,6 @@
send: <iq type='get' to='component'>
<query xmlns='http://jabber.org/protocol/stats'/>
</iq>
-
recv: <iq type='result' from='component'>
<query xmlns='http://jabber.org/protocol/stats'>
@@ -252,8 +257,8 @@
<query xmlns='http://jabber.org/protocol/stats'>
<stat name='time/uptime' units='seconds' value='3054635'/>
<stat name='users/online' units='users' value='365'/>
- <stat name='bandwidth/packets-in' units='packets' value='23434'/>
- <stat name='bandwidth/packets-out' units='packets' value='23422'/>
+ <stat name='bandwidth/packets-in' units='packets' value='23434'/>
+ <stat name='bandwidth/packets-out' units='packets' value='23422'/>
</query>
</iq>
@@ -261,7 +266,7 @@
If an error occurs with one or more of the requests for
- statistics the component or server should return one of the
+ statistics the component or server should return one of the
following error codes.
Code String Reason 503 Service Unavailable Statistic is
temporarily unavailable
-
-
Because we wish to be able to collect groups of statistics
within a single returned packet errors must be handled in a two
- tier way with authorization and core errors that would render
- all the statistics meaningless being indicated
+ tier way with authorization and core errors that would render
+ all the statistics meaningless being indicated
with a type='error' in the returned packet.
- <iq type='error' from='component'>
- <query xmlns='http://jabber.org/protocol/stats'>
+ <iq type='error' from='component'>
+ <query xmlns='http://jabber.org/protocol/stats'>
<error code='401'>Not Authorized</error>
</query>
</iq>
@@ -310,12 +313,12 @@
All statistic names, returned data units types and other
pertinent statistic information will be assigned and registered with
- the Jabber Naming Authority in the category stat.
- Unfortunately at this time such a body does not exist so we will
+ the Jabber Naming Authority in the category stat
+ Unfortunately at this time such a body does not exist so we will
have to rely on component and server authors diligently
- researching to ensure that their desired name is not already
+ researching to ensure that their desired name is not already
in use and that they adequately document the returned units
- type and anything else that would normally be registered.
+ type and anything else that would normally be registered.
Hopefully by the time this document is formally adopted
a central naming authority for the Jabber protocol will be in
place and functional and authors will be then able to register
@@ -386,16 +389,16 @@
Supporting industry accepted standards and procedures
For more details on SNMP
- and CIM within
- the Jabber protocol is highly desirable as long as it does not
- restrict the flexibility or functionality of Jabber. So while
- the http://jabber.org/protocol/stats namespace seems to fall within the domain of
- the SNMP and CIM standards amongst others and large jabber
- installations would find direct support an appealing prospect
- when tying jabber into their existing network information and
- management systems the jabber:iq:namespace will not do this.
- Because Jabber is an XML based protocol, conversion of
- the returned data to other formats including those required
+ and CIM within
+ the Jabber protocol is highly desirable as long as it does not
+ restrict the flexibility or functionality of Jabber. So while
+ the http://jabber.org/protocol/stats namespace seems to fall within the domain of
+ the SNMP and CIM standards amongst others and large jabber
+ installations would find direct support an appealing prospect
+ when tying jabber into their existing network information and
+ management systems the jabber:iq:namespace will not do this.
+ Because Jabber is an XML based protocol, conversion of
+ the returned data to other formats including those required
for SNMP, CIM etc. should be relatively simple. Not supporting
industry standards is not without advantages. By leaving the
http://jabber.org/protocol/stats as a pure jabber namespace we allow
@@ -412,14 +415,14 @@
TBD
TBD
+TBD
A REL-compatible stream transport must have the following properties:
| Code | -Description | -
|---|---|
| INIT | -Initiation | -
| GOOD | -Successful initiation (connected) | -
| BAD | -Unsuccessful initiation (stream is closed, no further state) | -
| CLOS | -Successful closure after establishment (stream is closed, no further state) | -
| ERR | -Link failure after establishment (stream is closed, no further state) | -
| Code | +Description | +
|---|---|
| INIT | +Initiation | +
| GOOD | +Successful initiation (connected) | +
| BAD | +Unsuccessful initiation (stream is closed, no further state) | +
| CLOS | +Successful closure after establishment (stream is closed, no further state) | +
| ERR | +Link failure after establishment (stream is closed, no further state) | +
The following stream transports that meet these guidelines are: