[standards-jig] Protocol support in the upcoming jabberd 2.0 server
rob at cataclysm.cx
Thu Oct 10 11:34:39 UTC 2002
[ crossposted to jabberd at js.o, but replies to standards-jig please ]
I'm not sure of what the "official" relationship between the JSF and the
Jabberd project is, but I think its fair to say that most see it as the
reference implementation for the protocols. As such, its important to
get the mix of supported protocols correct, because support in jabberd
is enough to make or break a protocol.
I'm currently in the process of determining the IQ namespaces that
should be supported in the upcoming jabberd 2.0 release. I've gone
through the protocol support that exists in 1.4.2, as well as new
namespaces that have appeared since, and I've put together this summary
of the various protocol pieces, and what I think.
I'd appreciate any and all feedback you might have on this. If I've
missed something, please reply and let me/us know. If you have a comment
about support of some other part of the protocol (message/presence), let
the list know.
The following namespaces are supported by 1.4.2.
jabber:iq:admin (includes jabber:mod_admin:who) (not documented)
A mixed bag of administrative functions. It has options "who",
"monitor", "user" and "config". mod_admin implements "who" (returns a
list of online sessions), partially implements "config" (retrieves the
current server config), and has stubs for "monitor" and "user".
(mod_admin als handles admin messages (ie messages to the SM) - these
I'd prefer to drop this namespace in favour of a more "correct" approach
using browse/disco for user browsing, and x:data and JEP-0050 for
configuration (maybe for 2.2).
Used to get information about the services offered by the SM. This was
the precursor to browse.
It's still used by many clients, and its part of the standard
protocol, so it stays.
Used to browse services (like jabber:iq:agents) and users on the
Service browsing is probably required, and user browsing is a useful
feature, however I'm not sure which is the best choice given the
current debate between browse and disco.
I'd like to not to implement this until either browse or disco (or
something else) are ratified by the Council, but I may not be able to
get away with that (especially since JEP-0011 is active).
jabber:iq:filter (misc docs on oid.jabber.org)
Providers powerful message filtering options based on rules set by the
The 1.4 implementation is flaky, and there's no definitive
documentation. I don't want to implement something this big without a
real document ratified by the council, but there are clients out there
that support it, so I'll go either way.
It should be noted that mod_filter makes use of jabber:x:envelope.
JEP-0033 is the obvious choice to replace this, but it hasn't been
Primarily concerned with finding out the last time the user did
something. This is usually either the last time they interacted with
the system, or the last time they logged out.
Although the protocol is informational, the 1.4 implementation is
trivial and benign, so it stays.
Used for self-registration of new users.
I personally hate it, but its part of the standard protocol, and its
widely used, so it stays.
Used for managing the user roster (lists of JIDs that we send or
receive presence to or from, and associated information).
Of course its supported :)
Used to find the current time on the server.
In the standard protocol, and trivial to implement, so it stays.
Used to store arbitrary per-user XML on the server (such as client
preferences, bookmarks, etc).
In fairly wide use already, with a new informational JEP about its
use. Trivial to implement, so it will stay.
A storage format for a variety of information about a user.
The 1.4.2 server also allows for automatically populating a JUD.
If we chose not to implement that feature, then support for this
namespace is simply get or set to the database. At the very least,
that will be supported.
The 1.4.2 server also allows for public XML storage - an IQ set in any
unknown namespace will cause the enclosing data to be stored. A get in
that namespace (by any user) for the user will return the stored data.
This feature is undocumented, but is the exact same semantics as
I'd be interested to hear if this feature has widespread use.
There's also this IQ namespace which possibly should be implemented:
Implements server-side black/white lists.
This implements some of things that are possible with
jabber:iq:filter, arguably in a more rounded way. I imagine that there
will be quite a bit of demand for this, but it has not yet been
ratified by the Council.
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards