Hello Philipp, thanks for your feedback. On 06/17/2014 03:02 PM, Philipp Hancke wrote: > Am 02.06.2014 18:48, schrieb XMPP Extensions Editor: >> 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. > > -1 --I think this needs a decent flame war^W^W^Wmore discussion about > the usage of XEP-0033. > > >> it's impossible to be subscribed to a person's feed if the person is >> not subscribed to you because in this case his server doesn't know >> your presence information and your capabilities and hence it can't >> filter the messages appropriately, so you won't receive any >> notifications at all; > > Assuming the publisher uses filtered notifications. Which it does not > have to if the "explicit subscribe" described in XEP-0277 is used. > Note that this probably requires the publisher to support > pubsub-on-a-jid instead of just pep. That doesn't seem as a consistent way to me too because it will lead to sending the events to all the resources, even if they are not able to process them from the one side and it will lead to problems with synchronization between resources in the case when there are more then one simultaneously connected resources.
> > >> servers need to know not only their users' capabilities but also the >> capabilities of all the users that it wants to communicate; > > Right. I'd note that a caps-aware/pep-enabled server already does that. Sure, the point is that they will be able to exclude capabilities of the users' of the RSF-enabled servers from their caches. > > >> clients can't decide what kind of notifications they want to receive; >> node owner decides instead, but clients might not be interested in >> some of notifications or vice versa. > > It seems to be useful for a client to instruct their server to filter > events sent to the bare JID. For this, an approach like the one > described in 3.4 seems to make sense. > Which would basically turn this proposal into a way to do pep-like > filtering on the receiver side instead (or in addition to?) the sender. > That seems generally useful IMO. Yes, that's one of the (two) main reasons to introduce the XEP. > > > >> we can't reduce amount of S2S traffic by sending one notification for >> each server, we need to send as much notifications as much users are >> subscribed on it; > > I'd note that the distribution problem (or multicast optimization) is > not limited to pubsub. Presence, pep and MUC have the same problem. > > > Back in 2008 (april) we had another proposal that went in the same > direction: http://xmpp.org/extensions/inbox/repeaters.html > (and we've had lengthy discussions about that and "smarticast" in 2006) > I agree with the authors of the repeaters proposal that "in practice > Extended Stanza Addressing has not resulted in traffic optimization". I > do not expect this to for the use of 0033 in this specification either. > stanza repeaters hasn't been moved forward. I don't know whether this > was by council decision or because the authors decided not to move it > forward... > > That said, I haven't seen much effort in that field since 2008. So it > seems this doesn't hurt the ops side much which implies there is no need > for standardized optimizations. > I have some concerns here but I won't argue here because it's not the main reason to introduce the XEP. I just want PEP to correspond the presence model tightly to be able to use it more widely, and I would like to hear if you have any reasons why I should not want that to become real :) I am ill a little now, so my apologies if some of my thoughts were not explained well enough. I will be happy to continue the discussion though. -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
