[Standards-JIG] proto-JEP: Smart Presence Distribution
melo at co.sapo.pt
Thu May 18 14:33:46 UTC 2006
On May 18, 2006, at 9:39 AM, Michal vorner Vaner wrote:
> On Thu, May 18, 2006 at 01:54:03AM +0100, Pedro Melo wrote:
>> On May 18, 2006, at 12:41 AM, Tijl Houtbeckers wrote:
>>> On Thu, 18 May 2006 01:06:50 +0200, Pedro Melo <melo at co.sapo.pt>
>>> Even if all servers involved correctly follow protocol, there is
>>> absolutly NO garantuee that someone I do not want to send my
>>> presence to will not end up receiving it.
>> This is only true if someone bypasses the current protocol and adds
>> your jid to his roster, correct?
>> So this would only happen if:
>> - that user that wants your presence has direct access to the
>> database where the roster information is stored;
>> - or the entire server is compromised in terms of security and the
>> user can install forwarding rules.
>> I think that you would agree that if a server follows the current
>> XMPP spec in full, a normal user cannot add your JID to his roster,
> I can add you to my roster without problem without you even knowing
> about it. I thing I could even persuade my server to thing you sent me
If a server allows that without me giving you a presence subscribed,
that is a bug in that server.
> However, you expect that all software is without bugs. A good, secure
> protocol works secure even if the software has few bugs. You say
> "Theretically, this should never happen, so it is not our problem.
> If it
> happens, something is wrong and it is not our responsibility".
No I don't say that. I'm aware of the presence leaks if the roster
get out of sync or if the roster is modified "out-of-band". And this
proto-jep just makes those two problems more evident.
Yet, to do multicast, you need to explode the distribution of the
information that you are sending, on the other side, on the remote
server. It's just the way it works. You explode the distribution in
the last common point. And that means loosing the total control you
expect right now.
All proposals of multicast so far, including JEP-0033 do the final
explosion on the remote side. The difference is where and how is the
distribution list passed on to the remote server.
> The actual situation would need a bug on _my_ server to send
> presence to
> someone I do not want. I can persuade my admin to have a look at
> that, I
> can choose another server, whatever.
I think all the persons on this list that are defending this proto-
jep have already agreed to that this protocol requires more
cooperation from the remote server, to do the final broadcast.
All these protocols are trading S2S traffic for remote server
This protocol would even be useful with a external component. For ex,
in my roster I have about 30 JIDs representing phone numbers of
people so that I can send and receive SMS to/from them. This is
implemented by a transport on my server. But whenever I change my
presence, this transport receives 30 presences, when he only needs 1.
Also the same for any legacy networks gateway.
I won't have any more time for a month or so to follow this thread.
This is my last day, as I'm leaving for some weeks of paternity
leave. I'm sorry to leave the conversation midway, but nature calls :)
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt
More information about the Standards