[Standards-JIG] Client Capabilities (rant)
stpeter at jabber.org
Fri Dec 2 23:16:52 UTC 2005
Sorry, I was offline when this thread erupted.
Chris Mullins wrote:
> 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
I think the subsequent list discussion has shown that you may have
missed a thing or two in your reading of the JEP. That said, I'm always
in favor of making things as clear as possible, so I'm willing to fix
the text as necessary.
> 2 - Perform Disco against the particular remote client resource.
No, you don't need to do that if as recommended you have cached the
information you've previously discovered about various clients.
> [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:
That's because the top of that page states:
The 'var' attribute of the <feature/> element within the
'http://jabber.org/protocol/disco#info' namespace may contain any
namespace that is registered with the Jabber Registrar (see
<http://www.jabber.org/registrar/namespaces.html>). This page lists only
additional values that have been separately registered with the Registrar.
> 3 - Many of the useful features In Band Byte Streams (JEP 47) don't
> provide any means of discovery, so just wing it here.
Has anyone actually implemented JEP-0047? What features do you have in
mind? Naturally we can add them to the registry.
> 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.
Absolutely not necessary to send version requests. One of the main
purposes of JEP-0115 was to forestall the need for the old version flood.
> 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.
The IQ storm is prevented if you implement JEP-0115 correctly and cache
> 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.
What we have today is people who can't read the specs. Either that or
unreadable specs. ;-)
> 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.
Perhaps we can add further sarcasm to our discussion threads while we're
at it? ;-)
> 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.
Oh god no.
> 4 - Stick with the Disco approach, but at least document all the
> features that can be looked for in a single place (The Jabber
> 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.
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.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards