This capability comes with a decision problem: which protocol should each application use? The answer is not the same for every client, and choosing the wrong protocol introduces unnecessary overhead, limits feature access, or creates interoperability gaps that surface as production incidents.
This guide provides the complete ActiveMQ protocol comparison, covering AMQP, MQTT, OpenWire, and STOMP while including protocol architectures, performance characteristics, feature access differences, a use case decision matrix, and configuration for both Apache ActiveMQ® and Apache Artemis™.
The Four Protocols: Architecture and Origin
OpenWire: ActiveMQ’s Native Language
OpenWire is a binary wire-level protocol designed specifically for Apache ActiveMQ®, serving as its native protocol since version 4.x. It is currently at version 12 (V12) in the Apache ActiveMQ® mainline, with V13+ development moved to the activemq-openwire sub-project.
The OpenWire protocol operates through structured command objects, essentially an efficient binary serialization of JMS commands. A ConnectionInfo command establishes the connection. A ProducerInfo creates a producer. A Message command sends a message.
A MessageAck acknowledges delivery. The broker is natively aware of these command types, there is no translation layer between OpenWire’s wire format and the broker’s internal message representation.
This is OpenWire’s core performance advantage: zero translation overhead. A Java client sends an OpenWire Message command; the broker directly processes it. By contrast, an AMQP message must be converted from AMQP’s framing format to the broker’s internal format on arrival and back to AMQP on delivery to AMQP consumers.
OpenWire also provides the fullest access to ActiveMQ-specific features: advisory messages, virtual topics, message scheduling, network of broker discovery, and the complete JMS API feature set including XASession for distributed transactions. No other protocol has the same level of integration with ActiveMQ’s internal operations.
Tight encoding: OpenWire’s default configuration uses “tight encoding”, an optimization that compresses the wire format at the cost of slightly higher CPU usage for marshaling. For network-bound workloads, tight encoding reduces bytes on the wire. For CPU-bound workloads, it may be worth disabling via wireFormat.tightEncodingEnabled=false.
Protocol version negotiation: When a client connects, the client and broker negotiate the highest mutually supported protocol version. Older clients using OpenWire v1 will interoperate with newer brokers where backward compatibility is a first-class design principle of the OpenWire protocol.
AMQP Protocol: The Enterprise Interoperability Standard
The AMQP protocol (Advanced Message Queuing Protocol) 1.0 is an open, vendor-neutral binary standard ratified by OASIS in October 2012 and subsequently approved as ISO/IEC 19464:2014. Unlike earlier AMQP versions (0-8, 0-9, 0-9-1), which were heavily broker-model-specific, AMQP 1.0 defines only the transport semantics on how messages are framed, delivered, and settled between peers. The broker’s internal messaging model is out of scope.
Critical distinction: ActiveMQ supports AMQP 1.0 only. It does NOT support AMQP 0-9-1, which is RabbitMQ’s native protocol. These two are incompatible at the wire level and share only a name prefix. RabbitMQ AMQP 0-9-1 clients cannot connect to ActiveMQ’s AMQP 1.0 acceptor.
The AMQP protocol’s architecture is built around links where directed message flows between a sender and a receiver. A link is created on a session, which is multiplexed on a connection. This hierarchy enables efficient resource management and sophisticated flow control:
- Flow control via credits: senders can only transmit messages when they have delivery credits granted by the receiver. This prevents fast producers from overwhelming slow consumers without broker-side flow control mechanisms.
- At-most-once, at-least-once, and exactly-once delivery via settlement semantics, the protocol defines explicit accepted, rejected, and modified terminal delivery states.
- Transactional messaging via a dedicated Coordinator link target, the transaction is managed at the protocol level, independent of the broker’s transaction implementation.
- Rich message format: AMQP messages carry headers, delivery annotations, message annotations, properties, application properties, and a typed body. This self-describing format enables efficient routing and filtering at intermediary nodes without full deserialization.
The AMQP protocol’s broker-model independence is its key architectural advantage: the same AMQP client that talks to ActiveMQ can also talk to Azure Service Bus, IBM MQ, or any other AMQP 1.0 broker. For enterprise integration scenarios where the messaging backend may change over time, or where messages need to flow between different enterprise messaging platforms, AMQP provides true write-once portability.
AMQP client ecosystem: Apache Qpid JMS (Java), AMQP.Net Lite (.NET), Rhea (Node.js), Proton-Python, Azure Service Bus SDKs for all languages, and many others. Any AMQP 1.0-compatible library connects to ActiveMQ’s AMQP acceptor without modification.
MQTT: Purpose-Built for Constrained Environments
MQTT (Message Queuing Telemetry Transport) was originally designed by IBM for telemetry on satellite-linked oil pipeline monitoring in the late 1990s, environments where network reliability was low, bandwidth was precious, and devices were severely resource-constrained. These design origins define every aspect of the protocol.
The MQTT fixed header can be as small as 2 bytes. A complete QoS 0 publish packet, the smallest meaningful MQTT frame, adds only 2 bytes of fixed header overhead to the payload. By comparison, an AMQP frame with a minimal header is tens to hundreds of bytes. For devices transmitting 4-byte temperature readings every 5 seconds over a cellular connection, MQTT’s overhead is categorically different.
We covered MQTT’s full configuration on ActiveMQ – QoS levels, retained messages, will messages, virtual topic subscriptions, TLS, and IoT scaling in our ActiveMQ MQTT Protocol Setup Guide. This section focuses on positioning MQTT relative to the other protocols.
What MQTT is not: MQTT is not a general-purpose enterprise messaging protocol. It has no native support for JMS transactions, message selectors, or the full broker feature set accessible via OpenWire. It maps cleanly to pub/sub semantics on topics. Using MQTT for enterprise services that need transactional message processing or complex routing is using the wrong tool.
The complementary architecture: Many enterprise IoT deployments use both MQTT and OpenWire/AMQP on the same ActiveMQ broker. MQTT handles device-to-broker communication (sensors publish on MQTT topics). OpenWire or AMQP handles broker-to-backend communication (Java or .NET processing services consume from the same topics). The broker routes between protocols automatically.
STOMP: The Human-Readable Option
STOMP (Streaming Text Oriented Messaging Protocol) is a text-based protocol modeled on HTTP’s frame syntax. It is the simplest protocol to implement from scratch; a STOMP client can be written in any language in hours using nothing but string parsing.
STOMP’s text encoding makes it slower than AMQP and OpenWire for high-throughput workloads. It is the right choice for scripting contexts (quick admin scripts, test harnesses, Ruby/Perl/shell integrations) and web application scenarios where simplicity outweighs performance.
This guide focuses primarily on AMQP, MQTT, and OpenWire as the three protocols that require active selection decisions for production deployments. STOMP is covered here for completeness, but it is rarely the production choice over the binary alternatives.
The Protocol Comparison Matrix
| Dimension | OpenWire | AMQP 1.0 | MQTT (3.1.1/5.0) | STOMP |
| Type | Binary, proprietary | Binary, open standard | Binary, open standard | Text, open standard |
| Standard | ActiveMQ-specific | OASIS / ISO 19464 | OASIS (MQTT 5.0) | Informal spec |
| Default port | 61616 | 5672 | 1883 (8883 TLS) | 61613 |
| Performance on ActiveMQ | Highest (native) | High (10-30% below OW) | High (lightweight) | Moderate (text overhead) |
| Protocol translation | None | On every message | On every message | On every message |
| Language clients | Java, C, C++, C# | All major languages | All major languages | All languages |
| Interoperability | ActiveMQ only | Any AMQP 1.0 broker | Any MQTT broker | Limited |
| JMS feature parity | Full | Partial | Partial | Partial |
| Transactions | Full XA support | Local transactions | None | None |
| Advisory messages | Full support | Limited | None | None |
| Virtual topics | Full support | Limited | Via subscriptionStrategy | None |
| Flow control | Producer flow control | Credit-based (native) | QoS 1/2 acknowledge | None |
| IoT suitability | Low (heavy) | Moderate | Highest | Low |
| Enterprise integration | Native | Excellent | Limited | Scripting |
| Apache ActiveMQ® support | Native (5.x) | 5.x | 5.x | 5.x |
| Apache Artemis™ support | Yes | Yes (AMQP 1.0) | Yes (MQTT 5.0) | Yes |
Performance: What the Numbers Tell You
OpenWire’s performance advantage over AMQP on ActiveMQ is consistently observed in benchmarks, with estimates ranging from 10% to 30% better throughput depending on message size, persistence settings, and hardware. The cause is structural: the OpenWire protocol maps directly to the broker’s internal command model with no translation layer.
The AMQP protocol’s performance is not poor, it is a high-performance binary standard, but the inbound translation from AMQP framing to internal format, and the outbound translation back, adds overhead per message.
For context: a performance test comparing OpenWire and AMQP under similar conditions (non-persistent, 1KB messages, single producer, single consumer) showed OpenWire running at roughly twice the throughput.
Persistent messaging narrows this gap considerably because disk I/O dominates the cost, and the protocol translation overhead becomes a smaller fraction of total latency when each message requires an fsync.
Practical implication: For Java-to-Java enterprise services on ActiveMQ, where maximum throughput is the priority and broker lock-in is acceptable, OpenWire is the right choice. For polyglot architectures, cloud-native services, or scenarios requiring broker portability, the throughput difference is the cost of interoperability, and it is usually worth paying.
MQTT performance at scale: MQTT’s small frame overhead and lightweight QoS 0 delivery make it capable of very high connection counts. We covered the virtual topic subscription strategy for scaling MQTT consumers in our MQTT Protocol Setup Guide, including the thread model difference between mqtt+nio and mqtt:// (critical for high device counts). For IoT telemetry workloads, MQTT frequently outperforms both OpenWire and AMQP simply because message payloads themselves are small and protocol overhead is proportionally lower.
AMQP vs MQTT: Choosing Between the Two Open Standards
When evaluating AMQP vs MQTT, the decision almost always maps to the nature of the client. These protocols are not competing alternatives for the same use case; they address different environments.
Choose the AMQP protocol when clients are enterprise services: .NET backends, Python data pipelines, Go microservices, or Java applications that need broker independence. AMQP delivers rich message properties, local transactions, and cross-broker portability. A service written against AMQP today can migrate from ActiveMQ to Azure Service Bus without a client code change.
Choose MQTT when clients are constrained: IoT sensors, microcontrollers, mobile applications, or any environment where memory footprint and bandwidth are limited. MQTT vs AMQP on overhead tells the story plainly: a QoS 0 MQTT publish adds 2 bytes of fixed header. An AMQP frame with a minimal header is tens to hundreds of bytes. On a cellular-connected temperature sensor sending 4 bytes of data every 5 seconds, MQTT’s overhead difference is not marginal.
The complementary pattern: AMQP vs MQTT does not have to be an either/or choice on the same broker. Most enterprise IoT architectures run both, MQTT for device-to-broker ingestion, AMQP or OpenWire for broker-to-backend processing. ActiveMQ routes between them transparently.
| Criterion | AMQP Protocol | MQTT |
| Client environment | Enterprise services (.NET, Python, Go, Java) | IoT devices, sensors, mobile apps |
| Message overhead | Tens–hundreds of bytes per frame | As low as 2 bytes fixed header |
| Transactions | Local transactions supported | None |
| Message filtering | Supported | Not supported |
| Broker portability | Any AMQP 1.0 broker | Any MQTT broker |
| Pub/sub only? | No, queues and topics | Yes, pub/sub only |
| MQTT 5.0 features | N/A | Apache Artemis™ only |
Cross-Protocol Message Routing: The Translation Layer
One of ActiveMQ’s most powerful capabilities is that a message published via one protocol can be consumed via another. A Python service publishes an order event via AMQP. A Java service consumes it via OpenWire. An analytics script subscribes via STOMP. All from the same queue, on the same broker, in real time.
The translation happens inside the broker’s protocol converter layer. Each incoming message is converted from its wire format to the broker’s internal representation. Each outgoing message is converted from internal format back to the target protocol’s wire format. This is transparent to both producer and consumer, neither needs to know what protocol the other is using.
Translation caveats:
- Message body type preservation: The AMQP protocol supports a typed body model (data sections, AMQP sequence sections, AMQP value sections). When an AMQP message is delivered to an OpenWire consumer, the body arrives as a BytesMessage. The type information may be lost. If you need typed body preservation across protocols, use AMQP’s JMS mapping conventions in your AMQP clients, this ensures the broker converts the AMQP body to the correct JMS message type.
- Header mapping: JMS message properties (set via setStringProperty(), setIntProperty()) survive cross-protocol routing via the application-properties section of AMQP and as custom headers in MQTT. However, MQTT’s message model is simpler — it carries only a topic and payload; properties in JMS messages that cross MQTT boundaries may not survive.
- Feature degradation: Features that are protocol-specific, such as JMS message selectors, advisory topics, and virtual topics, are not available to clients using protocols that don’t support them natively. An MQTT client cannot use a message selector to filter messages from a queue. This is a hard architectural constraint, not a configuration limitation.
- Advisory messages and MQTT: Apache ActiveMQ® uses advisory messages extensively for connection tracking, temporary destination management, and the coordination of a network of brokers. MQTT clients on Apache ActiveMQ® do not receive or send advisory messages that they operate outside the advisory system. Ensure your advisory topic authorization configuration accounts for this when MQTT and JMS clients coexist on the same broker.
Configuring Protocols on Apache ActiveMQ® and Apache Artemis™
Apache ActiveMQ®: Transport Connectors
| <!– activemq.xml — multi-protocol production configuration –> <broker xmlns=”http://activemq.apache.org/schema/core” brokerName=”prod-broker”> <transportConnectors> <!– OpenWire: native JMS clients, Java microservices –> <transportConnector name=”openwire” uri=”nio://0.0.0.0:61616 ?maximumConnections=2000 &wireFormat.maxFrameSize=104857600″/> <!– OpenWire over TLS –> <transportConnector name=”openwire-ssl” uri=”nio+ssl://0.0.0.0:61617 ?maximumConnections=2000″/> <!– AMQP 1.0: polyglot enterprise clients (.NET, Python, Go) –> <transportConnector name=”amqp” uri=”amqp://0.0.0.0:5672 ?maximumConnections=1000 &wireFormat.maxFrameSize=1048576″/> <!– AMQP 1.0 over TLS –> <transportConnector name=”amqp-ssl” uri=”amqp+ssl://0.0.0.0:5671 ?maximumConnections=1000″/> <!– MQTT: IoT device fleet –> <transportConnector name=”mqtt” uri=”mqtt+nio://0.0.0.0:1883 ?maximumConnections=10000 &transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/> <!– MQTT over TLS (preferred for production) –> <transportConnector name=”mqtt-ssl” uri=”mqtt+nio+ssl://0.0.0.0:8883 ?maximumConnections=10000 &transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions”/> <!– AUTO: single port protocol detection (Classic 5.13+) –> <!– Useful for environments where port segregation is difficult –> <!– <transportConnector name=”auto” uri=”auto+nio://0.0.0.0:61618?maximumConnections=3000″/> –> </transportConnectors> </broker> |
AUTO transport: From Apache ActiveMQ® 5.13.0, a single transport connector can automatically detect the protocol from the client’s initial handshake bytes. This is useful for environments where firewall rules limit port choices. It works for OpenWire, STOMP, AMQP, and MQTT. The performance cost is minimal, protocol detection adds microseconds per connection establishment, not per message.
Apache Artemis™: Multi-Protocol Acceptors
| <!– broker.xml — Artemis multi-protocol acceptors –> <acceptors> <!– Default multi-protocol: OpenWire, AMQP, STOMP, MQTT, Core, HornetQ –> <acceptor name=”all-protocols”>tcp://0.0.0.0:61616 ?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;useEpoll=true</acceptor> <!– Dedicated AMQP acceptor with tuned parameters –> <acceptor name=”amqp”>tcp://0.0.0.0:5672 ?protocols=AMQP;amqpIdleTimeout=0;amqpCredits=1000;amqpLowCredits=300 ;directDeliver=false;batchDelay=10</acceptor> <!– Dedicated MQTT acceptor for IoT fleet –> <acceptor name=”mqtt”>tcp://0.0.0.0:1883?protocols=MQTT</acceptor> <!– MQTT over TLS –> <acceptor name=”mqtt-ssl”>tcp://0.0.0.0:8883 ?protocols=MQTT;ssl=true &keyStorePath=/etc/artemis/certs/broker.ks &keyStorePassword=${ssl.keystore.password}</acceptor> <!– AMQP over TLS for enterprise clients –> <acceptor name=”amqp-ssl”>tcp://0.0.0.0:5671 ?protocols=AMQP;ssl=true &keyStorePath=/etc/artemis/certs/broker.ks &keyStorePassword=${ssl.keystore.password}</acceptor> </acceptors> |
The Apache Artemis™ AMQP acceptor tuning parameters deserve attention:
- amqpCredits=1000: Initial credit granted to each AMQP sender, indicating how many messages a producer can send before awaiting credit replenishment. Lower values increase flow control responsiveness; higher values improve throughput.
- amqpLowCredits=300: Credit threshold at which the broker proactively sends more credits. Setting this at ~30% of amqpCredits provides smooth throughput without credit starvation.
- directDeliver=false;batchDelay=10: Instructs Artemis to batch deliveries on a 10ms cycle rather than delivering each message immediately on arrival. For high-message-rate scenarios, this significantly improves throughput at the cost of up to 10ms added latency.
Protocol Selection Decision Framework
Choose OpenWire when:
- All clients are Java (or JVM-based), and maximum throughput within the ActiveMQ ecosystem is the priority
- You need the full JMS feature set: XA transactions, advisory messages, virtual topics, message selectors, broker-to-broker network connectors
- You are building on Apache ActiveMQ® 5.x or Apache Artemis™, and do not have cross-broker portability requirements
- You are extending or building ActiveMQ-native tooling (monitoring, management, test harness)
Do not use the OpenWire protocol when: you have non-Java clients in any language without an existing OpenWire library, or when broker portability (potential migration to Azure Service Bus, IBM MQ, or any other AMQP 1.0 broker) is a requirement.
Choose the AMQP Protocol when:
- Your architecture includes clients in multiple languages (Java + .NET + Python + Go + Node.js)
- You need interoperability with other enterprise messaging platforms (Azure Service Bus, IBM MQ 9+, Solace, etc.)
- You are building a cloud-native application where the messaging backend may evolve over time
- You are publishing messages that Azure Service Bus, Kafka (via AMQP bridge), or other platforms need to consume
- Your security requirements include SASL EXTERNAL (certificate-based client authentication via AMQP)
Do not use the AMQP protocol when: all clients are Java and maximum throughput on a dedicated ActiveMQ deployment is the sole priority. AMQP is the right choice when interoperability is a real requirement, not a theoretical future consideration.
Choose MQTT when:
- Clients are IoT devices, microcontrollers, mobile applications, or any environment where memory footprint and bandwidth matter
- You need device-level QoS semantics (at-most-once, at-least-once, exactly-once) with will messages for fleet monitoring
- The client side will be diverse languages/platforms, with only pub/sub patterns needed
- You are using MQTT 5.0 features (Artemis only): flow control via receiveMaximum, topic aliases, enhanced authentication
Do not use MQTT when clients need JMS-style message selectors, transactional message processing, or access to JMS-specific features. MQTT is pub/sub only, it does not map to queue/consumer semantics beyond the basic patterns.
Choose STOMP when:
- You are writing a quick test harness or admin script in Python, Ruby, Perl, or shell
- The client environment genuinely cannot use binary protocols
- Simplicity of implementation outweighs performance
Multi-Protocol ActiveMQ Deployment: Get It Right the First Time
Mixing protocols on a shared broker introduces translation overhead, authorization complexity (per-protocol security configurations), and monitoring blind spots (per-protocol connection counts). MeshIQ’s experts have designed and reviewed multi-protocol enterprise deployments and can help architect your protocol strategy for correctness and performance.
Talk to an ExpertProtocol Support Across Apache ActiveMQ® and Apache Artemis™
One important dimension of protocol selection is the feature completeness per broker version:
| Protocol Feature | Apache ActiveMQ® 5.18.x | Apache Artemis™ 2.x |
| OpenWire (all versions) | ✅ Native | ✅ Supported |
| AMQP 1.0 | ✅ Supported | ✅ Native (Core + AMQP) |
| AMQP 0-9-1 | ❌ Not supported | ❌ Not supported |
| MQTT 3.1 / 3.1.1 | ✅ Supported | ✅ Supported |
| MQTT 5.0 | ❌ Not supported | ✅ Supported |
| STOMP 1.0 / 1.1 / 1.2 | ✅ Supported | ✅ Supported |
| WebSocket transport | ✅ (all protocols) | ✅ (all protocols) |
| AUTO protocol detection | ✅ (5.13+) | ✅ (default port) |
| AMQP over WebSocket | ✅ | ✅ |
| MQTT over NIO | ✅ (mqtt+nio) | ✅ (implicit) |
The MQTT 5.0 gap in Apache ActiveMQ® is significant for IoT deployments that want to use MQTT 5.0’s flow control (receiveMaximum), topic aliases, or enhanced authentication. If these features matter, Artemis is the required broker. We covered the Apache ActiveMQ® vs Apache Artemis™ architecture differences, including protocol support as a migration criterion in our ActiveMQ vs Artemis: 2026 Definitive Guide .
Monitoring Protocol Usage
With multiple protocols active on a broker, understanding which clients use which protocol is important for capacity planning and incident diagnosis. In Apache ActiveMQ®, TotalConnectionsCount reflects all connections regardless of protocol. Protocol-specific connection counts are not directly exposed as individual JMX metrics, but the transport connector MBean provides per-connector statistics.
For multi-protocol monitoring on Artemis, the artemis_connection_count metric labeled by acceptor name gives per-protocol connection breakdowns:
| # Connections per protocol acceptor on Artemis artemis_connection_count{acceptor=“amqp”} artemis_connection_count{acceptor=“mqtt”} artemis_connection_count{acceptor=“all-protocols”} |
We covered the full monitoring and alerting setup in our Monitoring & Alerting Setup post. For multi-protocol deployments, add per-acceptor connection count monitoring to your baseline alerting, a sudden drop in AMQP connections while OpenWire connections remain stable narrows a connectivity incident to a specific client type immediately.
Protocol Is Architecture: Choose It Early, Change It Rarely
The protocol your applications use is not a configuration detail, it is an architecture decision. The OpenWire protocol locks clients to ActiveMQ but delivers maximum feature access and throughput. AMQP 1.0 provides broker-independent portability at a modest performance cost. MQTT addresses a class of constrained clients that neither OpenWire nor AMQP serves well.
For new ActiveMQ deployments, the practical recommendation is: Java microservices → OpenWire; polyglot services or cloud-native integrations → AMQP 1.0; IoT devices → MQTT. These three protocols can coexist on the same broker, with the broker routing messages between them transparently.
MeshIQ Console surfaces per-protocol connection counts, message rates, and per-acceptor health metrics in a unified dashboard, giving you the visibility to understand how each client tier is performing and to detect protocol-specific issues before they become systemic incidents.
Need help designing your multi-protocol ActiveMQ architecture?
Talk to an ExpertFrequently Asked Questions
OpenWire is the default and native protocol for Apache ActiveMQ®, on port 61616. Apache Artemis™’s default port 61616 is a multi-protocol acceptor that auto-detects OpenWire, AMQP, STOMP, MQTT, and the native Core protocol. Apache ActiveMQ® 5.13+ adds an AUTO transport for single-port multi-protocol detection.
Both are binary protocols. OpenWire is ActiveMQ-specific and 10–30% faster due to zero translation overhead. AMQP 1.0 is an OASIS/ISO standard compatible with any AMQP 1.0 broker: Azure Service Bus, IBM MQ, and others. OpenWire supports the full JMS feature set, including XA transactions; AMQP supports local transactions. Use OpenWire for maximum performance in Java-only environments; use AMQP when polyglot or cross-broker interoperability is a real requirement.
MQTT for constrained IoT devices where payload size and battery consumption matter. AMQP for polyglot enterprise services needing rich message properties, transactions, and cross-broker portability. The two protocols are complementary; many architectures use MQTT for device-to-broker and AMQP or OpenWire for broker-to-backend on the same ActiveMQ deployment.
Yes. Configure separate connectors per protocol (OpenWire, AMQP, MQTT, STOMP) or use the AUTO transport (Apache ActiveMQ® 5.13+) or Apache Artemis™’s default multi-protocol acceptor for all protocols on one port. Messages sent via one protocol are transparently routed to consumers using any other protocol.
Yes. Both Apache ActiveMQ® and Apache Artemis™ support AMQP 1.0 only, not AMQP 0-9-1 (RabbitMQ’s native protocol). The two are incompatible at the wire level. AMQP 1.0 is an ISO standard used by Azure Service Bus, IBM MQ, and others.