Harmonization between vendors is good. If all this is is common names for headers and keys to cut down on trivial divergence, this is great. As for the big pic

Harmonization between vendors is good. If all this is is common names for headers and keys to cut down on trivial divergence, this is great. As for the big picture, one of the unfortunate consequences of HTTP having recently won out as the default protocol for remote interaction is having to reinvent or re-frame all of the prior art that's been in use with other platforms. There's half a dozen other pubsub messaging protocols and their associated framing and envelope specs, but they usually define full semantics around addressing and routing -- and usually run on lower-level transports than over HTTP. Since this effort doesn't want to prescribe every facet of messaging, it can't directly define a more restrictive profile or overlay of an existing protocol. Instead, it has to start fresh, and invent yet another envelope format. Someday, someone will ask why there isn't a simple way of getting MessageID or MessageTimestamp across a variety of technologies whose purpose is largely the same, yet I don't think anybody will go back and define a one true mapping between the protocols. If some vendor later decides to accept AMQP as well, they'll write some glue code to translate, but if another vendor accepts it too they'll write their own independent mapper. This is one of the ways that incompatibilities proliferate: actors left to their own devices in the absence of unambiguous guidance. It shows that standards can be both extremely useful and frustratingly bound to fashions.