[Standards] Re: [jdev] XEP-0115: Entity Capabilities

Rachel Blackman rcb at ceruleanstudios.com
Wed Jun 27 08:17:44 UTC 2007

>> But that violates the /entire purpose/ of the XEP, and basically
>> makes it useless.
> It would make it useless if everyone used a new client on every new
> connection. While someone uses the same client version there's no need
> to constantly disco it. So, the aim of the XEP is achieved (for the
> higher cost however).

But the high cost is primarily -- indeed, I would say almost / 
exclusively/ -- when someone logs on and probes their entire roster.   
Or when someone logs in for the first time in a day or so, and all  
their contacts probe them; usually the cache will be gone for at  
least some of the contacts by then, as many people restart their  
clients (and thus lose the cache) every few days due to a Windows  
reboot or wanting to play a game and not be bothered, or whatever.

Your proposal addresses neither of those.

>> The situation we used to have was that someone would come online, and
>> other people would disco probe them.  Every single resource that came
>> online.  It generated too much traffic, both as you came online and
>> all your contacts probed you, AND as you had to probe all your
>> contacts.  It was bad.  It needed a solution; the solution is, thus
>> far, this XEP.
> But the security flaws are inacceptable for me in this solution.

I'm not arguing that the perceived flaws may be unacceptable to you  
personally here, but you already have two viable options for  
addressing that.

First option, in your implementation you can just individually probe  
each of your contacts (or, even, just disco and cache based on jid  
and client/version, as you suggested) and suffer the potential  
network-karma penalty if a user logs in and has 200 contacts online  
to probe.  Just keep in mind that many people still consider putting  
avatar hash data into presence to be too much potential network spam,  
so you may face some opposition from mobile client users who pay for  
their bandwidth by the megabyte.  (I.e., the same argument about high  
cost that led to entity caps in the first place.)

Second option, XEP an alternative protocol and put it forward to get  
others to adopt it.

>> So instead, I'm going to offer a challenge up.  The challenge is that
>> if anyone wants to seriously suggest that caps is a fundamentally
>> flawed XEP, they should first write up and submit an alternative XEP
>> for convenient capability discovery and traffic reduction.  /PLEASE/
>> offer an alternative!  Come up with some new, more secure XEP.
>> Suggest a version of caps which requires the client to sign the caps
>> bit with a private key, thus attempting to prove its identity.
>> Whatever.
> I'd propose another approach. Let every person who writes an extension
> to XMPP comes with a reference implementation. It seems to me that
> there will be much less forgotten and poorly designed XEPs. Which
> would be better for Jabber/XMPP, in my view.

Wonderful; we're in agreement on this!  It's something several people  
have pushed for before, about how too many XEPs get proposed purely  
as thought experiments and never actually are implemented by anyone.   
Reference implementations should be a requirement for writing a XEP.

However, in this case, caps already has /many/ implementations, as a  
great number of clients use it successfully.  And I'm pretty sure it / 
is/ one of the few that actually had a reference implementation  
provided way back when.  :)

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/

More information about the Standards mailing list