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

Mridul mridul at sun.com
Tue May 30 10:32:02 UTC 2006

Hi Carlo,

  Please see inline.


Carlo v. Loesch wrote:

>| Mridul wrote:
>| > The implicit creation of a list could go out of sync very fast , does
>| > not take care of updates to privacy profiles and looks very 'hackish' imo.
>| > Why not make it explicit ?
>You are talking about the first proto-JEP, not the current one I'm afraid.
>We have indeed gone through these aspects before and have rewritten the
>JEP to use the outgoing presence information rather than the rosters, so
>according to the current proto-JEP, privacy profiles are fully supported.

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.
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.
This IMO is not very desirable and can break at quite a lot of cases.
Functionality cannot be compromised for efficiency/optimization.
Using rosters was totally broken IMO - good to see that the JEP authors
have moved away from that approach !

>| > 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.
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.

Ofcourse , not pushing for this :-) I am sure there might be other
better ideas ... just an alternative to what is being proposed.

>| > similar in ways to muc I guess.
>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.

>Richard Dobson typeth:
>| This was my original suggestion, but they seem to be very against it for 
>| some reason, they have still yet to really explain why.
>Your idea was to combine JEP-0033 syntax with our idea of keeping state
>in form of context lists on the recipient side. That is a possible way
>to go about it, but it is redundant with the way presence is to be sent
>out according to RFC 3921. If you're going to make a completely new
>distribution scheme for presence, you are either being redundant, or
>disabling large parts of RFC 3921 in your interserver communications.

I do not see how there are significant savings when comparing what
Richard proposed to what is currently proposed in the proto-JEP ...
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.
Without the guesswork , security issues, etc.
There is no need to be different just to be "new" :-)
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

That being said , these are subset of problems we had to solve in our
server pool implementation (since it is within the same external server
, we could do a more efficient form of what was initially proposed :-) ).
If something like this makes into s2s , it will be good for all - but it
should not be at the cost of broken specs and loss of functionality.

Ofcourse , there could be valid reasons why not to take this approach if
there are implications with what is yet to be published.

>Our new proto-JEP makes use of the presence distribution according to
>RFC 3921 and only delicately extends this to re-use the information and
>save on bandwidth. I am sorry you didn't notice there is fundamental
>difference from our earlier proto-JEP to the current one. I think it
>has even doubled in size.  :-)

This reuse is not proper reuse - it is introducing guesswork into the
whole 'construction of the initial list' process.

>| > Either we can expose ways to add/delete jid's to this list , or just
>| > recreate a new list depending on what gets decided here.
>Yes that's what we have. Look at the List Use Cases in 5.2 of

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

>| > If the receiving server sends an error about list unavailability ,
>| > initiating server can recreate the list again.
>Correct, see 5.2.4.
>| > If some of these lists are constant/static , these lists could be reused
>| > for different users as an optimization - need not be specific to a user.
>| > (Like an admin group , etc) - just a thought , we need not get into this :-)
>| >   
>| Yes exactly.
>That's a possible extension for completely different purposes than Presence
>or MUC. Yes, the lists could undoubtedly be extended in such a way, if a
>good JEP takes care of all the necessary steps.

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 ?

>| > Just to add , if this gets supported , it will need to be a stream
>| > feature I think ... not specific to a user/group/etc.
>| >   
>| It would be a disco feature, rather than a stream feature.
>We have gone through that and opted for disco.
>| > We could extend this to other 'needs' also.
>Yes, we have even looked at how Pubsub can work with context lists
>on the receiving server side. It's not easy because it would need to
>define many lists for each combination of user settings, like digest
>vs no-digest etc. etc.
>| don't worry, yes ive already suggested this, even though they seem to be 
>| ignoring it, more fuel on the fire, good to hear minds are thinking alike :)
>No Richard, we have gone through all the suggestions we got, taken them
>seriously, and come up with an in large parts new solution, so please come
>and take a look at it.  

Definitely , these are my first impressions of the JEP.
Keep up the effort !


More information about the Standards mailing list