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

Sergey Dobrov binary at jrudevels.org
Fri Aug 15 06:06:06 UTC 2014


On 08/13/2014 10:26 PM, Peter Saint-Andre wrote:
> 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.
Thank you for that.

> 
> 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.
Surely, and for those systems we have bare jids, but what if we do need
some list of subscriptions like in blogging, why don't use roster in
such cases?

> 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.
Firstly, I don't think that it's a completely different protocol, it
just changes the flow to solve some problems and for end users it
changes completely nothing except of more smooth experience because user
expects PEP to work in conjunction with presence and it not always does
so. Secondly, if anybody would come up with easier solution on one-way
subs, I would love to accept it, but nobody knows, it seems, how to do that.


> 
> Just my centigram of silver...
Thanks.

> 
> Peter
> 
> 


-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.



More information about the Standards mailing list