[jdev] The future of Jabber/XMPP?

[Dave Cridland]

On Fri Aug 27 13:18:15 2010, Evgeniy Khramtsov wrote:
> 27.08.2010 21:02, Dave Cridland wrote:
>> On Fri Aug 27 11:23:09 2010, Evgeniy Khramtsov wrote:
>>> 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.
> 
> Indeed, and I still don't understand what you are talking about.
> 
> 
Okay, bear with me, and I'll try to explain.

The automatic subscription on a PEP service is the only one that  
should be filtered.

For instance:

"A PEP service MUST support the "filtered-notifications" feature  
defined in Section 9.2 of XEP-0060. This implies that when an  
automatic subscriber can specify which event payloads it wants to  
receive by including appropriate feature bundles in the XEP-0115  
information it broadcasts."

I'd note that this does not mention any distinction between local and  
remote subscriptions.

Nothing prevents a more complex client and PEP service using  
*explicit* subscriptions, which would not be filtered - basically a  
PubSub service which is not only the PEP subset will be severely  
broken by your protocol.

In your implementation, because you filter on delivery at the  
receiver, you cannot make this distinction, because you lack the  
knowledge of the source.

Which means not only is ejabberd's PEP implementation broken WRT  
anyone else's, it is *also* self-restricting, such there's no path  
forwards to anything more than the PEP subset.

Dave.
-- 
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