[Standards] Comment to rfc3921 pt 11.1 : handling of messages to ressources with identical priorities
elmex at x-paste.de
Sat Aug 25 17:45:31 UTC 2007
On Fri, Aug 24, 2007 at 12:11:09PM -0600, Peter Saint-Andre wrote:
> Robin Redeker wrote:
[.snipped arguments for broadcasting.]
> > I actually mostly care about sane and _clear_ and simple semantics for
> > handling cornercases. It clearly defined what users, developers and
> > admins can expect in such cases.
> This feels like an implementation detail to me. At the least, I would
> not want to say that if two resources have the same priority then the
> server MUST deliver to both resources, because that closes the door to
> more intelligent routing based on advanced knowledge that the server may
> have from user-configured routing rules or the like.
The RFC defines whether this ia an implementation detail or not.
Currently the RFC delegates handling of this corner case to the
implementors. If servers are free to handle this case any way they want
they will handle it differently. Users won't have a clue what will
As someone on this thread posted: they even expected broadcasting in the
first place. That expectation might be an exception, haven't made a
poll about this yes :-)
Without a SHOULD the users, developers and admins still can't rely on a
defined behaviour. (defined in a sense that users (and also their
clients) have no idea what behaviour the server is or might be
implemented for this case).
All I want is the ability to tell "Aunt Tillie" what she can expect
when she has two clients with the same priority.
If there is nothing to expect this will happen:
Asking her: "Oh, I don't know what might happen, which server software
and settings has the XMPP server you are using?"
She: "Uhm, I don't know, there is no website."
Me: "Oh, just ask the admin!"
She: "Will do that..." *writes mail/xmpp message to admin*
Admin: "We send the message to a random resource if the priorities are
She: "Thats bad, I don't want that. What should I do?"
Me: "Easy, just pick a server which does the right thing."
She: "Which would be a server that just broadcasts the messages to all
Me: "Easy, just go to http://www.jabber.org/user/publicservers.shtml
and send mails to all admins to ask them."
She *does that*
She: "Ok, got it now, 12jabber.net does it. I've created an account
there now, but now I have to move my roster there and reprint my
I don't know what the user will expect, some seem to expect broadcasting
other some clever algorithm like: "last resource that sent a message",
or whatever. But they certainly won't have much abilities to find it
out or rely on a default behaviour.
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
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"
More information about the Standards