[Standards] XEP-0354: Customizable Message Routing - Council Remarks
flo at geekplace.eu
Tue Oct 21 17:52:55 UTC 2014
Thanks for accepting CMR as XEP-0354. :)
I'd like to reply to the comments made by the council meeting (2014-09-24):
Two members suggested to replace <available /> with disco. This was
actually the case in one of my first drafts. But I then realized that a
get/result IQ was necessary by the client, to determine the current CMR
state and decided to put the available algorithms there too. The
motivation was to avoid adding more disco features besides 'cmr:0' in
order to increase the chance that entity capabilities between different
servers still match. I know that this is a minor optimization. But I
don't see a real advantage of using disco in this case, as you don't
even avoid an additional round-trip (in most cases). It also feels right
to split the feature (announced in disco) from the featured algorithms
(announced in IQ result).
But if this is a show stopper, I'm willing to put the available
algorithms into the disco result.
[15:07:50] <Tobias> i'm unsure about the use case, the use case section
more describes the use cases for different routing rules...less so the
use case for discovering those dynamically
The dynamic discovery is not really an feature of CMR, it's more an side
effect. What's important is that different routing algorithms can be
used on the same service.
[15:10:42] <Tobias> Kev, yeah..but what would it benefit a client
knowing the server does routing X instead of routing Y?
While clients that typically use CMR would always use a server that is
under the same entities control that also controls the clients, it's
still good to know that the service is able and does actually route the
messages as the client expect them to route. Again this is just a side
effect of allowing different routing algorithms on the same service and
for different clients (having a different bare jid).
[15:10:46] <Lance> it would probably be worth giving more explanation on
why this is different than carbons, or how the two interact. this spec i
assume is more for bots & iot than humans
Carbons, if enabled, still only send the message to *all* (carbon
enabled) resources. This doesn't allow for load-balancing, CMR does.
Roughly speaking, Carbons is ideal for human interaction, CMR is ideal
I hope to have addressed all the issues mentioned and be happy to
discuss further points regarding CMR.
The current version of CMR can be found at
More information about the Standards