[Standards] Proposed XMPP Extension: Recipient Server Side Notifications Filtering

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 13 15:26:35 UTC 2014

On 6/2/14, 10:48 AM, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Recipient Server Side Notifications Filtering
> Abstract: This specification defines a modern efficient way to deliver PubSub notifications.
> URL: http://xmpp.org/extensions/inbox/rsf.html
> The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.

I've finally made time to read this proposal.

It seems to me that the proposal is saying that PEP isn't always ideal, 
so we need a new protocol. However, I think that for high-scale 
scenarios (e.g., a bot collecting geolocation information about all 
users in a large company, or microblogging for users with lots of 
followers), it might be better to use generic pubsub (XEP-0060) without 
presence involved at all, not PEP (which as noted depends on having 
bidirectional presence subscriptions in place). PEP is a simplification 
of pubsub for IM systems, but not all pubsub systems are based on IM. 
However, a system could be architected such that it provides two ways to 
subscribe to the same information (via pubsub and PEP). Or a system 
could implement full pubsub on every JID, instead of using the 
simplified technology we defined in the PEP spec. I'm not, however, 
seeing the need for a completely new protocol.

Just my centigram of silver...


More information about the Standards mailing list