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

[Rachel Blackman]

On Jun 26, 2007, at 11:31 PM, Sergei Golovan wrote:

Okay, first... please don't take this personally; your post just  
provides a chance to make a point about this constant argument over  
this XEP.

>> You can always just query each user independently if you like; you
>
> I think that the XEP must not recommend to cache capabilities based
> only on reported software name and version. The more acceptable index
> is a tuple {jid, client name, client version}.

But that violates the /entire purpose/ of the XEP, and basically  
makes it useless.

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.

The purpose of this XEP is to avoid clients flooding stuff by saying  
'hi, I am <client> with <version> and <list of extensions>' in a  
manner that each of those tokens can be used to cache and reuse the  
information.  I.e., <client>#<version> and <client>#<extension>  
should be unique disco namespaces, and once you have the result you  
no longer need to query it each time.

Every couple of weeks we seem to get another set of arguments going  
'ZOMG THE SKY IS FALLING PEOPLE COULD TAINT THE INFORMATION CACHE!'   
Y'know what?  That's absolutely true insofar as it goes... but first,  
other than malicious mischief, I'm not certain offhand what such an  
attack could actually do to compromise a remote client.

But second, and more importantly, not one single person has offered a  
solution other than 'make every extension hardcoded' or 'just probe  
each contact, cache only per-JID,' which returns us to the original  
troublesome network-flooding behavior on logins.  Both have already  
been argued to death here; I'm not going to rehash the arguments.

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 don't know, nor do I care, what the alternative is; when it's  
presented I'll happily assess and potentially implement it, along  
with everyone else.  But right now, caps is here, it works to solve  
an existing problem, and if someone wants to tear it down I suggest  
they offer the alternative.

It's time and energy we could spend on sorting out how to make Jingle  
more readily implementable.  We also have certification and  
standardization to think about.  And I know I seem to mention this in  
darn near every post lately, but we STILL have two incompatible file  
transfer specifications live on the network right now unless Google  
Talk has decided to implement stream initiation. :)

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