Chapters

16 XMPP: Messaging Foundations

protocols
application-protocols
xmpp-protocol-fit
messaging
technology-selection

Start with the story: XMPP is useful when an IoT system needs addressed conversations, presence, discovery, or federation rather than just another telemetry pipe. Start by asking who needs to know that a device is present, what stanza carries the fact, and whether the extra semantics are worth operating.

16.1 Start With the Decision

An XMPP stanza can carry device state through a long-lived session. The design must name the transport, address, extension, and delivery limit.

16.2 Route Overview

This is part 1 of 2. Continue with XMPP: Protocol Fit and Operations.

16.3 Part Objectives

  • Trace XMPP streams, stanzas, addressing, and extensions.
  • Identify delivery and scaling limits for IoT messaging.

16.4 Chapter Roadmap

  • In 60 Seconds
  • Reference Anchors
  • XMPP Review Route
  • Architecture Roles
  • Authentication and Channel Security
  • Stanza Roles
  • Addressing and Discovery
  • Presence and PubSub
  • IoT Extension Evidence
In 60 Seconds

Use one message path first. Name the sender. Name the receiver. Give the message a purpose. Set its safe age. Decide whether a reply is needed. Decide whether a repeat is safe.

Check identity at both ends. Check who owns each server. Check how access ends. Save a clear message ID. Keep time visible. Log rejection as well as success.

Break the path. Restart one end. Send while the worker is away. Restore the path. Look for lost, late, or repeated work. Make the operator see each case.

Add features only for a named need. Presence may help one service. Group exchange may help another. Extra rules add support work. Record every chosen extension. Recheck after server, policy, or message changes.

Picture a building service that sends a fault message to a repair team. The worker may be offline. The message may cross company boundaries. The sender needs to know who the other party is. The service also needs a clear rule for delayed or repeated delivery.

Start with the conversation. Name each party. Decide who can begin it. Decide whether messages go to one person, a group, or a service. Mark which messages may wait. Mark which ones become unsafe when old. State what the receiver must confirm.

The exchange uses named identities and structured messages. A long-lived session can carry a series of small exchanges. Extra rules can add group chat, presence, or device control. These features are useful only when both ends agree on their meaning and security duties.

Plan for breaks. A device may lose its path. A service may restart. A message may arrive twice. Keep an identity check. Give each important action a unique record. Set an age limit. Make reconnect behavior visible to the operator.

This first view treats the path as one managed conversation. Real systems may cross several servers and policy areas. The Practitioner layer builds the message and operations record. Under the Hood examines session state, message extensions, trust between services, and the cases where a chat-shaped exchange is a poor fit for device work. XMPP is a standards-based XML messaging protocol built around persistent streams, global addresses called JIDs, three core stanza types, and optional federation between domains. For IoT, XMPP is strongest when identity, presence, discovery, human-device interaction, or cross-domain messaging matter. It is usually a poor default for constrained telemetry unless the selected devices, servers, extensions, transport, security model, and operations team prove that the extra protocol semantics are worth the implementation cost.

16.5 Learning Objectives

By the end of this chapter, you should be able to:

  • Explain the core XMPP roles: client, server, stream, stanza, JID, and federation.
  • Distinguish message, presence, and IQ stanzas by their system role.
  • Describe how service discovery and PubSub extensions fit into an IoT architecture.
  • Identify what evidence is needed before using XMPP IoT extensions in a real design.
  • Compare XMPP with MQTT, AMQP, CoAP, and WebSocket-based designs using requirements evidence.
  • Build a protocol-fit record without relying on stale bandwidth, cost, or vendor claims.

16.6 Reference Anchors

Use current standards and implementation documents before making a deployment decision:

Read these points as one connected sequence: start with RFC 6120: XMPP Core: XML streams, client-to-server and server-to-server behavior, stanza semantics, STARTTLS, SASL, resource binding, and security considerations; then RFC 6121: XMPP Instant Messaging and Presence: presence subscriptions, rosters, messaging behavior, and IM-oriented presence rules; then RFC 7622: XMPP Address Format: modern JID address format replacing the older RFC 6122 address definition; then RFC 7395: XMPP over WebSocket: WebSocket transport for XMPP when browser or web-proxy environments need it; then XEP-0030: Service Discovery: discovering entity identity, supported features, and associated items; then XEP-0060: Publish-Subscribe: PubSub nodes, subscriptions, publications, notifications, and access models; then XEP-0323: Internet of Things - Sensor Data: XMPP sensor-data extension; and finish with XEP-0325: Internet of Things - Control: XMPP control extension for writable device fields.

These are review anchors, not deployment proof. A real project still needs server support, client libraries, extension compatibility, security review, privacy review, field testing, and operations evidence.

16.7 XMPP Review Route

Start by deciding whether the project needs XMPP semantics or only a transport for device data.

Use Figure 16.1 to keep that decision evidence-led. Begin with the application need, then move from standards claims to implementation and field proof before comparing alternatives.

XMPP review route from application need through XMPP semantics, standards evidence, implementation evidence, field validation, and protocol comparison.
Figure 16.1: XMPP review route from application need through XMPP semantics, standards evidence, implementation evidence, field validation, and protocol comparison.

Read Figure 16.1 from left to right. First name the required semantic—presence, directed messaging, discovery, PubSub, or federation. Next identify the RFC or XEP that defines it, then prove that the selected server and client implement the same feature. Field validation follows because standards support alone says nothing about operations, failure, or interoperability. Only then compare a simpler protocol, preserving the chapter’s distinction between an attractive capability and deployable evidence.

Use this route:

  1. Record the application need: presence, directed messaging, discovery, PubSub, federation, human-device interaction, or history.
  2. Map the need to XMPP standards: core streams, stanza type, JID addressing, discovery, PubSub, IoT extensions, or WebSocket transport.
  3. Check implementation support in the exact server, client, library, gateway, and device profile.
  4. Validate security, privacy, operational ownership, monitoring, and failure behavior.
  5. Compare against simpler alternatives when XMPP semantics are not required.

16.8 Architecture Roles

Federation is clearer when one full JID crosses two administrative domains. Figure 16.2 routes a pump alert from plant.example to a contractor resource at service.example.

Four-stage XMPP route: authenticated client-to-server stream, DNS-discovered server-to-server federation, message presence and IQ stanza semantics, and delivery to a named recipient resource.
Figure 16.2: An XMPP pump-alert stanza moves from a sensor client through two federated domain servers to a contractor mobile resource.

In Figure 16.2, Client stream authenticates sensor-7@plant.example/pump, and Federated hop discovers and opens an S2S stream to the recipient domain. Stanza semantics separates <message>, <presence>, and <iq>, while Recipient resource makes /mobile routing and queue policy explicit.

XMPP architecture separates local clients, local servers, optional server-to-server federation, and extension services. That is useful for cross-domain identity and presence, but it also creates more surfaces to operate.

Inspect Figure 16.3 to locate each trust and operations boundary before treating federation as a benefit.

XMPP federation across domains: devices bind to a local server over client-to-server port 5222, and home and office servers exchange messages over server-to-server port 5269 with no central broker.
Figure 16.3: XMPP devices connect to a local server (client-to-server, port 5222) while servers federate across domains (server-to-server, port 5269), routing messages without a central broker.

In Figure 16.3, start at a device or application opening its client-to-server stream to the local server. The local server authenticates the entity, binds its resource, and routes local stanzas. Then follow the optional server-to-server path across domains, where DNS, certificates, trust, policy, and abuse controls become shared concerns. Extension services hang from those servers rather than from a magical central broker. This architecture explains why XMPP can federate and why the operating surface grows with that choice.

Client entity Device, gateway, application, or user agent that opens an XML stream, authenticates, binds a resource, and exchanges stanzas.
Local server Terminates client streams, authenticates users or devices, routes local stanzas, stores roster or policy state, and exposes extensions.
Federation path Optional server-to-server route for cross-domain messaging. Review DNS, TLS, trust, policy, abuse controls, and monitoring.
Extension service Service discovery, PubSub, multi-user chat, IoT sensor data, control, archive, or another XEP-backed capability.

16.9 Authentication and Channel Security

SASL and TLS are named in the Architecture Roles federation checklist above, but “we use TLS” is not evidence by itself. Review the exact mechanism, because XMPP’s authentication and channel-security defaults have specific, documented gaps.

SASL password exposure Plain SASL mechanisms commonly encode credentials with Base64, which is an encoding, not encryption, and carries no confidentiality check of its own. A Base64-encoded password is trivially decodable, so the exchange stays exposed to man-in-the-middle, address-spoofing, and unauthorized-access attacks unless the surrounding channel is protected end to end.
STARTTLS timing risk XMPP typically upgrades a plaintext stream to TLS with STARTTLS. If crafted messages are sent while that upgrade is still in progress -- before the three-way TLS handshake completes -- a shotgun-parser exploit can use the pre-TLS window to tamper with data such as header fields. Confirm the exact server and client reject or hold stanzas received before STARTTLS negotiation finishes.
Multipath stream gaps XML stanzas can travel across multiple stream paths and federation hops. Not every hop is guaranteed to be TLS-protected end to end, so confidentiality and integrity can silently drop on a path nobody reviewed.
Recommended fix Pair TLS with SASL so encryption covers the full exchange, not just the password field, and prefer an authentication mechanism with a built-in confidentiality check and channel binding -- such as SCRAM-SHA-1 or SCRAM-SHA-1-PLUS -- over plain or Base64-only mechanisms.

Record the exact SASL mechanism, the point in the stream where TLS becomes mandatory, and whether channel binding is negotiated before approving an XMPP deployment. “STARTTLS is enforced before any stanza is accepted, and SCRAM-SHA-1-PLUS is the negotiated mechanism” is an evidence record; “we use TLS” is not.

16.10 Stanza Roles

XMPP traffic is built around three core stanza families. Each one answers a different design question.

Use Figure 16.4 to classify the application intent before writing XML. Read the three branches as event delivery, availability state, and correlated request-response.

XMPP stanza roles showing message for event delivery, presence for availability state, and IQ for request-response operations.
Figure 16.4: XMPP stanza roles showing message for event delivery, presence for availability state, and IQ for request-response operations.

In Figure 16.4, inspect message first for alerts and notifications that do not require an IQ-style result. Move next to presence, where a state change may fan out to subscribers and therefore carries privacy and load consequences. Finish with iq, whose get, set, result, and error types form a request-response exchange. Keeping those roles distinct makes the examples below design evidence rather than three interchangeable XML envelopes.

Message

Use a message stanza for event-like delivery, alerts, chat-style commands, notifications, or PubSub notifications. A message is not the same as a correlated request-response transaction.

Presence

Use presence when availability state is part of the application. Presence is useful for “device reachable”, “operator online”, “maintenance mode”, or “gateway unavailable” workflows, but it must be designed with privacy and fan-out load in mind.

IQ

Use IQ for structured request-response interactions. Service discovery, roster operations, many extension queries, and device control patterns use IQ-like get, set, result, and error flows.

<message from="sensor-7@plant.example/line-a"
         to="dashboard@ops.example/web"
         type="chat">
  <body>threshold alert: vibration review required</body>
</message>

<presence from="gateway-3@plant.example/west">
  <show>away</show>
  <status>maintenance window</status>
</presence>

<iq from="controller@ops.example/tablet"
    to="pump-2@plant.example/panel"
    type="get"
    id="read-42">
  <query xmlns="urn:xmpp:iot:sensordata"/>
</iq>

Keep examples short. Production designs need schema, namespace, validation, authorization, retry, timeout, and audit records.

16.11 Addressing and Discovery

JIDs identify XMPP entities and resources. Service discovery lets a requester ask what an entity is and which features or items it exposes. That combination is useful for device capability review, but it can also leak information if access control is weak.

Inspect Figure 16.5 as a lifecycle record, beginning with identity naming and ending with deprovisioning rather than stopping when a discovery query succeeds.

XMPP addressing and discovery record connecting JID policy, resource binding, discovery queries, authorization, privacy boundary, feature evidence, and deprovisioning.
Figure 16.5: XMPP addressing and discovery record connecting JID policy, resource binding, discovery queries, authorization, privacy boundary, feature evidence, and deprovisioning.

Read Figure 16.5 from the JID policy through resource binding, then into discovery authorization. The returned identity, feature, and item lists are useful capability evidence, but they also reveal entity existence and device function, so the privacy boundary must be evaluated alongside access control. Finish at version evidence and deprovisioning: a retired or compromised resource must stop advertising and accepting work. That full route connects addressing to the operational proof required by the review route.

Record:

  • JID naming policy for devices, gateways, applications, and users.
  • Resource binding behavior for multiple sessions or device roles.
  • Which discovery queries are allowed to which requesters.
  • Feature list and version evidence for each extension.
  • Privacy controls for entity existence, item lists, and device capabilities.
  • Deprovisioning behavior when a device is replaced, retired, or compromised.

16.12 Presence and PubSub

Presence and PubSub are the most common reasons to consider XMPP in an IoT workflow. They should be reviewed as application semantics, not as a shortcut around telemetry architecture.

Inspect Figure 16.6 to separate availability from published data before estimating fan-out and storage behavior.

XMPP presence and PubSub flow showing device availability, subscriber notification, PubSub node publication, authorization, and application handoff.
Figure 16.6: XMPP presence and PubSub flow

In Figure 16.6, follow presence from an entity’s availability change to authorized watchers, then follow a payload into a PubSub node and out to subscribers. Presence answers whether an entity is reachable or in a named state; PubSub distributes items under node policy and may retain them. The authorization and application handoff apply to both branches. This distinction helps decide whether XMPP semantics are genuinely needed or whether a simpler telemetry broker fits the running workload.

Presence fit Use when the system needs availability state, reachability, operator/device status, or state changes pushed to subscribers.
PubSub fit Use when the system benefits from XMPP nodes, subscriptions, access policy, notifications, and optional stored items.
Telemetry caution High-volume sensor data may be simpler through MQTT, AMQP, CoAP, HTTP, or a stream pipeline unless XMPP semantics are required.

16.13 IoT Extension Evidence

XEP-0323 and XEP-0325 define XMPP extension patterns for sensor data and control. They are useful standards anchors, but a deployment decision must prove support in the selected stack.

Inspect Figure 16.7 from specification to field behavior so an XEP citation cannot substitute for compatibility proof.

XMPP IoT extension evidence showing sensor data, control fields, server support, client library support, access control, field tests, and fallback.
Figure 16.7: XMPP IoT extension evidence showing sensor data, control fields, server support, client library support, access control, field tests, and fallback.

Read Figure 16.7 by following one sensor field or control command. Confirm the namespace and field contract first, then check the exact server and client-library implementations. Continue through access control and error behavior before running field tests against disconnects, stale values, rejected writes, and timeouts. The fallback at the end matters because partial XEP support is common. This chain turns an extension choice into the implementation evidence demanded by the opening review route.

Before relying on XMPP IoT extensions, check:

  • Server support for the needed XEPs and namespaces.
  • Client library support on the device, gateway, browser, or application runtime.
  • Field naming, type, unit, timestamp, and validation rules.
  • Access control for read and write operations.
  • Error behavior for unavailable devices, stale fields, rejected commands, and timeouts.
  • Monitoring and fallback if an extension is missing or implemented differently.

16.14 Continue to the Next Part

Carry this evidence into XMPP: Protocol Fit and Operations, which begins with Protocol Fit.