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 appropriately. Regards, Mridul 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, >
