[Standards-JIG] proto-JEP: Address lists

Joe Hildebrand 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  
approach.

6) It would be nice to have more examples, particularly around the  
actual message that gets delivered to the receiver.

Great start.

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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1883 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060608/a1bbc9f6/attachment.bin>


More information about the Standards mailing list