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

Carlo v. Loesch CvL at mail.symlynX.com
Thu May 18 08:20:53 UTC 2006

| What you assume is a perfect data set to work with. A perfect history of

We presumed the presence data to be in a better shape, yes.
But still, the worst thing that can happen with rosters not being in
synch is that someone you once sent presence to still gets it.
Sure, the roster synch problem needs to be addressed, but I don't
think ignoring the problem and adding more complexity to a distribution
protocol to navigate around the problem is a good solution. That's
what using JEP-0033 in this case means - you are postponing the solution
to the synchronization bug.

| *regardless of existing conditions and previous events*, in the current
| system, *I* control who gets my presence, as long as -and this is only
| required for THAT moment in time- protocol is followed.
| With this proposal THAT IS SIMPLY NO LONGER TRUE.

You control when you transmit presence. The fact that the list of
recipients is being walked through by you instead of an other server
doesn't make you safer. Anyone, even an end user can plug in a script
that will expose your presence to people you didn't intend to.

So if you are worried about bugs, please help fix them. But if you are
worried by human treason and evil h4x0rs, you already lost the game.

Your worries about the synch problems in Jabber rosters are valid, and
this proposal won't solve them. Still you are rejecting massive traffic
improvement (Matthias' latest figures showed about 50% presence can be
reduced by this proposal) which is not related to the problem.

| Mattias brought up an intresting point here. I tried it on an ejabberd
| server and indeed I could set a roster item with subscription "both" (and  
| get back a result with "both"), this was gone when I re-requested the
| roster though (back to "none"). I wonder what other servers would do... it
| is however not the main point.

We have updated the JEP to make it clear that it MUST be ensured, that
the subscription state has not been 'faked'. I was not aware of such
security problems in servers, but I presume a server developer willing to
implement this JEP would first ensure the roster data he is working with
is safe and reliable.

| But it is a good demonstration of my other points.. while such bugs can be
| fixed (if they exist), it is no longer my *own* server and actions

You cannot have optimized distribution without handing out a little bit of
control. Also the proposal to use JEP-0033 will pass control over to the
other servers, and even the current situation is trivial to abuse for any
user as I said before. I'm sorry you are so emotional about this, but all
we can do is fix the holes in the system.

More information about the Standards mailing list