Hello Paul

Interesting post. It has attracted some attention, for instance in this thread:

http://www.linkedin.com/groupItem?view=&gid=108418&item=239593910&type=member&commentID=138229614&trk=hb_ntf_COMMENTED_ON_GROUP_DISCUSSION_YOU_COMMENTED_ON

As part of this discussion, I found that the comparisons you've made in your blog piece would do good to include a couple of important categories: (Part of a longer response in a longer discussion.)

Security (securing against attacks and exploits):

CoAP: MEDIUM. It has security mechanism, but they are optional. [2]

XMPP: HIGH. Encryption + Client Authentication + Client Authorization mandatory. It is the only solution that has a Client Authorization mechanism. The others cannot implement this, even if they do it as an application specific extension. The protocols simply do not allow it.

REST/HTTP: MEDIUM. It has security mechanism, but they are optional.

MQTT: Low. Sends passwords in clear text. The SSL/TLS solution does not remote the man-in-the-middle attack threat, making it possible to extract passwords in clear text even if communication is encrypted. Since it is done for constrained devices, the probability that safeguards against this is implemented is low.

Provisioning (Configuring IoT networks):

CoAP: Low. No privisioning support is defined for CoAP.

XMPP: HIGH: Ability for operators to provision who can talk to who, what they can see or do, what services are accessible to whom, etc, is available through XEP.0324 [3].

REST/HTTP: Low. Non-existant.

MQTT: Low. Non-existant.

Interoperability (Making things from different vendors understand each other):

CoAP: Low. Content is binary, and proprietary. To make things interoperate, further work has to be done. Limited such work is available in the SENML initiative, but it covers only a very small fraction of use cases for IoT.

XMPP: HIGH. Through XEP-0323 (Sensor Data) [4], XEP-0325 (Control) [5] and XEP-0326 (Concentrators) [6] important use cases for interoperability has already been defined. More extensions in this field is being worked on, and will be published shortly.

REST/HTTP: Low. Non-existant.

MQTT: Low. Non-existant.

So, as a base for Internet of Things, I would say MQTT is a very poor choice. That doesn't mean it's a bad protocol or bad technology. It has its obvious advantages, when it comes to transporting and routing messages using a publish/subscribe architecture in secure and controlled environments. I understand why large corporations want to use it, in settings where they control everything, from sensor, gateways, networks, servers, etc. But, it is simply not suited to be a standard for IoT.

Sincerely,
Peter Waher

[1]: http://xmpp.org/extensions/xep-0322.html
[2]: http://datatracker.ietf.org/doc/draft-ietf-core-coap/
[3]: http://xmpp.org/extensions/xep-0324.html
[4]: http://xmpp.org/extensions/xep-0323.html
[5]: http://xmpp.org/extensions/xep-0325.html
[6]: http://xmpp.org/extensions/xep-0326.html