[Standards-JIG] proto-JEP: Smart Presence Distribution

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Wed May 17 17:52:10 UTC 2006


Philipp Hancke wrote:
> I was assuming that xmpp-im was taking care of that, but it seemingly
> does not (e.g. what if a unsubscribed stanza bounces because a hostname
> is temporarly unavailable).

>From the latest thread about 'assured delivery' and related issues, you may
gather that no system is perfect. But as you can see from these exchanges,
we are actively working at it...

> How is he going to tell multicast.capulet to create a distribution list
> that includes everyone on his roster less those people that are
> on his presence-out list without telling multicast.capulet who is
> on his presence-out list?

You would have to tell us. In fact, I don't think it necessary. A careful
re-reading of JEP-0033 would help you understand that a multicaster is only
there to relay whatever has been inserted in the enhanced addressing
extension. I do not see any provision to actually create the addressing list
in the first place.
Now if you ask me how the list could be created in the first place, I could
imagine that your initial presence handler in the XMPP server could easily
build that list. This handler certainly knows about your roster list
(otherwise it would not do all this broadcast you want to avoid) It also
knows about your privacy lists (otherwise it would not be able to filter
presence-out) It makes it a good candidate to build the extended address
list leaving out the unwanted 'evil' capulets, don't you think?

> On the other hand, the evil capulets can already guess that Romeo
> has blocked Gregory if they see successive presence stanzas to
> Juliet, Nurse, Peter, Sampson, Anthony and Potpan but not Gregory.  

So what? How could they retaliate? A sound and efficient privacy process
does not work by delegation. No honest Montague wants to outsource its own
privacy rules to an 'evil' Capulet's server. Privacy must always reside on
the user's home server. This is a very common end user behavior, haven't you
noticed?

Again, trying to make the presence broadcast more efficient between servers
is an interesting idea. But you would probably agree with me than solving it
may require more than just removing the 'to' in a presence stanza. There are
certainly people on this list who have though about possible solutions, it
would be interesting to hear what they have to say.

Jean-Louis  

-----Original Message-----
Message: 6
Date: Wed, 17 May 2006 18:52:44 +0200
From: Philipp Hancke <fippo at goodadvice.pages.de>
Subject: Re: [Standards-JIG] proto-JEP: Smart Presence Distribution
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <446B54DC.6040600 at goodadvice.pages.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Jean-Louis Seguineau wrote:
>>which is what we do. We only use the roster instead of negotiating a
>>list. This assumes that the roster is synchronized between
>>the two servers of course.
> 
> 
> This 'of course' is the important bit, of course.
Of course it is ;-)
I was assuming that xmpp-im was taking care of that, but it seemingly
does not (e.g. what if a unsubscribed stanza bounces because a hostname
is temporarly unavailable).

Quick thought:
include a 'roster serial', e.g.
<presence from='romeo at capulet/inlove>
    <x xmlns='jabber:iq:roster:serial:whatever' version='2006051705'>
</presence>
(serial format YYYYMMDD##)
That might also be handy for roster retrieval on c2s.
If the receiving server notices a serial mismatch a resync is
needed.

>>How are you going to negotiate that list without disclosing
>>parts of your privacy list to the remote server?
> 
> 
> By not including a particular address on the list for presence-out, and
> blocking for presence-in, why?
What I was talking about...

lets assume Romeo wants to send presence to everyone but Gregory using
's44sdasb4444dedd at multicast.capulet' as a relay.
How is he going to tell multicast.capulet to create a distribution list
that includes everyone on his roster less those people that are
on his presence-out list without telling multicast.capulet who is
on his presence-out list? (assuming that multicast.capulet is also
operated by the evil capulets who know who of the capulets is on romeos
roster).

On the other hand, the evil capulets can already guess that Romeo
has blocked Gregory if they see successive presence stanzas to
Juliet, Nurse, Peter, Sampson, Anthony and Potpan but not Gregory.


 > I am just saying this breaks section 9.1.1 of RFC3920 for s2s
Yes, it does. It uses the semantics for c2s presence stanzas without
'to', i.e. "distribute it on my behalf".
Support for xmpp-heresy needs to be negotiated of course.





More information about the Standards mailing list