[Standards] XEP-0115 is harmful and should be deferred

[Rachel Blackman]

> 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 (foo at jabber.org/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 <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/