[Standards-JIG] proto-JEP: Address lists
hildjj at gmail.com
Thu Jun 8 06:10:09 UTC 2006
I'm interested in this approach. Couple of questions.
1) Who creates the list name? If the lists are almost always
automatically created on my behalf by my server, I'm guessing the
hash is MUCH more important than the name.
2) Is the list scoped to a particular from address, or if a different
person wants to send to the same list, (has the same hash), can it be
reused? This is probably just a security considerations detail.
3) What about servers that have multiple domains hosted? Is it
possible to determine that a given multicast service works for
multiple domains? Do you just create the list with everyone,
preserving JEP-33 semantics, and the receiving multicast server only
forwards to "local" domains?
4) Aside from pending question 3 above, all of the addresses in the
list MUST have a domain that is hosted on the receiving server. This
is to prevent the receiving server trying to send on behalf of a jid
it doesn't own. Server-to-server XMPP should block that, one hopes.
It's possible to create lists on the originating server, that don't
need this restriction. However, this defeats the purpose of the
list, since no traffic is optimized.
5) I'm guessing that the full JEP-33 semantics get perturbed, unless
the approach in question 4 is taken. This means that if you wanted
to do MSN-style end-to-end multi-way chat, you couldn't use this
6) It would be nice to have more examples, particularly around the
actual message that gets delivered to the receiver.
On Jun 6, 2006, at 5:33 PM, JEP Editor wrote:
> The JEP Editor has received a proposal for a new JEP.
> Title: Address lists
> Abstract: This document specifies extension to Extended Stanza
> Addressing to create and reuse lists of addresses.
> URL: http://www.jabber.org/jeps/inbox/address-lists.html
> The Jabber Council will decide within 7 days (or at its next
> meeting) whether to accept this proposal as an official JEP.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1883 bytes
Desc: not available
More information about the Standards