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

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 27 22:08:33 UTC 2007


Dave Cridland wrote:
> 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".

To my mind, "MUST unless configured to do X" means SHOULD. :)

>> 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).

Nothing is obvious. :) But yes that is a good catch. It needs to read
something like this:

   If there is not one highest-priority available resource but
   instead the highest priority is asserted by two or more
   available resources, the server SHOULD deliver the message
   to all of those 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.
>>
>>
> 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. 

How so? If server-impl-X uses some smarter logic to break the tie, it
has chosen the optional MAY-path instead of the recommended SHOULD-path.
I don't see how that is non-conformant. (And I don't mean in the
tautological sense.)

> And if we
> choose to hand-wave, then this leaves open all the concerns from the
> existing text.

I fail to see how this is hand-waving. It's just an instance of refusing
to close a door if there is no good reason to do so.

> 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 see that as functionally equivalent to the text I posted, except that
you introduce the concept of a default configuration to explain why a
server can choose the optional MAY-path instead of the recommended
SHOULD-path. And I don't know if that is helpful, because it requires
active intervention by a server administator (at the least, choosing
something other than the default configuration) in order to activate the
more intelligent delivery logic. What if the more intelligent delivery
logic is added to the system by embedding an XMPP server into some kind
of broader collaboration suite or somesuch? What if there is no such
thing as a standalone implementation, but the implementation exists only
through a deployment (e.g., Google Talk or some other system in which
the software is a service)? Bogging the spec down with this kind of
implementation and deployment scenario does not especially clarify
things, I think.

However, I do think that the idea of a "priority tie" may help to
clarify matters. But IMHO the phrase "delivery tie" is better, since
what matters is that the tie affects the 2+ highest-priority available
resources (i.e., the resources to which the message would be delivered),
not just any 2+ resources.

Therefore I suggest the following.

   If there is not one highest-priority available resource but
   instead the highest priority is asserted by two or more
   available resources, these resources are said to form a
   "delivery tie".

   In the case of a delivery tie, a server SHOULD deliver the
   message to all of the tied resources.

   However, before delivering the message, a server MAY remove
   one or more resources from the tie.  Methods for doing so are
   outside the scope of this specification, but could include
   factors such as the resource's time of connection, time of
   last network or application activity, availability as
   determined by some hierarchy of <show/> values, or
   user-configured rules.  Nevertheless, a server MUST NOT
   remove all resources from the tie, and MUST deliver the
   message to at least one of the highest-priority resources.

> 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.

Which I phrase as SHOULD deliver to all equal-highest-priority resources
but MAY deliver to less than all such resources.

> 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.

That is not discussed in RFC 3921, nor in rfc3921bis, probably because
we were not as sophisticated back then.

Anyway it sounds like an implementation detail to me. Code it however
you find most efficient, then report back to us with implementation and
deployment experience. :)

> 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.

Right. Typically an XMPP server has lots of messages to delivery. The
more complex the delivery logic, the more difficult it is to code and
(at least potentially) the more latency might be introduced.

In any case, at this point the order of privacy list processing vs.
priority processing (vs. other factors) probably belongs in XEP-0016 as
an implementation note.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070827/7fa1f666/attachment.bin>


More information about the Standards mailing list