I had a (serious) think about what the issues are here, and what to
do about it, over the weekend.
On Mon Aug 27 17:52:40 2007, Peter Saint-Andre wrote:
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.
Right, the problem being here that there's no fixed, conformant, way
of doing things. It's left vague, and vague can mean
non-interoperable. Note that it almost doesn't matter which of the
possibilities is the "correct" way, it's simply that there can be
only one. A common way of specifiying this in a more flexible manner
is to say "Servers MUST do this unless configured otherwise".
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.
(Obviously, "all these resources" or something, since you don't want
it delivering messages to resources with lower priority in this case).
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.
This worries me because if we implement some form "intelligent
routing" mechanism, then the server is then no longer "fully
conformant" to the RFC, even though it's "better", because it breaks
the SHOULD. And if we choose to hand-wave, then this leaves open all
the concerns from the existing text.
What about something more like:
<t>If two or more available resources have the same priority, these
resources are said to form a "priority tie".</t>
<t>Servers MAY support a configuration where one or more resources
are removed from a tie (perhaps by noting last activity time, highest
availability via <show/>, or support for some future extension),
but in the default configuration, no resources SHALL be removed from
the tie. Servers MUST NOT remove all resources from the tie.</t>
<t>After such processing, if any, the message is delivered to all
resources remaining in the priority tie, subject to normal rules.</t>
I ended up restating the problem here, because it seemed clearer, but
the general rule is that servers, by default, broadcast to all
equal-highest-priority resources, but they're allowed to have
non-default configurations which do otherwise.
The last phrase in the last paragraph is worth mentioning - I
couldn't immediately find anything in RFC3921, at least, which said
whether servers can, or should, discount a resource before
considering priority or after it.
I'd have thought that if I have a high-priority resource with a
privacy list, then messages blocked by this should be routed to a
lower priority resource which is willing to accept them, but I've not
looked at how tricky this might be to code.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
