[jandrewrogers]

This write up is right on the mark. There are quite a few things about MQTT that seem to have the goal of supporting legacy expediency. At the same time, these dubious design elements undermine the nominal goals of the standard and in some cases flat out contradict those goals.

We know how to design modern, efficient, flexible wire protocols that can be driven at the rates required by M2M communication patterns. MQTT does not fit this description nor even makes an attempt to reflect best practices within its current scope.

[tkellogg]

For the life of me I can't find anywhere that says "extensibility" is a goal of MQTT. The main goals are clearly stated to be "simplicity" and "lightweight". Extensibility is the enemy of both. A lot of Clemens' points are based on the concept that MQTT is supposed to be extensible. When you realize that's not even a goal, most of his concerns become moot. He says "I'm not trying to create another AMQP" but if you think about what he's actually saying, it's quite the opposite.

[clemensv]

There are not many modern app-level protocols and much fewer messaging protocols that don't allow for any end-to-end message metadata; at a minimum declaring what the payload content of a message is, when the message was generated, and an end-to-end ID. Content-type could be a mere byte the client sends to the app and where 0x01 spells "JSON". CONNECT shows how you can have a bitfield that can control the presence of headers. You can control the presence of 4 subsequent optional headers with 4 shape options in one byte. That's as simple as what happens in CONNECT and just as compact.

There are also not many modern app-level protocols that constrain their opcode-set to 4 bits quasi forever, so extensibility also means to have runway for future extension.

[dragonwriter]

> There are not many modern app-level protocols and much fewer messaging protocols that don't allow for any end-to-end message metadata; at a minimum declaring what the payload content of a message is, when the message was generated, and an end-to-end ID. Content-type could be a mere byte the client sends to the app and where 0x01 spells "JSON".

Sure, and suddenly you're limited to 256 content types, or, more likely, burning an extra byte and still frequently needing to communicate the actual substantive content-type in the payload. If you are going to bother having content-type be part of the messaging protocol, do it right rather than by half-measures.

As I see it, there's a continuum of messaging protocols from barebones (requiring smarter components) to full featured (that require the components to do less because the protocol and broker do more). ØMQ sits close to the first extreme -- call it "the left" -- and AMQP pretty close to what would then be "the right" (at least, the closest of any current open protocol that I am aware of); MQTT seems to be just to the right of ØMQ (I mean, it has a broker).

[dragonwriter]

> A lot of Clemens' points are based on the concept that MQTT is supposed to be extensible.

No, I think they are based on the combination of factors:

(1) A lot of MQTT choices violate the stated design goals in a way which makes sense only to support extensibility,

(2) However, the specific way that MQTT specifies these things also makes them useless for extensibility.

(Plus, an extra serving of speculation about IBM's motivations heaped on top.)

[jamesbritt]

Do you have some ideas for an alternative? Is it plausible, for example, to extend CoAP to cover MQTT use cases?