[Standards] Proposed XMPP Extension: Stanza Repeaters

Tobias Markmann tmarkmann at googlemail.com
Tue Mar 18 00:01:04 UTC 2008


On Mon, Mar 17, 2008 at 11:47 PM, Pedro Melo <melo at simplicidade.org> wrote:
> Hi,
>
>
>
>  On Mar 17, 2008, at 4:28 PM, XMPP Extensions Editor wrote:
>  > The XMPP Extensions Editor has received a proposal for a new XEP.
>  >
>  > Title: Stanza Repeaters
>  >
>  > Abstract: This specification defines an XMPP extension that enables
>  > optimization of interdomain traffic that is intended for delivery
>  > to multiple recipients, using the concept of a stanza repeater.
>  >
>  > URL: http://www.xmpp.org/extensions/inbox/repeaters.html
>  >
>  > The XMPP Council will decide at its next meeting whether to accept
>  > this proposal as an official XEP.
>
>  I'm sure there is some security implication that I'm missing, but why
>  do we need to make the hash of the repeater ID so tightly coupled
>  with the recipients list?
>
>  I understand the need of keeping the ID unique but I fail to see what
>  else is gained by this complexity.
>
>  On the other hand, the use of an ID that doesn't change each time we
>  update the recipients list would be easier to work it in the presence
>  of multiple senders.
>
>  Regarding the use of repeaters for <presence>, maybe we should just
>  use the domain of the users as a virtual repeater, like PEP is a
>  virtual pubsub at the users domain. This was suggested two years ago,
>  btw.
>
>  The roster at the remote host could be used as the distribution list,
>  no need for costly updates. Just reverse-query the roster if your DB
>  system provides that (easy for SQL-based rosters, not as simple for
>  LDAP-based ones).
>
>  Best regards,
>  --
>  Pedro Melo
>  Blog: http://www.simplicidade.org/notes/
>  XMPP ID: melo at simplicidade.org
>  Use XMPP!
>
>
>

Right. I think for its most common use case, MUC or PubSub, you will
end up with one repeater for each room(MUC) or node (PubSub) and if
those IDs change each time someone joins or leaves it just adds
complexity.
A similar optimization could be done by removing deletion of a
repeater by its creator and hand that task off to the repeater
component itself. MUC and PubSub codes don't have to care about a
repeater when they don't need it anymore; just forget about it. The
repeater component removes unused repeaters after a certain timeout
and informs the creator with a message.

Tobias



More information about the Standards mailing list