[Standards] XEP-0115 is harmful and should be deferred
stpeter at jabber.org
Thu Jul 5 22:19:47 UTC 2007
Tomasz Sterna wrote:
> Dnia 04-07-2007, śro o godzinie 21:03 -0600, Peter Saint-Andre
>>> base64(sha1(dave-formatted id/features))
>> Seems reasonable to me.
> I've picked this random post to reply but it does not concern this
> particular post but the whole thread...
> ...which I did not follow really, because I find this whole XEP and
> concept of entity capabilities distributed with presence packed unneeded
> and harmful.
Great! Disagreement is good.
> This XEP came out to solve a problem of jabber:iq:version storming on
> the Psi client launch, which other clients blindly copied just to
> show-off the remote client version at the fancy tooltip.
Not just that. Also the disco flood on login. Believe me, if you have
1500 people in your roster, the disco flood can be significant. Or are
you saying that just-in-time discovery is good enough? Have you written
a client that does that? What has been your experience?
> So instead of pull-based mechanizm there was a push-based mechanizm
> 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?
> Excuse me. I've subscribed your PRESENCE information.
What is presence? It's not mere network availability, it's availability
for communication. And capabilities tells me how you can communicate.
> I didn't ask for
> your mood, tune, avatar nor capabilities. If I would need them, I will
> ask and you may allow me to have them.
> There's nothing special about the caps, that these would require special
Except that caps are about your communication capabilities.
> And what's more - we invented a way for me to subscribe for all this
> kinds of additional information. Using everyone's favorite PubSub.
> Why don't we reuse it somehow?
Funny thing is, the fancy filtering stuff PEP depends on caps.
> We didn't have PEP/PubSub deployed at all when we invented XEP-0115, but
> we do have now and for sure can do better now.
Feel free to come up with a specific proposal.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards