[Standards-JIG] proto-JEP: Smart Presence Distribution
mridul at sun.com
Tue May 30 13:21:21 UTC 2006
Please see inline.
Carlo v. Loesch wrote:
>| Maybe I did not explain it properly enough - I am referring to
>| 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
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
>| 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
If similar functionality is achieved without breaking the spec and gives
similar performance metrics , then what is wrong or useless with the
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
>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
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
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
>| 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
If the idea makes sense , we will need to re-design :-)
>| Keep up the effort !
>I could use a virtual beer now.
Have fun :-)
More information about the Standards