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 Addressed with https://github.com/Flowdalic/xeps/commit/3d6a3192e317c1df42419d6c403e1dab0301414b 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 Addressed with https://github.com/Flowdalic/xeps/commit/467674303725d7ebcc6bae8107c16c03af718b01 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 for M2M. 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 http://geekplace.eu/xeps/xep-cmr/xep-cmr.html - Florian
