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

2014-08-15 Thread Sergey Dobrov
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.


[Standards] UPDATED: XEP-0313 (Message Archive Management)

2014-08-15 Thread XMPP Extensions Editor
Version 0.3 of XEP-0313 (Message Archive Management) has been released.

Abstract: This document defines a protocol to query and control an archive of 
messages stored on a server.

Changelog: Fetching current preferences,
switch to iq-set for searching,
switch to using a data form,
describe how to fetch that form, remove the 
archived element and
use a sentinel message instead of iq reply. 
(ka/ks)

Diff: http://xmpp.org/extensions/diff/api/xep/0313/diff/0.2/vs/0.3

URL: http://xmpp.org/extensions/xep-0313.html



[Standards] Proposed XMPP Extension: Client State Indication

2014-08-15 Thread XMPP Extensions Editor
The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Client State Indication

Abstract: This document defines a way for the client to indicate its 
active/inactive state.

URL: http://xmpp.org/extensions/inbox/client-state-notification.html

The XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.