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

Peter




More information about the Standards mailing list