[Standards] Comment to rfc3921 pt 11.1 : handling of messages to ressources with identical priorities

Robin Redeker elmex at x-paste.de
Wed Aug 22 07:16:45 UTC 2007

On Tue, Aug 21, 2007 at 11:02:09AM -0600, Joe Hildebrand wrote:
> On Aug 21, 2007, at 5:15 AM, Remko Tronçon wrote:
> >When 2 resources are logged in with the same priority, it's probably a
> >lot worse to just let the server pick one, because it will pick the
> >wrong one in 50% of the cases.
> Not if you use a better algorithm.  You've got information from  
> presence that helps you make a better choice than coin-flip.   
> Timestamps, show, etc. are really good at tie-breaking in the real  
> world.

Will that algorithm be a 100% solution or will it just reduce the chance
of picking the wrong resource? I think that the solution to this
problem should be a 100% one, because it's an essential part of XMPP
to deliver messages.

I would rather like a deterministic 'send to all resources with the same
priority' than some heuristic (which can fail) on the server side the
user doesn't know about.

If the proposed algorithm goes into a 'best practices' document we will
likely end up with only 'some' servers implementing leading to a
inconsistent experience for the users of those servers. I don't expect
users to read some website somewhere to figure out whether the server
does what he expects. Some users of course don't even know what to
But the 'send to all resources with the same prio' approach
will seem consistent to them and I argue that this will give the user
a more safe feeling that he just gets the message than having to worry
about servers doing funny stuff to figure out where a message should go

About the nice 'sell 50 shares' example: There is delayed delivery

Will your proposed algorithm provide a 100% solution to the problem and
is also the most likely thing a user expects? Can it also be explained
to a user easily? Or will we have to tell them "there is some algorithm
which is around multiple pages long that determines whether you get that
message or not"?


More information about the Standards mailing list