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

Mridul Mridul.Muralidharan at Sun.COM
Fri Aug 24 12:22:31 UTC 2007

Using same priority for all resources, and expecting messages to be
delivered to all resources is not the right expectation. This is
precisely the reason why priority is configurable at the client side -
and clients need to use it appropriately.

If you have multiple resources of same priority, as Joe Hildebrand
mentioned, it is up to the server to determine which resource to receive
it - for some very valid reasons : some of which have already been
detailed in the thread. JD Conley also detailed a proposal which can
serve as a guideline for client developers if they so chose to use it.

I dont see the need for the multicast behavior when this can be handled


cJ wrote:
> Hi, I am wondering why the RFC (3921, 11.1) specifies "If two or more available resources have the same priority, the server MAY use some other rule (e.g., most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of <show/> values) to choose between them or MAY deliver the message to all such resources."
> I think the second option can be used to have collective jids (an account used by multiples users) and force messages to get to multiple destinations and doesn't remove functionnality, without adding much complexity to the processing of messages.
> What are the reasons to not make the second option "deliver the message to all such resources" THE ONLY way of handling such messages ?
> If broadcasting messages is not the standard, I think informing the user of the processing done by his xmpp server (the "some other rule") is very important.
> Thank you for your answers,

More information about the Standards mailing list