[jdev] The future of Jabber/XMPP?

Dave Cridland 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  
>> ejabberd.
> 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
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the JDev mailing list