[jdev] The future of Jabber/XMPP?
dave at cridland.net
Fri Aug 27 06:02:23 CDT 2010
On Fri Aug 27 11:23:09 2010, Evgeniy Khramtsov wrote:
> 27.08.2010 19:54, Dave Cridland wrote:
>> So you're snooping all messages even from remote sources to guess
>> if they're PEP events intended to be filtered? How would you know?
>> If I (or my client) explicitly subscribes to a particular node on
>> PEP/PubSub-onna-jid service, you'd filter it out anyway.
> If you have caps and valid disco#info then there will not be such
> problem. So it works in practice.
You're misunderstanding me.
If a client sends an explicit subscription to a node on a pubsub
service held on a foreign domain whose jid happens to be a bare jid,
then notifications will be filtered by the client's local server,
effectively breaking the subscription.
>> I'm struggling to understand how that does not violate the XEP?
>> auto-subscribe is defined as a depth=all items subscription to the
>> root node from the bare_jid, and filtered-notifications then only
>> sends the notifications to those full jids that have requested
>> them. Both are required for PEP. I don't see how you can claim to
>> be conformant to PEP without doing both.
> Yes, but http://xmpp.org/extensions/xep-0163.html#notify-addressing
> para 4 says:
> "... if the PEP service does not have presence information about a
> subscriber, it MUST address the notification to the subscriber's
> bare JID (<localpart at domain.tld> or <domain.tld>)."
But you *do* have presence information - or at the very least the
only reason you don't is because you've thrown it away. I don't see
how this can be described as conformant behaviour.
>> So because you filter on the subscriber's end, you restrict
>> PubSub-onna-jid to the PEP subset, and because you don't filter on
>> the service end, you break even that if the subscriber isn't on
> Well, strictly speaking yes. However such situation is uncommon it
> practice: all popular clients provide caps and disco#info.
What, it's uncommon for subscribers not to be on ejabberd?
If a subscriber is on a remote server that's implementing standard
PEP (or indeed no PEP at all), then you're breaking, caps and
disco#info or not. I reiterate - the only case your protocol works
like PEP is when the remote subscriber is on ejabberd too.
Or do you mean that it's uncommon for PEP services to speak more than
just the PEP subset? This I'll agree with, but we should not design
to preclude that.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the JDev