[Standards] Entity Capabilities Woes

Matt Tucker matt at jivesoftware.com
Wed Mar 14 02:35:48 UTC 2007


Hey all,

Because we're adding Jingle to Spark and Smack, we need to bite the
bullet and start disco'ing clients for features. That inevitably leads
to the entity capabilities XEP. Maybe I don't understand all the
subtleties, but the XEP seems very complicated and possibly not even
very efficient in a heterogeneous client environment (lots of
client/version/extension combinations).

After talking through the issue here at Jive, we thought we had a simple
and great solution. After talking it over with a few others, it turns
out this has all been discussed before:

http://mail.jabber.org/pipermail/standards/2005-November/thread.html#916
9

To re-hash the idea... instead of having the fairly complex logic around
client name, version and optional extensions, there would simply a
presence extension that would look like the following:

<capabilities xlmns="whatever">muc pep jingle xhtml</capabilities>

The values would be short text strings maintained in the XMPP registry
that represent full disco information. Before I go any further, I should
address the inevitable and powerful "that ship has already sailed"
argument. Three possible answers:

 1) More than two year later, there's still relatively little client and
server adoption of the current caps XEP as far as I can tell. It's an
overstatement to call the XEP a failure, but it's in a far different
class compared to MUC, for example.
 2) The alternative proposal above (and in the thread) is incredibly
simpler to implement. I don't think the current XEP fits well into the
XMPP philosophy of simple clients.
 2) Coversant actually went to the effort to fully implement the current
XEP and they're *still* open to the alternative proposal (Chris, feel
free to correct me). :)

There were some objections raised to this idea in the thread from two
years ago:

> This alternative proposal is less efficient on the wire, since tons of
extensions might be added.

1) In two years time, few new extensions have been added to XMPP.
2) I'd argue that the current XEP is generally far less efficient.
Having to disco for every ext item is painful and complicated (and every
client will have a fair number of ext items given preferences). If it is
more efficient (which might take a statistical analysis to prove),
that's *only* in the case where disco queries are cached on disk between
sessions (so much for simple clients).
3) I'd argue that no client will have more than about 30 capability
extensions. With server-side optimization, that would only have to be
sent on the first presence packet or for changes. Combine that with
short names and you have a pretty efficient protocol. There are other
optimization options as well (like rollup names to represent the basic
and medium protocol suites).

> Maintaining a central registry would be hard, there would be
conflicts.

Given the low number of new protocol extensions, I really doubt this
would be a practical issue.

-------------

Is there any appetite for revisiting this issue? I personally think it's
very relevant given that the XSF is currently pushing Jingle and PEP.
Entity caps is essentially required for both those extensions (from a
practical standpoint), and making caps a lot simpler for client authors
will only help drive PEP and Jingle adoption.

The changes to the XMPP registry and XEP's that depend on the current
caps would be simple as far as I can tell.

Waiting for Flames,
Matt



More information about the Standards mailing list