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

Mridul mridul at sun.com
Tue May 30 13:21:21 UTC 2006

Hi Carlo,

  Please see inline.


Carlo v. Loesch wrote:

>Mridul typeth:
>| Maybe I did not explain it properly enough - I am referring to
>| "http://www.jabber.org/jeps/inbox/smartpresence.html".
>| I was referring to the way the JEP is using outgoing presence info to
>| cobble together a list on the fly in section 5.
>The term "cobble" implies that the process is not well defined, but it is.

I am not really sure how it is well defined.
The impression I got was that the following assumptions are being made -
which are incorrect :
1) There will not be a directed presence getting sent until the presence
broadcast is delivered : not valid.
The JEP uses this initial presence burst to create the list.
2) Privacy list issues. It makes the assumption that disabling
presence-out implies sending an unavailable presence to the remote user.
This is not a MUST requirement if I am not wrong.
3) The 'list management' is not explicit - and is a potential landmine
of impl bugs.
Example from JEP where this could fail : probe getting sent before the
broadcast is over , probe not getting sent , case (1), etc.
4) The JEP is depending on observed behavior - not defined behavior
(preferably should depend on MUST requirements) : this is not a good way
to gaurentee robust behavior.

I am sure I am missing more points ...
That being said , I would really like to see some savings in s2s.

>| It is making assumptions as to who all are in my roster based on the
>| behavior of who all I send my presence updates to , or want the info to
>| be sent to.
>Incorrect. It remembers who you have sent presence to and whom you will again
>later. If you change the privacy list, the change will propagate to all
>involved servers.

Please see above , I think you are assuming (2) for this.

>| This IMO is not very desirable and can break at quite a lot of cases.
>No. Name one.

Other than the ones mentioned above : for a list recreation , do you
need to send a presence burst again ?
Considering the chances of how list's could get out of sync (can be
validated if there is a way for the initiating server to query for the
jid's in a list) , this is a very high cost if it happens frequently
enough ...

>| Using rosters was totally broken IMO - good to see that the JEP authors
>| have moved away from that approach !
>Not because the approach was broken, but because in Jabber rosters
>operate in a way that cannot be trusted upon. That's okay, every
>chat system has its culture, and we made a wrong presumption on
>the safety of rosters in Jabber. No problem. We sat down and came
>up with a different solution.

I was talking from the context of XMPP :-) For XMPP , the approach is
Btw , the approach was not broken 'cos I could arbitrarily modify my
roster (well , I can and so also broken - but that is a different issue)
: it is not just a matter of impl - it is a matter of trust and
I trust my local server to enforce my requirements : I can take my admin
to task if he does not - not a remote server's admin.
There has been enough mail traffic on that issue though :-) So I guess I
will just leave it at that and not create more.

>| >| > The initiating server can request for a list creation with a set of bare
>| >| > jid's and then use that as 'to' in subsequent presence stanza's -
>| >
>| >Yes, this is how the context lists operate.
>| Exactly , why not use this ?
>| Create a new list on the fly on the remote server with the required
>| barejid's, and use that list as recipient to send presence updates to.
>Yes. That's what happens, although it's a bit more deterministic than
>"on the fly."

The bounds within which the list is created are very shaky.
You are assuming server implementation details (send presence broadcast
, then probes , all point from 1 , 4 above , etc) for ensuring it to work.
Mind you , if the assumptions were valid , it would work beautifully -
unfortunately , it is not the case IMO.

>| The new list would take care of fanning out the updates to its local users.
>| The traffic improvements would still be significant considering that the
>| extra overhead is :
>| a) list creation.
>| b) list-recreation in case it has gone out of scope.
>| I dont think this is entailing the security issues discussed with the
>| roster approach , or the guesswork that the current approach is
>| attempting on.
>Correct, that's why our current proto-JEP is pretty good.
>Thank you.  :)
>| Ofcourse , not pushing for this :-) I am sure there might be other
>| better ideas ... just an alternative to what is being proposed.
>No, you are describing exactly what the proto-JEP does.
>| >MUC doesn't do that yet, but our pre-proto-JEP on "smartchat" suggests
>| >just that.
>| What I was referring to was the fact that - you send a message to the
>| 'room' , all resources in the room (that is users) get this message :
>| same concept is used for lists and what we are talking about here I guess.
>It has been discussed on this list in February, that both groupchat and
>presence are a one-to-many operation. It has also been discussed on IMPP
>in 1999. Unfortunately XMPP has taken zero provisions for one-to-many
>addressing and routing, that's why we're working out something now.

Unfortunately , I do not have context about these discussions : I was
not part of them , neither can I find the relevant archives about the
discussions (except for jig).

>In PSYC we have already implemented both presence and groupchat using
>the same multicast contexts, same algorithms and data structures.
>We noticed how we just can't solve it as elegantly in our XMPP
>implementation and would like to lay the fundaments to do that.

If you can make assumptions about integrity , validity and trust - then
all these problems "go away" to a large extent. This is what we could do
with server pools.
Unfortunately when federating XMPP servers , they are not real world
So for wider adoption , it makes sense to have something which will not
create any newer bottlenecks in terms of security or implementation :
neither something which will expose existing issues to exploitation.

>| I do not see how there are significant savings when comparing what
>| Richard proposed to what is currently proposed in the proto-JEP ...
>Both suggestions are using the same concept of context lists on the
>receiving side, so they are both fundamentally right. Richards plan
>however makes Presence as it is defined in XMPP IM 5.x useless,
>whereas we keep on using it. It's a question of taste, I personally
>don't mind rewriting the XMPP RFCs, but it is certainly out of the
>scope of a new JEP then.

I am not sure if his proposal was making it useless.
It was making use of the concept of lists to achieve the required
There is a usecase for directed presence , there is one where a list
might help.
If similar functionality is achieved without breaking the spec and gives
similar performance metrics , then what is wrong or useless with the
approach ?

If nothing , this JEP has brought some interesting points to ponder over :-)

>| Other than a 'to' being added to the presence stanza for a random list
>| (and potential list recreation if what I mention above is implemented) ,
>| the 'cost' is the same.
>We were asked to re-introduce the 'to' in respect to the XMPP RFCs.
>Our original suggestion was to leave it out, just as is being done
>in the client to server protocol when sending <presence/>

Leaving out the 'to' is a non-starter.
Not just from the point of view of breaking the spec , but also from the
fact that you are totally ignoring hosted domains and similar features.
But this is also something which has been discussed in detail - so
leaving it at that.

>| Without the guesswork , security issues, etc.
>| There is no need to be different just to be "new" :-)
>What guesswork? What security issue? And who's trying to be new and different?
I mentioned "guesswork" regarding the list population and management.
"security issue" comes from the way presence-out issue is not managed in
the new list , and in the old roster approach.

>| If it makes sense , we should consider - but as much as possible , it
>| makes sense to integrate with existing proposals and protocols : they
>| are already in use and will be easier to implement and extend for all
>| concerned.
>Exactly, that's what our proto-JEP does and Richard's proposal doesn't.

I think there might be more implementation of JEP 0033 than what you
propose :-)
So it would be easier to get something along those lines accepted as
compared to something new.
Not that this is a good enough reason not to innovate ! Just pointing
out the obvious...

>| This reuse is not proper reuse - it is introducing guesswork into the
>| whole 'construction of the initial list' process.
>You seem to enjoy wild assumptions, but you are wrong.

I dont see how , but this is becoming petty.

>| Saw that , I was just commenting w.r.t what I was thinking about : I did
>| notice that the proto-JEP mentions similar stuff :-)
>It defines operations, not similar stuff.

Operations are useless unless the initiating entity knows what it is
operating on.
I did not see a list-jids/query operation on the list : so the rest of
the operations may not be very useful.
Assuming you add that too , validation of the list will be as expensive
as creating a new one !

>| Exactly - it would become a generic : create "random lists" sort of thing.
>| How you use these lists would be implementation dependent.
>| Could be for MUC , for presence broadcast , etc ... not necessarily for
>| multicast.
>| The "life" of a list is also not gaurenteed - except for reasonable
>| limits like atleast one operation on the list , prevent abuse by
>| throttling number of lists being created , etc.
>| But then I think something like this is already in place right ?
>You are thinking all along our lines. Just because we use the *existing*
>syntaxes to populate certain lists that serve a certain purpose doesn't
>mean you can't use those lists in a different way, populating them with
>the appropriate protocol to that purpose. The data structures and
>algorithms are there. You think a one-protocol-fits-all approach would
>be nicer - alright, but then you have to do it against the current RFCs.
The problem is simple - not every server is designed this way.
Looking at your descriptions , I know for sure that ours isn't !
In our case , the presence handlers are pretty much abstracted away from
the actual stream - by more than one layer.
This sort of tight coupling as espoused by the JEP is not very practical
(reset lists when stream is closed , etc) ... but that is a different
discussion altogether.
If the idea makes sense , we will need to re-design :-)

>| Keep up the effort !
>Thanks, Mridul.
>I could use a virtual beer now.

Have fun :-)

More information about the Standards mailing list