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; youI 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 <[EMAIL PROTECTED]> Trillian Messenger - http://www.trillianastra.com/
