[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 16:52:40 UTC 2007


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.
-------------- 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/e75e12ab/attachment.bin>


More information about the Standards mailing list