[Standards-JIG] proto-JEP: Address lists
Michal vorner Vaner
michal.vaner at kdemail.net
Thu Jun 8 18:31:52 UTC 2006
On Thu, Jun 08, 2006 at 01:45:36PM -0400, Etan Reisner wrote:
> On Tue, 6 Jun 2006, 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.
> In line with point 1 of Joe Hildebrand's email, I have to wonder what
> the point of the 'name' attribute of a list is really for. The hash is
> the really important piece of information in terms of identifying lists.
Well, the name is somehow developer-friendlier thing. Besides, the hash
is control, but the name is identifier. You can have different lists
with the same hash, if they have different name.
> As far as I can see the name is really only used when clients don't have
> the hash and just want to use an existing list. Is that really a usage
> we want to allow for/encourage? It would seem to me that the only time
> this is really useful is for using lists that are tied to a bare JID
> from a different client than the one that set the list up in the first
Now, that should not be used at all. The possibility to have bare-jid
wide lists is for MUCs and things like this. In a MUC component, the
messages have many different resources, but it is still one piece of
software, one instance.
> But I'm not sure that this is actually something that makes sense as
> an action. What if the server doesn't know what that list is? As I
> understand it the server is supposed to send an error which lets the
> client recreate the list and then try again, but the client doesn't know
> what the list is that is the problem. If the client did know it could
> have used the hash (which means that it can recreate the list when it
> needs to).
No, this should not be used, of course.
> Did I miss something? Do the names have another use? That is besides
> being human readable (which I don't count very highly because the client
> can keep a name<->hash mapping interally and let the user use the name
> that way).
Well, it will be easier for a developer if he sees the xml stream. And
it may help resolve hash collisions, if they occur. If each room in MUC
keeps its one latest version of the list, it is sure it is unique (the
name, can be based on the name of room) and still has control about the
list being in sync.
> Assuming I didn't miss anything, I would suggest that we make including
> 'hash' a MUST and consider removing 'name' entirely.
Well, I do not want the hash to be must, since, with auto-lists, the
sender does not need to know the precise list, for example. And I do not
see any developer hand-computing the hash. The names are there so it can
I think SHOULD is enough here. Maybe I could lower the MUST on name to
> I hope this was all clear. I have some other comments about the spec but
> I'll send separate emails for them.
There are two types of optimizations. The ones which make the program
slower and the ones which make the user red by missing features.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards