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

Dave Cridland dave at cridland.net
Mon Aug 27 20:19:42 UTC 2007


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:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list