[Standards-JIG] proto-JEP: Address lists

Michal vorner Vaner michal.vaner at kdemail.net
Thu Jun 8 08:13:13 UTC 2006


On Thu, Jun 08, 2006 at 02:10:09AM -0400, Joe Hildebrand wrote:
> 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.

You speak about the auto-lists? Some names would be registered in the
registrar and some of them could be specific to the service - you could
have an auto-list for an admin, and only the admin would know the name,
that would contain all people on that server.

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

I hope I wrote it in section about the owner of the list. The list is
either specific to bare JID or to full JID, which means different from
address can not use your list.

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

Well, you strip-off the bcc (I hope these are the ones that are hidden
copies) that do not belong to that server. Which is how jep-0033 would
work, yes.

And, hm, maybe if you have a multiple domains using one multicast
service, all of them will present it in its disco with the same address.

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

This is the same as in jep-0033. While creating the list, if you include 
some attribute. I guess it was delivered, or something like that,
indicating the address should not be used again. And this attribute
would be stored in the list as well.

Maybe I should include that in the hash and note it there as well it seems.
I will note this somewhere.

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

Hm, I guess I do not understand this question. Actually, I never used
MSN, so I do not know what you are talking about.

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

Yes, I know. I wanted to present it and hear what people think. This is
not the final version of course.

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



-- 

Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060608/209e77aa/attachment.sig>


More information about the Standards mailing list