[Standards-JIG] proto-JEP: Address lists

Michal vorner Vaner michal.vaner at kdemail.net
Thu Jun 8 10:06:26 UTC 2006

On Thu, Jun 08, 2006 at 10:18:28AM +0100, Richard Dobson wrote:
> Personally I think it would be better to use a format like:
> <presence to='multicast.montague.net' from='conference.montague.net/romeo'>
>    <list xmlns='http://jabber.org/protocol/address/list' name='private MUC' 
>    hash='0ea29eb12ceff84d6300d66170eeebc0'>
>        <remove>romeo at montague.net/orchard</remove>
> 	<add>romeo at montague.net/orchard</add>
>    </list>
>    <show>away</show>
> </presence>
> For the adding and removing of items from the list, using the whole 
> JEP-0033 message format seems a bit wasteful bandwidth wise to me for no 
> real gain.
> and using the following format when you wish to broadcast a message or 
> presence stanza to the list without adding or deleting.
> <message to='multicast.montague.net' from='conference.montague.net/romeo'>
>    <list xmlns='http://jabber.org/protocols/address/list' name='private 
>    MUC' hash='624678c1ce4f0cf6497b79cd9bc5822e'/>
>     <body>Julie, I love you</body>
> </message>

Can you use two lists in this approach? And can you merge together?
Maybe it is of no practical use anyway, it seemed to me it might be

But yes, you are right the use of all that URLs and bcc's and so on from
the jep-0033. Maybe I could remake it.

> It seems cleaner to use the top approach for adding and deleting as it 
> means you are broadcasting the message to the list while also adjusting it 
> as necessary.
> What does anyone else think?
> Also a question how does the sender know when its got out of sync? As the 
> spec doesn't seem to address this as far as I can see, all it does is send 
> the hash off to the multicaster, but what happens if the multicaster 
> realises its got out of sync? How does it tell the sender of this fact so 
> it can resync/resend the list?
There are two possibilities. One, a newer version was created, but noone
deleted the old. Then the old one can be still used with the hash, since
the new one has different hash.

Another, the one sender wants does not exist there in that given version
(with that hash). The multicast component finds out it does not have the
requested list, does not broadcast anything and send the stanza back as
an error. As stated in the protoJEP, it MUST include the original
stanza. Therefore the sender can take the stanza, recreate the list and
send it again - resolve the crisis situation, when it happens.

One semi-random fortune: 

Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
                -- Fred Brooks

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/2cf55381/attachment.sig>

More information about the Standards mailing list