On Wed, Jun 18, 2014 at 9:20 AM, Lance Stout <[email protected]> wrote: > > On Jun 2, 2014, at 9:48 AM, XMPP Extensions Editor <[email protected]> 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'm a -1 based on the reasons Fippo explained concerning XEP-0033 use. > > > However, the event filtering by the receiver's server via caps part of this > proposal is useful and could stand on its own without the XEP-0033 parts. > > That enters into SIFT-like territory, but maybe that's a direction we need to > experiment in so that we can actually have things that implement SIFT > features.
This is one I'd really like to thrash out at a summit, because I think it's slightly more involved than is immediately obvious. The -33 use makes me uncomfortable, because I'm not convinced yet that -33 actually buys us much here. I'd rather like to see figures here to convince me. The recipient-side filtering seems OKish, but could lead to situations where the publishing servers blindly send out to all possible recipient JIDs and let the recipients deal with whether to send to the clients or not - clearly not OK. It seems that this is potentially trying to answer part of a larger 'how do I manage my pubsub subscriptions?' question, as there are other things you want to do with your subscriptions. I think the buddycloud folks have looked at some of this stuff with their inbox services. I don't know if cross-polination there makes sense? /K
