[Standards-JIG] Client Capabilities (rant)

Chris Mullins chris.mullins at coversant.net
Sat Nov 19 23:50:10 UTC 2005

I've spent quite a bit of time over the last few weeks adding client
capabilities into our SDK. I've done this, as customers have complained
that they can't figure out what clients support what features, and they
need a better way. 

After working on this, I have to say that the existing client
capabilities infrastructure that XMPP / Jabber has needs (at the least)
some very serious re-work, and more likely a complete overhaul.

As it stands now, to figure out what capabilities a particular client
has, we need to go through the following steps:

1 - Check presence and see if any JEP 115 capabilities are listed. If
any of these are listed, we need to just ignore them, as they're client
specific anyway and of no use to any other client. This JEP is of no use
for general client capabilities and should be either renamed, or

2 - Perform Disco against the particular remote client resource. Look

[Found in JEP 95, Stream Initiation]
	<feature var='http://jabber.org/protocol/si'/>

[Found in JEP 95, but NOT in JEP 96 (File Transfer) ]

[I don't know where this comes from, JEP-Wise, but I keep seeing it]
	<feature var='http://jabber.org/protocol/bytestreams'/>

[Found in JEP 71]
<feature var='http://jabber.org/protocol/xhtml-im'/>

NONE of the features above are listed in the Jabber Registrar found at:

3 - Many of the useful features In Band Byte Streams (JEP 47) don't
provide any means of discovery, so just wing it here.

4 - Send an IQ:Version request (JEP 92) to the remote client. Hope they
support it. Hardcode all the features based on trial and error of what
Psi, Pandion, Exodus, Trillan, Pandion, iChat, and Gush support.

The major features people care about are FileTransfer and XHTML.
Everyone wants to eliminate the giant IQ Storm that happens on a client
login. The two need to be reconciled somehow.

What we have today is a mess, and if we want clients to ever actually
interoperate with either other in an advanced way, a significantly
better mechanism is required. 

Options for fixing issue this include:

1 - Take the JEP115 approach of clients announcing their capabilities in
the presence stanzas. Eliminate the sentence "The names of the feature
bundles MUST NOT be used for semantic purposes: they are merely
identifiers that will be used in other use cases.", and map "xhtml" to
the XHTML jep, "ft" to the file transfer jep. 

2 - Take a pubsub approach. Given the wild success, high adoption, and
overall community consensus of the PubSub Avatar JEP has been this
approach is strongly recommend.

3 - Have a web page somewhere that lists the client, and the features
they support. At least this way we could hardcode the features and
things would more-or-less work. 

4 - Stick with the Disco approach, but at least document all the
features that can be looked for in a single place (The Jabber
Registrar). Accept that this fails in many mobile and low-bandwidth
cases due to the iq packet storm on login with a roster of any
significant size.

Chris Mullins

More information about the Standards mailing list