But I do see some inconsistency here. We don't allow vCard hashes to be pushed with the presence. We do not allow moods and "now-playing" to be pushed on us with the presence packet, but we gladly allow unrequested capabilities to be pushed with the presence?? More then, we're going to REQUIRE them?
Vcard, user tune, user mood and so on are in no way required for two clients to know what methods they have to communicate. Capabilities are, at least for more than the most basic of interactions.
It's useful to know whether or not another client supports XHTML-IM before you send them a large packet filled with both plaintext and XHTML data. (Especially for the oft-cited case of mobile folks who pay by the megabyte.) It's also useful to know whether or not someone supports voice chat or video chat so that you can put a 'voice' or 'video' chat icon next to their name, or have a 'Open audio chat...' in the contact's right-click context menu. Similarly, it's nice to know if they support file transfer or not, so that you can put a 'Send file...' option in their right-click menu.
For any of that to work in the client interface, you need to know the client capabilities; it's kind of an implied dependency for anything other than the most basic plaintext <message/> stanza.
You mention pubsub/PEP, but while PEP is great it seems to me that pubsub is not really suited for this. First off, capabilities are really tied to XMPP sessions; if you logged a new client in which didn't support PEP, but used the same resource ([EMAIL PROTECTED]/Work, for instance), then you'd have old, inaccurate capabilities stored in PEP.
Further, in order for PEP to work for capabilities, you'd really need to /require/ every client to publish their disco capabilities as a PEP item, and also require everyone to subscribe to that item for all those on their roster. That's a heavy set of requirements just to discover support for file transfer or formatted text! Plus, it generates a lot of text; no matter how many people on your list use 'Pidgin 2.0' you will get the entire disco result for each of them as they log on.
Moreover, we already /have/ a method out there to discover the capabilities of a client -- namely, disco queries. So based on that, you could just disco-probe every single resource of every single contact on your roster, but that would create a lot of traffic... basically, it's iq:version all over again, only with much, much larger response packets. What would probably make more sense would be to have a small bit of information you can key off of to know that, hey, *this* disco result maps to this special key, and any client with this special key has that disco result.
If you had a way to communicate that small bit of identifying information to anyone who cares about your presence, then you would only need probe any particular version of any particular client once and you have the results for everyone else using that client. When they come online you get that small key, and if it's something you already recognize, you already have your answer. Otherwise, you query and cache for any future instances of that key.
Which basically brings us back to XEP-0115. :) -- Rachel Blackman <[EMAIL PROTECTED]> Trillian Messenger - http://www.trillianastra.com/
