Robin Redeker wrote: > Maybe best would be to make the default behaviour broadcasting and > then specify a way to configure the handling of this case by eg. ad-hoc > commands on the server for an account. Then the RFC could say: > > "Unless other behaviour was configured for an account the server > SHOULD/MUST broadcast the message to all resources with same > priorities." > > That might be a bit overkill, but it would be a defined, simple and most > reliable default handling for that case. And with per account > configuration it would even be open to future "more intelligent" > routing.
The relevant text regarding delivery of messages to bare JIDs (section 8.3.1.1 of rfc3921bis) currently reads: 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. As I've said before, I think that needs to be adjusted so that sending to all available resources is recommended. I suggest the following text: If two or more available resources have the same priority, the server SHOULD deliver the message to all available resources. However, the server MAY use implementation-specific or deployment-specific rules (e.g., most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of <show/> values) or user-configured rules (as specified according to a defined XMPP extension or an implementation-specific or deployment-specific feature) in determining the resource to which it will deliver the message. What this means is that the server should deliver to all resources in this case [1], we really encourage you to do that, and you shouldn't stray from this recommendation unless you have good reasons for doing so. However, if the server has knowledge that enables it to deliver more intelligently, it may try to do so. We leave open what that knowledge is and whether the resulting behavior really is more intelligent. We do that because (1) this is a corner case, (2) we haven't defined a protocol for account configuration yet, but we don't want to close the door to such a protocol, and (3) we also don't want to close the door to integration with rules engines, advanced presence systems, geolocation systems, activity-based computing, lifestreams, or whatever all else people dream up in the future. In this kind of instance, we recommend what we think makes the most sense now, but we optionally leave things up to the implementation or deployment if something smarter comes along. IMHO we don't need to specify every little detail in this kind of corner case. And if you don't like the optionally-chosen behavior of your implementation or deployment in this corner case, you are free to choose a different implementation or deployment, file a bug report, or (we hope) modifiy the source code. /psa [1] With the proviso that you never deliver a message addressed to the bare JID to an available resource that has negative priority.
smime.p7s
Description: S/MIME Cryptographic Signature
