[Standards] XEP-0115 is harmful and should be deferred
rcb at ceruleanstudios.com
Thu Jul 5 22:31:09 UTC 2007
> 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
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/
More information about the Standards