[Standards-JIG] Client Capabilities (rant)

Chris Mullins chris.mullins at coversant.net
Sat Dec 3 23:16:18 UTC 2005

PSA Wrote:

[CLM Dislikes the current state of client capabilities]

[Does Chris Understand JEP 115?]
> I think the subsequent list discussion has shown that 
> you may have missed a thing or two in your reading of 
> the JEP. 

I understand the JEP. Really. 

My real rant (although it's not clear) is less at the JEP than at the
exceedingly poor state of client support for it. 

I build an IM SDK for a living, and that SDK is supposed to work against
a wide variety of clients. The way it sits now, the many (the majority?)
of popular clients don't have proper capabilities support. 

Because of this, the logic to determine caps is exceeding complex. 

The Algorithm is something along the lines of:

1) Certain clients (a very small percentage. Currently I only know of
one) properly work with JEP 115. Go forth and be merry.

2) Certain clients announce caps in presence and support disco on their
root node, but don't support disco on the EXT nodes they announce. Deal
with this.

3) Certain clients announce caps in presence but don't respond on the
client caps root node, but do respond on the standard disco node. Deal
with this.

4) Many don't announce caps at all. Make the Disco request against their
root node. 

5) Many don't respond to the disco request, so send them an IQ:Version

6) Punt on the ones who don't respond to IQ:Version. 

Next up is the fact that few of the clients properly ask ME for my
capabilities. They either never send the disco requests to the client
caps node, never query the ext nodes, or query the wrong node names.

Several clients query using the old disco mechanism. 

Others send IQ:Version each time regardless.

Most client, even once they have identified the capabilities that I'm
announcing don't' bother doing anything with the caps. For example I can
pull "xhtml" out of my tests, and a number of clients will keep right on
sending me xhtml in the message packets. Same goes for the Chat State
Notification. Same goes for a number of features. This means even when
the client capabilities are properly identified, client developers often
don't use them.

This is my real frustration. In spades. 

That the JEP is (in my opinion) unclear in a few places is easy to fix.
That some of the feature aren't listed in the registrar when I believe
they should be is easy to fix. 

Admitting that we have a number of exceedingly poorly written clients in
the wild, and that, worse, some of these clients are in very wide use is

Doing something about it once the problem has been acknowledged is
equally hard. 

The Jabber.Org clients page
lists 81 clients today. These are clients that, at one time or another,
people have put enough work into to 1) Make them semi-functional, 2) Get
them on the list. Neither of these is a trivial exercise. What
percentage, do you think, properly supports client capabilities? I would
be shocked if that number even came close to 10%. I think we would be
lucky if 5% has complete client caps support.

[Obligatory Flame Baiting]
One could make the case that this example highlights much of what is
wrong with open source software. Large numbers of partially written,
often long abandoned, software masquerading as a finished product.

[Features missing in the registrar - IBB]
> Has anyone actually implemented JEP-0047? What features do you 
> have in mind? Naturally we can add them to the registry.

There's no one feature - against it's more the general state of things.
Many of the JEPS don't offer a way to discover them. In Band Byte
Streams was just the one that I picked as an example. 

What we're seeing is a classic legacy issue. IBB was written pre-disco,
and when disco went live, IBB was never updated to provide a discovery
mechanism. There are a number of JEPS like this. 

Overall, it makes the entire issue of client capabilities exceedingly
difficult, and possibly impossible in the general case.

[Pubsub Client Caps]
> Perhaps we can add further sarcasm to our discussion threads 
> while we're at it? ;-)

Sarcasm aside, this is probably the best long term answer. Given the
complexity required on the client side to deal with it, I don't think it
will ever happen unless one of the major client players (Google, Apple)
goes there first.

> The point of JEP-0115 is to be a kind of profile of service 
> discovery. If people implement it correctly the old-fashioned 
> IQ storm would be a thing of the past.

I agree 100%. But that's not the current state of things, and doesn't
appear to be. 

Given that I talked with the primary developers of many of popular
clients, and (for the most part) they either misunderstood or did not
plan on implementation JEP 115, I don't see this changing any time soon.

Chris Mullins

More information about the Standards mailing list