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