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