> 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).
